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.
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