Question

A new branch from master is created, we call it test.

There are several developers who either commit to master or create other branches and later merge into master.

Let’s say work on test is taking several days and you want to continuously keep test updated with commits inside master.

I would do git pull origin master from test.

Question 1: Is this the right approach? Other developers could have easily worked on same files as I have worked btw.

---

My work on test is done and I am ready to merge it back to master. Here are the two ways I can think of:

A:

git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test 

B:

git checkout test
git pull origin master
git checkout master
git merge test

I am not using --rebase because from my understanding, rebase will get the changes from master and stack mine on top of that hence it could overwrite changes other people made.

Question 2: Which one of these two methods is right? What is the difference there?

The goal in all of this is to keep my test branch updated with the things happening in master and later I could merge them back into master hoping to keep the timeline as linear as possible.

Answer 1

How I would do this

git checkout master
git pull origin master
git merge test
git push origin master

If I have a local branch from a remote one, I don’t feel comfortable with merging other branches than this one with the remote. Also I would not push my changes, until I’m happy with what I want to push and also I wouldn’t push things at all, that are only for me and my local repository. In your description it seems, that test is only for you? So no reason to publish it.

git always tries to respect yours and others changes, and so will --rebase. I don’t think I can explain it appropriately, so have a look at the Git book – Rebasing or git-ready: Intro into rebasing for a little description. It’s a quite cool feature