251

I have my master branch and a develop branch for working on a few changes. I need to merge changes from master into develop, but will eventually merge everything from develop into master. I have two different workflows in mind:

  1. git pull origin master into develop branch
  2. git merge master into develop branch

Which is the best way to do this, and why?

Dom
  • 1,687
  • 6
  • 27
  • 37
Carson
  • 17,073
  • 19
  • 66
  • 87

6 Answers6

354

This workflow works best for me:

git checkout -b develop

...make some changes...

...notice master has been updated...

...commit changes to develop...

git checkout master
git pull

...bring those changes back into develop...

git checkout develop
git rebase master

...make some more changes...

...commit them to develop...

...merge them into master...

git checkout master
git pull
git merge develop
elemjay19
  • 1,126
  • 3
  • 25
  • 51
Ian Lotinsky
  • 3,985
  • 2
  • 15
  • 10
  • 2
    This is how I work too, and I find it works well. There's one thing I don't do though, and that's the `git pull` right before the final `git merge develop`. What's the purpose of that? – crdx Aug 31 '12 at 08:05
  • After the ...notice master has been updated... part, wouldn't the checkout master wipe your local changes to develop if you not commit them? – a1an Sep 04 '12 at 13:59
  • 1
    @a1an No, but if you don't commit them then the changes will move over to the master branch and git won't let you pull until they have been committed. – elemjay19 Dec 17 '12 at 16:42
  • @Ian Lotinsky when working on 'develop' how could you tell that 'master' had been updated? – zkent Jan 30 '13 at 23:53
  • @zkent, git pull would pull any changes down. – Ian Lotinsky Feb 01 '13 at 17:47
  • @zkent because at times there are those who commit on master, no matter what! – Tarun Feb 27 '13 at 04:48
  • 5
    @crdx Chances are that other branches are merged to remote master before you merge your branch to your local master. You pull and bring remote master changes to your local copy of master. This is how I understood it. – Tarun Feb 27 '13 at 04:50
  • 12
    `git pull --rebase origin master` on your develop branch is a bit faster. – Nathan Lilienthal Apr 10 '13 at 14:33
  • I need to clarify something: This answer assumes that `develop` branch is **not** shared across multiple users, right? Or, would this solution work if we had a `master` and a `develop` branch that were being pulled by multiple users? For example, if each user would typically send PR's of their feature branches into `develop`, but some hot fixes were applied to `master`, how would we update the hotfixed changes onto our `develop` branch? It seems like rebasing a shared `develop` branch is bad news for other users, because it would require one to push-force the rebased `develop` branch. – modulitos Dec 08 '15 at 05:29
  • Remember to `git push` your changes to the `master` branch after the steps above! Might sound really basic but I forget sometimes and wonder where my changes are lol. – Gcap Nov 17 '16 at 23:58
111

Be careful with rebase. If you're sharing your develop branch with anybody, rebase can make a mess of things. Rebase is good only for your own local branches.

Rule of thumb, if you've pushed the branch to origin, don't use rebase. Instead, use merge.

Eric Leads
  • 1,142
  • 1
  • 7
  • 2
  • Yet is it safe to rebase and a `git push origin rebasedBranch --force` on a private repo? The only user is myself. – k0pernikus Oct 25 '12 at 13:46
  • Yes, if you're the only user, of course it is safe. I use git push --force all the time when I'm the only user. :) – Tyler Rick Mar 28 '13 at 21:53
  • 3
    I echo Eric's warning. Although, it's perfectly okay to rebase your own remote branch too. Play around with both rebase and merge and you will understand the pros and cons of each and learn when to use them. – Ian Lotinsky Sep 06 '13 at 02:37
  • Good article on using rebase, even merging after resolving conflicts: https://github.com/everpix/Everpix-Intelligence – Ian Lotinsky Jan 11 '14 at 01:32
  • @IanLotinsky your link doesn't point to an article on rebase. Longshot, but do you still have the correct link? :) – Daniel Serodio Jan 04 '18 at 16:11
  • I don’t get this answer, the question was about which one to use between pull or merge, not rebase. – Albizia Feb 01 '19 at 15:14
26

The best approach for this sort of thing is probably git rebase. It allows you to pull changes from master into your development branch, but leave all of your development work "on top of" (later in the commit log) the stuff from master. When your new work is complete, the merge back to master is then very straightforward.

Derek Mahar
  • 27,608
  • 43
  • 124
  • 174
divegeek
  • 4,795
  • 2
  • 23
  • 28
  • 10
    Good advice, assuming `develop` isn't shared with anyone else. – Karl Bielefeldt Apr 06 '11 at 00:17
  • 1
    @KarlBielefeldt If `develop` **is shared** with other contributors, how would we update `develop` when some hotfixes were pushed directly to `master`? Should we do a merge, ie `git checkout master && git pull --rebase && git checkout develop && git merge master`? I left a comment on the highest voted answer above, which also details this concern. – modulitos Dec 08 '15 at 05:34
6

If you are not sharing develop branch with anybody, then I would just rebase it every time master updated, that way you will not have merge commits all over your history once you will merge develop back into master. Workflow in this case would be as follows:

> git clone git://<remote_repo_path>/ <local_repo>
> cd <local_repo>
> git checkout -b develop
....do a lot of work on develop
....do all the commits
> git pull origin master
> git rebase master develop

Above steps will ensure that your develop branch will be always on top of the latest changes from the master branch. Once you are done with develop branch and it's rebased to the latest changes on master you can just merge it back:

> git checkout -b master
> git merge develop
> git branch -d develop
KiRPiCH
  • 379
  • 3
  • 6
1

my rule of thumb is:

rebase for branches with the same name, merge otherwise.

examples for same names would be master, origin/master and otherRemote/master.

if develop exists only in the local repository, and it is always based on a recent origin/master commit, you should call it master, and work there directly. it simplifies your life, and presents things as they actually are: you are directly developing on the master branch.

if develop is shared, it should not be rebased on master, just merged back into it with --no-ff. you are developing on develop. master and develop have different names, because we want them to be different things, and stay separate. do not make them same with rebase.

hoijui
  • 3,615
  • 2
  • 33
  • 41
0

I prefer to use git pull origin <branch_name> over to the branch I am looking to merge into. I infact haven't ever used git merge <branch_name>

Reason, I used to get a bug with it in GitLab when I had started to use it. But now it is more logical as well... because git pull does: (a) git fetch (b) git merge

2 commands vs one; makes it no brainer application to keep work going fast.

PS: if you aren't sure what might come, it might be better to use the 'broken down' commands there right ;)

Mehdi
  • 61
  • 4