In a project, we always create branches to develop different features or requirements, and then merge back into the main branch when the features are complete. So how do you gracefully merge branches? If you’re intrigued, read on.

Build multiplayer development scenarios

1. Create a warehouse

// Initialize the repositorygit init
/ / create a.t xttouch a.txt
/ / create b.t xttouch b.txt // Add to the staging areagit add . / / submitgit commit -m 'initial' Copy the code

2. Create a feature branch

git checkout -b feature
Copy the code

3. Simultaneous development of two branches

Feature branch to develop new features for the next version, submitted twice, modified A.tuck file and B.tuck file respectively.


Master branch to develop this version of the function, also submitted twice, and modified the A.txt file and b.txt file.


The current branch situation is shown in the following figure. The characters above each node are the hash value of each commit. The header of the master branch is on the C5 node, and the header of the feature branch is on the C3 node.


In this case, the feature branch needs to be merged back to the master branch. There are two solutions:

  1. Merge feature branch directly on master branch;
  2. Rebase the feature branch first, then merge the feature branch on the master branch.

Here are two ways to explain them:

git merge

Git merge git merge git merge git merge git merge git merge

  1. Find the commit node C1, the most recent common ancestor of feature branch and master branch;

  2. Merge the latest commit node C3 on the feature branch with the latest commit node C5 on the master branch. If there is a conflict, resolve all conflicts at once, and then generate a new commit node C6.

  3. The git log can be used to view the sequence of commit times on the master branch.

The result of the above process is shown as follows:


The action commands in the project are as follows. Merging the workspace by merging all conflicts at once, and then committing a new commit.


Run the gitk command line, you can see the current branch on the interface as shown in the figure below. There is a new COMMIT.


git rebase

What this command does is obvious from its name: change the base point of the current branch. As for the feature branch, it is created from the C1 node of the master branch, so its base point is C1. If git rebase master is executed on the feature branch, the process is as follows:

  1. Select the latest commit node c5 from the current master branch and change the base point of feature branch to c5 node. ;
  2. If there is a conflict between the feature branch and the master branch, the conflict will be solved according to the commit time of the feature branch, and the hash value of the commit of the feature branch will be modified.
  3. The final view on the branch is a straight line, but there is a problem with historical commit overwriting.

The result of the above procedure is shown schematically below, where C2 ‘and C3’ indicate that the hash values have changed.


❝

It is important to note that you need to keep the master branch up to date when you perform the Rebase operation, otherwise there could be conflicts during the MerEGE merge and rebase would be useless.

❞

Now that we know the basic process, we can begin merging branches with the rebase command:

  1. Execute Git Rebase Master in your project, as shown below. Because both commits have conflicts, these conflicts need to be resolved in sequence in the Rebase workspace.

Run the gitk command on the feature branch, and you can see in the interface:


  1. After the feature branch completes the base change, switch back to the master branch and execute git merge feature to complete the merge operation.

Gitk is executed on the master branch, which has the following branch structure. You can see that the branches form a line and look very clean.


git stash

Sometimes the code on the branch has not been developed, and the branch needs to be merged. In this case, only:

  1. Execute git Stash to store your workspace contents, and then choose the two branches merge methods described above.

  1. Once the branch merge is complete, cut back to the branch you developed, execute git Stash pop to pop the workspace contents, and you can continue writing code happily.

conclusion

Git merge is a rough and most popular way of doing it. It ensures that every commit is in chronological order, but the branching diagram is messy and introduces a meaningless commit.

Git rebase is a very elegant line in the history commit record, but there is a risk of modifying the history commit, and the commit timeline is distorted when the Git log is viewing the log.

Individuals tend to use the Rebase approach because the cognitive cost of committing is there and comfortable to look at. If you have a large number of developers, merge them. After all, resolving conflicts one by one is boring

This article is formatted using MDNICE