CODEWITHSUNDEEP
gitgit-mergegit-rebasegit-pull
Narek
Narek

Reputation: 39871

Why for git pull merging is the default behavior?

Usually when we update our local repository with new origin commits we do git fetch, git rebase. But we don't do git fetch git merge. Usually, the reason is that we don't want to add a new commit (merge commit) but just want to get all new commits on top of our code. So why then the default behavior for git pull is not with merge. I know that we can change it, but is there is better reason to use fetch-merge over fetch-rebase.

Upvotes: 9

Views: 4024

Answers (2)

Stas
Stas

Reputation: 11761

I think it works this way by default to avoid rewriting local history, and changing hashes of existing commits. These commits might be already pushed to the remote. The rebase is a destructive command, and pulling changes from the remote shouldn't destruct anything by default.

You can use git pull --rebase or just create an alias for this action.

Upvotes: 3

poke
poke

Reputation: 387617

I assume your question is why with git pull the default behavior is to merge instead of to rebase the pulled-in changes.

The answer is rather simple: Rebasing recreates the commits that are being rebased. Those new commit objects then replace the old ones. But those new commits are completely incompatible with the old ones. This causes all other users who have pulled the original commits before to have incompatible commits from the rebased ones you just recreated. So you have two conflicting versions with mostly the same change. This usually means a lot of problems since you need to fix these conflicts manually (by saying which of the two versions to keep; so if you rebased, the other ones all need to throw the old ones away—manually).

This is also why you should never rebase commits that have been published.

So the default solution is to merge, as merging is a completely safe operation that will not cause conflicts. Merge commits are just commits that are added to the history, but do not replace the existing history. Yes, it may make the history a bit more complex, but it’s completely transparent and compatible with all versions that existed before.

Of course, there are some situations in which rebasing is just fine. Most notably if you work locally on some unpublished changes and you want to update your repository. Then fetching and rebasing your local changes is fine since they only belong to yourself and nobody else knows about them yet. But this should always be an explicit action, so you don’t make any mistakes. And that’s why the rebasing pull is just an option: git pull -r.

Upvotes: 13

Related Questions