Doesn't GIT force many big merges?

I am getting into th开发者_StackOverflow中文版e GIT world, but it seems like GIT has a huge disadvantage. Because your are submitting to your own local repository and only after several submissions your are submitting to the outside world, doesn't it creates many big merges?

---

Really, there's a way around merges in almost all cases in git. Instead of merging, you rebase your local repository, re-arranging history. By using rebase, the canonical/origin repository is never re-arranged and rarely has any merge commits, but local repository histories are re-arranged to more closely match the main repo.

So:

git fetch
git rebase origin/master
// resolve any conflicts (if there are any) by altering your own commits
git rebase --continue
git push

And all commits will be atomic, and the origin/master will never have any merge commits.

Now, in a rare rare case the rebasing process will become complicated and you'll find yourself resolving a lot of conflicts, in which case you may want to git rebase --abort and back out of the rebase process and then go for a merge instead, but I've gone months without needing to resort to a merge at this point, so keeping the history linear isn't too hard.

Essentially what this is doing is taking the least destructive approach. You are saying "hey, all of my commits are ones that I added to my local master branch -after- whatever other people put in the central/canonical branch are my responsibility, so -I- will be the one to re-arrange my code." In this manner, whatever goes into the master branch of whatever repository is deemed canonical FIRST gets precedence, and other people do not have to deal with merge commits that rewrite history for anything that is successfully pushed to the master branch.

---

Well yes, you could find yourself in that situation, but it is avoidable. Even if you decide to push your repo only after several (N amount of) commits, you still can pull from other branches constantly so that you are always integrating with whatever other people are doing. And Git is pretty good at merging anyway.

---

Not at all. Each commit in git is uniquely identifiable regardless of which repo it lives in. Therefore merges work exactly as they should. Git also has extremely good support for conflict resolution, making it even better at merges than some other VCSs.

---

It essentially depends on how often you decide to push your code and how often others are pulling the code. For example, if you push a small change and someone else pulls that change, it will not be a large merge. However, if you do not push until you have committed locally numerous times, then the pull could be a large merge.

I hope this helps.