Categories
branching-and-merging git git-branch git-merge

How do I safely merge a Git branch into master?

2521

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.

4

  • 31

    no.. rebase never overwrite, it just trying to achieve a cleaner history. by reattach(or fake) the history to the late point of the master

    Dec 23, 2015 at 11:47

  • 11

    rebase doesn’t overwrite your commits. It undoes your commits, applies the commits in the master branch to your test branch, then applies your commits back to test.

    – zundi

    Jun 20, 2016 at 14:32

  • 2

    What if we don’t have write access to master? Any way to fix conflicts pre-emptively on the feature branch? Probably not I guess, since the histories have probably diverged

    Jul 22, 2020 at 17:20

  • Why is this question not closed as it is opinon based? Please close this question please. That’s they main purpose of stack overflow, to close down questions

    Sep 27, 2021 at 10:37

3516

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

20

  • 3

    git merge test gives me fatal: 'test' does not point to a commit. I have to look in git log for the commit point on the test branch, switch back to master branch then do git merge 0f37d3154abbf52a4cbbbb5109f08af6a7567234.

    – Duncanmoo

    Dec 2, 2014 at 10:08

  • 21

    @Duncanmoo Well, of course the branch test must exist. Sure, you can use the commit hash instead, but it’s usually easier to use the branch name. Internally it just retrieves the hash of HEAD of the branch.

    Dec 4, 2014 at 11:06

  • 49

    @shanyangqu To get the latest changes from the remote. If you work alone and only with one system ever there is no problem. But when there are changes pushed from a different system (probably from a different developer) you’ll see a conflict as soon as you try to push your merge back (the 4th step). The only solution now is to merge your local master into the remotes master, which ends up in a pretty ugly “merged master into origin/master” merge commit. So it’s always a good idea to make a pull before the merge

    Dec 24, 2015 at 22:47

  • 9

    ” In your description it seems, that test is only for you? So no reason to publish it.” You might want to push your local branch up to a server if, for example, that server provides a backup against your local drive failing or if you don’t have another means to do a backup.

    – Eric

    Feb 13, 2017 at 18:02

  • 14

    “…Also I would not push my changes, until I’m happy with what I want to push…” why not pushing for the sake of having your code backed up, in case your local machines dies and days of efforts are gone?

    Aug 15, 2018 at 9:33


508

This is a very practical question, but all the answers above are not practical.

Like

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

This approach has two issues:

  1. It’s unsafe, because we don’t know if there are any conflicts between test branch and master branch.

  2. It would “squeeze” all test commits into one merge commit on master; that is to say on master branch, we can’t see the all change logs of test branch.

So, when we suspect there would some conflicts, we can have following git operations:

git checkout test
git pull 
git checkout master
git pull
git merge --no-ff --no-commit test

Test merge before commit, avoid a fast-forward commit by --no-ff,

If conflict is encountered, we can run git status to check details about the conflicts and try to solve

git status

Once we solve the conflicts, or if there is no conflict, we commit and push them

git commit -m 'merge test branch'
git push

But this way will lose the changes history logged in test branch, and it would make master branch to be hard for other developers to understand the history of the project.

So the best method is we have to use rebase instead of merge (suppose, when in this time, we have solved the branch conflicts).

Following is one simple sample, for advanced operations, please refer to http://git-scm.com/book/en/v2/Git-Branching-Rebasing

git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test

Yep, when you have uppers done, all the Test branch’s commits will be moved onto the head of Master branch. The major benefit of rebasing is that you get a linear and much cleaner project history.

The only thing you need to avoid is: never use rebase on public branch, like master branch.

Never do operations like the following:

git checkout master
git rebase -i test

Details for https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing

appendix:

8

  • 5

    I agree rebasing the test branch for later merging into master is the way to go. Even the other answers are correct this will keep history of changes of branch test in the head of master as the auther mention “you get a liner and much cleaner project” which is the purpose of version control system.

    – le0diaz

    May 5, 2016 at 14:32

  • 23

    The statement “it’s not one safety way, cause we don’t know is there any conflicts between test branch and master branch” is not true: one can always abort the merge. And even if there are no conflicts you can always undo the last local commit as long as it is not pushed. Without correct understanding of git some things may seem a bit scary or unclear, but “unsafe” is just incorrect in any way. Please be careful not to confuse others with incorrect information.

    Aug 17, 2016 at 23:11

  • 7

    agree with @PaulvanLeeuwen, when you git merge the test branch into master, you will be notified about conflicts, and thats where you’ll step in and merge the changes. Once you’re done, you will commit the merge and push back. If you regret or cant seem to merge it correctly, you can always discard your work and pull from master again. So it is definitely not unsafe..

    – Juan

    Oct 8, 2016 at 22:26

  • 4

    why rebase -i ?

    – MushyPeas

    Jun 16, 2017 at 10:59

  • 12

    Rebasing is inherently more unsafe than merging. Proposing rebasing as a more safer option to merging is wrong. Rebasing is a valid strategy, but comes with more caveats that the user should beware of.

    – Ikke

    Mar 31, 2018 at 6:14

99

Neither a rebase nor a merge should overwrite anyone’s changes (unless you choose to do so when resolving a conflict).

The usual approach while developing is

git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier

When you’re ready to merge back into master,

git checkout master
git log ..test # if you're curious
git merge test
git push

If you’re worried about breaking something on the merge, git merge --abort is there for you.

Using push and then pull as a means of merging is silly. I’m also not sure why you’re pushing test to origin.

7

  • 1

    This process will increase number of commits, every time you switch between branches, you have to commit your branch.

    – iBug

    Jul 21, 2014 at 7:34

  • 2

    What? Are you saying it will increase the number of commits every time you switch branches? Or are you saying that every time you switch branches, you have to “commit your branch”? The first is untrue and I’m not sure what the second means.

    – raylu

    Jul 21, 2014 at 19:30

  • before checkout, you have to commit branch. that is what i am saying

    – iBug

    Jul 22, 2014 at 3:29

  • 14

    You don’t: that’s (one of the things) git stash is for.

    – msanford

    Aug 13, 2014 at 16:36

  • 1

    Or you could ammend your last commit (in local branch) and make it the perfect one before pushing.

    – whihathac

    Apr 13, 2016 at 22:43