When using git to integrate branches, what is more commonly used is the rebase operation (git rebase) or the merge operation (git merge). Which one do you think is better?

Question

There are generally two ways to integrate branches in git - git rebase and git merge. But in your actual team development, which method is used the most, or which one do you think is better? ?

Answer 1

I guess the reality is like this:

1. At least half of the people who use git do not know how to use rebase (even for basic functions) (this estimate is probably very conservative)

2. I’m afraid only half of the remaining half really understand when to rebase correctly...

Merge or rebase is not a question of choosing one or the other. It should be chosen according to the specific situation. In reality, this "specific situation" is really difficult to list one by one. For most developers, It is said that the functions in the team are relatively single, and it is not often encountered, so here I will only summarize two principles that everyone should understand and abide by:

1. When you go pull from remote, always use rebase (with one exception, discussed later)

2. When you complete a feature (assuming you opened a local branch separately) and plan to merge it into the trunk branch, always use merge

Developers should understand that different merge strategies may not affect the final code result, but they will affect how git records the history of submissions (although many times this understanding only benefits individuals and has little impact on themselves). When other people use these histories (such as during code review, or during bisect, etc.), they will feel extremely happy or miserable because of what you have done in the past.

The second point is easier to understand. Hide the specific details of developing a function in the local branch, and merge the final result into the trunk branch as a complete record.

The key is the first point. In most cases, everyone will choose the default pull，也就是 fetch + merge, which is fetch + merge, so we will see interference messages such as Merge commit xxx into xxx appearing constantly on the trunk. If everyone does this for convenience, then we will never have a clean and beautiful history tree. Instead, we will have something like this:

If you clone a project that uses git correctly, you will never see a messy master like the picture above. why? The answer is: git pull --rebase. This command will use rebase instead of the default git pull --rebase，这条命令会使用 rebase 来代替默认的 pull to rebase the merged history tree, which can avoid the inability to quickly Additional merge records generated by fast forward.

Now most git clients allow setting git pull 的默认行为是 --rebase, so mastering this trick can produce clean and beautiful history records for most daily pull operations, but this is not a perfect ending. There is an exception like this:

1. When you use git merge 完成了一个功能分支向主干分支的合并之后（当然是 --no-ff)

2. When you run git fetch, you find that the remote trunk is several commits ahead of you

3. If you git pull --rebase at this time, you will find that the record of the feature branch you just merged is gone...

This is because rebase will ignore merged records, so the rebase command has a special parameter called: --preserve-merges which is used to reconstruct ignored merged records. So a better solution than --preserve-merges 用于重建被忽略的合并记录。所以比 git pull --rebase 更好的方案就是用 git fetch + git rebase -p is to use

+

instead.

Of course, this is only for the special circumstances mentioned above. With the upgrade of git, it is not certain that this problem will no longer exist one day. I usually don't encounter this situation, because I always do this:

1. git pull --rebase

   After completing the function branch, do not merge, but go back to the main branch
If the trunk is updated, rebase the updated content to the function branch to pre-check to see if my function is still OK after adding the recent changes of others (there may be conflicts in this process, don’t blame me for not reminding you) Oh)

3. git fetch

   After everything is ready, check the trunk again to see if there are any changes (because someone may have pushed new changes during the second step), if there are any changes, repeat the second step, if not -

4. Merge the functional branch to the trunk and push it, and call it a day.

git rebase -pI can avoid the accident mentioned above by doing this. It seems a bit complicated, but in fact it is not difficult once you are familiar with it. The more important reason is that

is flawed:

1. git pull cannot be used together with

   . One command is divided into two, which feels "lost" anyway (although you can write scripts, it is best not to do it because it will sometimes harm you after you get used to it)

2. git pull 配合使用，所以你必须指明目标分支给 rebase，这一点比较烦人，特别是很多 GUI 客户端压根不支持 git rebase -pSince it cannot be used with

   , you must specify the target branch for rebase, which is quite annoying, especially when many GUI clients do not support
at all (I often use git when switching environments between CLI/GUI)

3. ORIG_HEAD

will be destroyed.

ORIG_HEAD 在很多情形下非常有用，比如说你可以用 git log -p -reverse ORIG_HEAD 来回看最近一次合并所产生的所有变化等等。--preserve-merges

Very useful in many situations. For example, you can use git log -p -reverse ORIG_HEAD to review all the changes caused by the latest merge, etc. --preserve-merges will cause it to lose the location it is supposed to point to, and you will have to find the correct hash to replace it first, which can be a bit annoying.

🎜The above answer finally illustrates one thing. The complexity of reality will always exceed your imagination when you are a rookie. If you really want to use git well, you must understand the working principle of git on the basis of daily work. Yes. Go to the official website e-book (Chinese version). After carefully reading the git internal section in it, you will have an idea of ​​what command to use. 🎜

---

Additional point: If your team doesn't care about a lot of unimportant interfering commit records on the trunk branch, then you can always use rebase, so that at least there won't be many forks, and if you handle it properly, you can get a clean (but verbose) trunk. Branch history.

Answer 2

Not mandatory, but all tests are required to be green after push

(We don’t have particularly long branches, most are merged within 2-3 days, rarely more than a week)

Usually everyone chooses according to the merge difficulty. If there is no difference, rebase is given priority... because it looks better