2

I've worked on a dev team that preferred to use the method of git fetch and then git rebase rather than the method of git pull, before git pushing any changes to avoid merge conflicts.

Is there a specific reason besides the difference in the visual tree structure? According to http://mattsnider.com/git-rebase-versus-git-pull/ fetch & rebase

"will produce a cleaner history, without extraneous merge commits"

but between the two methods are there any other reasons to choose one over the other?

Jasper
  • 23
  • 7
  • You can configure `git pull` to run `git rebase` instead of `git merge` as its second step. In the end, it doesn't make much difference to *operation*, but I think `git pull` does a steep dis-service to *humans* by hiding the fact that there are actually two steps involved: `git fetch`, and then that second step. The `pull` command is also syntactically dangerous due to this same human failing: it's too easy to run `git pull origin b1 b2` and end up doing an octopus merge, because it *looks* like `git pull` does something magic, but it really doesn't. – torek Jul 25 '17 at 16:42
  • `git merge` creates a merge commit when it's not a fast-forward merge. A merge commit doesn't invoke a hook like `commit-msg`. In some cases, when you need `commit-msg` to do something with every new commit, the merge commit is ignored unless you amend it. – ElpieKay Jul 26 '17 at 01:34

1 Answers1

2

git pull = git fetch + git merge

git pull --rebase or git pull -r= git fetch + git rebase

No more, no less ;-) there is no magic. So you could do the second.

The main advantage of doing fetch then rebase in 2 distinct steps is that the first doesn't modify your local branch (absolutely no risks) and so you could do it every time (you could even create a task that run it periodically).

And once fetched, you could look at the history, compare it to your commits, and decide what you want to do and when...

Philippe
  • 28,207
  • 6
  • 54
  • 78