About the application scenarios and differences of branch merge and rebase in Git

Recently approached Git, here is a summary of some basic usage.

This article is reproduced in csdn:http://blog.csdn.net/rryqsh/article/details/8230560

Almost all version control tools have branch functionality, and branch is used primarily for the following scenarios:

1, control the product OEM.

Basically do products, different customers will come up with a variety of different characteristics of demand, the simplest example is the logo and the title is not the same. But perhaps most of the functionality of the product itself and the code of the module, this time how to manage multiple customer-specific features, and do not interfere with other OEM version of the functionality?

If you start with if plus n multivariate definition, the morning will be exhausted you, if you copy many copies of the code, each more than one new OEM copy a copy of the code, if you find that there is a bug in the public module, do you want to modify each version of the source code? If you change the wrong place, or which version of the forgotten Change, is a troublesome thing.

This time we can consider using the branch function, on the basis of the first OEM to sub-expenditure of the second OEM, the third OEM completely depends on and which version more like, on the basis of that version of the new branch, with the new OEM feature requirements, switch to that branch to modify, rest assured that The code on all of the individual branches looks independent and does not affect the other versions.

2, multi-person collaboration for long-time development of functional modules

If you're in a team, it's almost impossible to do a module function on schedule every day, and the test passes. The team members have to save their code once a day before they leave work, and if the machine fails, a code backup mechanism is also available. If you submit a code that doesn't work, and someone else gets it, the rest of us won't be able to do it anymore. So, branch another application scenario is to open a personal work area for team members, and then merge the work code of the member into the main branch after the unit test is correct, which can not only achieve the purpose of personal code backup, but also can not affect other people's work.

In fact, the above is the rebase and merge different application scenarios.

In the case of scenario 1, if you modify a bug in a common code, this is the time to put all the OEM version branches rebase to the branch to fix the bug, in the rebase process, Git will ask you to manually resolve the conflict on the code, All you need to do is put the bug fix code inside the target branch code. The result of rebase is that all branches still exist.

In the case of scenario 2, because the members of the code development work has been completed, there is no need to retain this branch, so we can put this member branch merge to the main branch, of course, the conflict is inevitable, hand-resolved work must not escape, but the benefits outweigh the harm is not it. After merge, the branch does not exist, but it can be seen in all of Git's branch history.

Depending on the scenario, use different branch merging strategies to keep your team's code alive.

About the application scenarios and differences of branch merge and rebase in Git