3

I ran into problems by merging the master branch with my feature branch. So I tried to understand how git handles merges and what's the best way to update a feature branch with the changes from the master branch. I found 2 solutions.

Number 1:

git checkout feature_branch
git merge master

Number 2:

git checkout feature_branch
git pull origin master // Read: pull the changes from origin/master into my current local branch 'feature_branch'

I read about the second solution only once whereas the first one came quite often to my eyes. Since git merge always completes with a commit, I like the second one more but wonder if it is really working the way it should.

I would appreciate any clarification.

LeEnno
  • 178
  • 3
  • 13

2 Answers2

4

In the first instance you are going to a feature branch and pulling in the latest version of the local master branch. This version of master may or may not be up-to-date with the tracking branch (origin/master) depending on whether the most recent interaction with the remote was a plain fetch vs. a pull (fetch and merge).

In the second instance, what is basically happening is that first the master branch is fetched from the remote and placed in your 'tracking' branch (origin/master). Then that version is merged into your current (development) branch.

For more info on git processes see git branch, fork, fetch, merge, rebase and clone, what are the differences?

Community
  • 1
  • 1
Michael Durrant
  • 93,410
  • 97
  • 333
  • 497
3

A pull is just a fetch with a merge; in both examples you are doing a merge, it's just the second one involves a second repository. I don't see much to choose between them.

If your feature branch is private to you, you might consider rebasing it on the new tip of master rather than merging master to incorporate changes from master. This way you can have your feature branch track master while having no merges in your history.

antlersoft
  • 14,636
  • 4
  • 35
  • 55