Shulou(Shulou.com)05/31 Report--

This article mainly introduces the relevant knowledge of "merge command instance analysis of Git". The editor shows you the operation process through the actual case. The operation method is simple, fast and practical. I hope this article "merge command instance analysis of Git" can help you solve the problem.

How does it work?

Git merge merges multiple submission sequences into a unified submission history. In the most common usage scenarios, git merge is used to merge two branches. We will focus on this merge scenario in the rest of this document. In this scenario, the git merge accepts two commit pointers, usually the top commit of the two branches, and then goes back to the most recent joint commit of the two branches. Once the joint submission is found, Git creates a new "merge commit" to merge the respective submission sequences on the two branches.

For example, we have a functional branch derived from the main branch, and now we want to merge this functional branch back to the main branch.

Executing the merge command merges the specified branch into the current working branch, which we assume is main. Git decides its own algorithm for merge commits based on the two branches (discussed in more detail below).

A merged commit is different from a normal commit because a merged commit will have two parent submissions. When you create a merge commit, Git attempts to automatically merge two separate submission histories into one. However, when Git finds that a piece of data contains changes in the submission history of both sides, it will not be able to merge it automatically. This situation is known as a version conflict, where Git requires artificial adjustment to proceed with the merge.

Prepare for merger

Before the actual merge operation, some preparatory steps need to be taken to ensure that the merge process can proceed smoothly.

Confirm to receive the merged branch

Execute the git status command to check the status of the current branch and make sure that the HEAD points to the correct branch that receives the merge. If not, execute the git checkout command to switch to the correct branch. In our example, git checkout main is executed.

Get the latest remote submission

Ensure that both branches involved in the merge operation are updated to the latest status of the remote warehouse. Execute git fetch to pull the latest submission of the remote warehouse. Once the fetch operation is complete, the git pull command needs to be executed to ensure that the main branch is synchronized with the remote branch.

Merge

When the preparations mentioned above are complete, the merger can officially begin. Execute the git merge command, where is the name of the target branch that needs to be merged into the current branch.

Fast forward merger

Fast forward merging can be carried out when the submission history between the current working branch and the merge target branch is linear. In this case, instead of actually merging the two branches, Git just needs to move the top pointer of the current branch to the top of the target branch (that is, fast forward). In this case, the fast forward merge successfully merges the submission history into one place, after all, the submissions in the target branch are now included in the submission history of the current branch.

However, fast forward merging is not allowed when there are bifurcations between the two branches. When the submission history of the target branch relative to the current branch is not linear, Git can only use the three-way merging algorithm to decide how to merge the two branches. The three-way merge algorithm requires a dedicated commit to integrate the submission history of both sides. The term comes from Git. To generate a merged commit, you need to use three commits: the top commit of the two branches, and their common ancestor commit.

Although you can actually choose to use these different merge strategies, most developers prefer fast-forward merging (by using the rebasing command), especially for small feature development or bug repair; conversely, for merging functional branches that have been developed for a long time, they prefer to use a three-way merge. In the second scenario, the merged commit generated by merge remains in the submission history as a flag for the merger of the two branches.

Next, let's use the first example below to show how to do a fast forward merge. The following command creates a new branch, commits twice on the new branch, and then merges the new branch back to the main branch with a fast forward merge.

# Start a new featuregit checkout-b new-feature main# Edit some filesgit add git commit-m "Start a feature" # Edit some filesgit add git commit-m "Finish a feature" # Merge in the new-feature branchgit checkout maingit merge new-featuregit branch-d new-feature

The workflow in this example is usually used for the development of short-term functions, which is more regarded as a relatively independent development process, corresponding to a long-term functional development branch that needs to be coordinated and managed.

Also note that in this case Git does not issue a warning to the git branch-d command because the contents of new-feature have been merged into the main branch.

In some cases, although the submission history of the target branch is linear relative to the current branch and fast-forward merging can be done, you still want a merge commit to indicate that the merge has occurred in this commit, so you can use the-- no-ff option when executing the git merge command.

Git merge-no-ff

The above command merges the specified branch into the current branch, but always generates a merge commit (even if the merge operation can be fast-forwarded). This command is useful when you need to mark merge events in the warehouse's submission history.

Three-way merger

The next example is similar to the above, but because the main branch itself changes as the feature branch moves forward, a three-way merge is required when merging. This scenario is quite common in large functional development or when multiple developers are developing at the same time.

Start a new featuregit checkout-b new-feature main# Edit some filesgit add git commit-m "Start a feature" # Edit some filesgit add git commit-m "Finish a feature" # Develop the main branchgit checkout main# Edit some filesgit add git commit-m "Make some super-stable changes to main" # Merge in the new-feature branchgit merge new-featuregit branch-d new-feature

Note that in this case, because there is no way to move the top pointer of the main directly over the new-feature branch, Git cannot perform a fast forward merge.

In most actual work scenarios, new-feature should be a big feature, and the development process takes quite a long time, so it is inevitable that there will be new submissions on the main branch at the same time. If your functional branch size is as small as the example above, you can use rebase to base the new-feature branch on the main branch and then perform a fast forward merge. This also avoids excessive redundancy in the project submission history.

Resolve the conflict

If the two branches to be merged modify the same part of the file, Git cannot determine which version of the content should be used. When this happens, the merge process stops before the merge commit commits, giving the user the opportunity to fix these conflicts manually.

The great thing about Git's merger is that it uses the well-known workflow of editing / staging / submitting to resolve conflicts. When a merge conflict is encountered, executing the git status command lists which files contain conflicts and need to be resolved manually. For example, when both branches modify the same part of the hello.py file, you will see something like this:

On branch mainUnmerged paths: (use "git add/rm..." As appropriate to mark resolution) both modified: how hello.py conflicts are displayed

When Git encounters a conflict during the merge process, it edits the relevant content in the affected file and adds visual tags to show the different content of both parties in this part of the conflict. These visual markings are:. To find the exact location of the conflict, it is very easy to search for these visual markers in the file.

Here is some content not affected by the conflict > feature branch

Generally speaking, the content before the = tag comes from the branch that receives the merge, while the content after that comes from the branch to be merged.

Once the part of the conflict is found, the conflict can be corrected as needed. When you have finished fixing the conflicts and are ready to proceed with the merge, simply execute the git add command to add the files that have resolved the conflicts to the staging area and tell Git that the conflicts have been resolved. After that, execute git commit as you would normally submit the code to complete the merge commit. This process is exactly the same as submitting code under normal circumstances, which means that dealing with conflicts is a piece of cake for ordinary developers.

It should also be noted that merger conflicts can only occur in the three-way merger process, and there will be no conflicts in fast-forward mergers.

This is the end of the content of "merge Command instance Analysis of Git". Thank you for reading. If you want to know more about the industry, you can follow the industry information channel. The editor will update different knowledge points for you every day.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.