Git rebase and Git Merge are two branch merge strategies used in daily development. Git rebase and Git merge are two branch merge strategies used in daily development. Git rebase and Git merge are two branch merge strategies used in daily development.

An overview of the

Git rebase merges git rebase with Git merge. Git rebase merges git rebase with Git merge. Git rebase merges git rebase with Git merge.

Consider the following work scenario:

You want to develop a new feature point in your current project, so pull out a feature branch based on the main branch and start developing. At the same time your colleague develops another new feature or fixes a bug and merges it into the main branch, so the main branch also gets new commits during your development, which causes the branch’s commit history to bifurcate.

When the feature branch is developed and merged into the main branch, it is necessary to consider whether to merge or rebase.

Merge

Git merge git merge git merge git merge git merge

git checkout main
git merge feature
Copy the code

It can also be done with one line of command:

git merge main feature
Copy the code

You can then push your local changes to the remote repository via git push.

Git merge generates a merge commit on the main branch.

The advantage of merge is that it is a non-destructive operation. Because the original branch (here referring to the feature branch) is not changed after the merge.

In contrast, the disadvantage of merge is that each merge branch produces an unrelated merge commit. If the number of submissions is high, the history of these unrelated merge referrals contaminating the branch can make the project’s submission history difficult to understand when multiple people are working together.

Rebase

Similar to the merge option, we can also merge feature branches into main branches using the rebase command:

git checkout feature
git rebase main
Copy the code

The rebase command will base the entire feature branch on the top of the main branch (the commit where the head is located) and merge all new commits. However, unlike merge Commit, the rebase command rewrites the history of the entire project by creating a new commit for each commit.

In this case, the local state of the feature branch is as follows:

After the rebase operation, the local feature branch’s commit is generated based on the main branch’s commit. Then switch to the main branch to perform the merge operation:

git checkout main
git merge feature
Copy the code

Because the feature branch after rebase does not conflict with the main branch, you can directly execute the fast-forward merge to avoid merge commit. Then, you can execute git push to push the feature branch to the remote end of the main branch.

The great benefit of Rebase is that the commit history of the branch is very clear. First, it does not result in unnecessary merge commits, and second, the commit history of the branch does not result in forks, only a very clear linear history, and you can clearly see each commit.

But the nature of Rebase poses some risks. The important thing to remember is that you should never rebase on a public branch! Rebase on a cooperative branch can be dangerous because it rewrites the history of the branch or even loses code submitted by others. So be sure to confirm before rebase.

Second, unlike merge, rebase does not retain the merge context. In fact, rebase commits are already different from the original commit (the COMMIT ID is different), and the commit order is likely to be out of order, making it impossible to determine the merge context. If we keep merging with Rebase in the main trunk branch of our code base, it’s hard to tell what code changes have been made to a release live.

Conflict resolution

One of the most common problems encountered in multi-person collaboration is conflict arising from merging.

When you modify a file during development, the following three situations may occur:

• A and B modify the code of different files;
• A and B modify the code of the same file, but not the same part of the code;
• A and B modify the same part of the same file code;

In the first two cases, Git does an automatic merge without causing conflicts. It is the third case that requires conflict resolution.

When using Git merge, you need to modify the conflicting files, save them, and then run git add, git commit, and git push in sequence. The merge operation can be completed by resolving only one conflict.

git add filename
git commit -m "commit"
git push
Copy the code

With Git rebase, if there is a conflict, you need to resolve the conflict and save the file.

git add filename
git rebase --continue
Copy the code

Git rebase –continue may cause another conflict. Then we need to continue resolving the conflict (repeat the above steps) until there are no more conflicts, and we can commit the code.

conclusion

Git merge git rebase

Both have their advantages and disadvantages, so we should choose different strategies based on the size of the team and development model. Personally, in the case of multi-person collaboration, everyone should pull out his or her own feature branch for development, and unify the branch into the development environment through Rebase after development. Because branching is active during development (there is often a lot of merging code, deploying dev environments, and so on), rebase merging ensures the integrity of each feature and maintains a linear history without worrying too much about the risk of error.

When performing operations on nodes such as raising or going online, merge is recommended to leave the context of merging branches, so that all changes caused by the raising or going online can be clearly known, and problems can be traced easily.