Shulou(Shulou.com)06/01 Report--

This article introduces what merge in git refers to. The content is very detailed. Interested friends can use it for reference. I hope it will be helpful to you.

In git, merge means "merge", and this command is used to merge two or more development histories together; the merge command can be used in git-pull to integrate changes in another code repository; it can also be used in a merge from one branch to another.

The operating environment of this tutorial: Windows7 system, Git2.30.0 version, Dell G3 computer.

Git-merge complete parsing

Git-merge of Git is a command that is frequently used in Git. Many people think that merging git is a very troublesome thing. If you are not careful, you will encounter the problem of losing code, so you will be put off by git. This paper gives a complete and detailed introduction to the git-merge command based on Git 2.8.2, especially on the problem of code loss caused by cross-merging. At the end of the article, I give my own suggestions, hoping to help the users of git. The content introduced in this article is based on Git 2.8.2

The git-merge command is an operation that merges two or more development histories, usually written as git merge.

Summary of 1.git-merge related option parameters 1.1

In the git-merge command, there are three usage parameters:

Git merge [- n] [--stat] [--no-commit] [--squash] [--[no-] edit] [- s] [- X] [- S []] [- [no-] rerere-autoupdate] [- m] [...]

Git merge HEAD...

Git merge-abort

Introduction to 1.2git-merge

The git-merge command is used to merge from the specified commit (s) to the current branch.

Note: the specified commit (s) here starts from these historical commit nodes until the current time of separation.

The git-merge command serves the following two purposes:

Used in git-pull to integrate changes in another code repository (that is, git pull = git fetch + git merge)

Used for merging from one branch to another

Suppose the following history node exists, and the current branch is "master":

Then the git merge topic command will reproduce the node that is separated after the common node (E node) on the master branch (that is, the A B C node of the topic branch) on the master branch until the current commit node (C node) of the topic branch, and at the top of the master branch. And create a new node along the master branch and the topic branch to record the result of the merge, with the information that the user describes the change of the merge.

That is, the H node, C node and G node in the following figure are all the parents of the H node.

1.3git merge HEAD... Command

This command exists for historical reasons, it should not be used in the new version, git merge-m should be used. Make a substitution

1.4git merge-- abort command

This command is used only if there is a conflict after the merge. Git merge-- abort will abandon the merge process and try to rebuild the pre-merge state. However, if there are files that are not commit at the beginning of the merge, git merge-- abort will not be able to reproduce the pre-merge state in some cases. (especially if these non-commit files will be modified during the merge)

Warning: running git-merge with a large number of non-commit files can easily get you into trouble, which will make it difficult to fall back in a conflict. Therefore, the existence of non-commit files when using git-merge is very discouraged. it is recommended that you use the git-stash command to temporarily store these non-commit files, and use git stash pop to restore these non-commit files after resolving the conflict.

two。 Parameters.

This section describes the parameters used in the git-merge command

2.1--commit and-- no-commit

The commit parameter causes the merged commit node to produce a merged result. This parameter can override-- no-commit.

-- the no-commit parameter allows users to review and modify the merge results before committing in order to prevent the merge from failing to commit automatically after the merge.

2.2--edit and-e and-- no-edit

-- edit and-e are used to invoke the editor to further edit the automatically generated merge information before a successful merge and commit. Therefore, the user can further explain and judge the result of the merger.

The no-edit parameter can be used to accept information about automatic merging (which is generally discouraged).

If you have given the-m parameter when merging (described below), it is still useful to use-- edit (or-e), which will further edit the contents of-m in the editor.

Older versions of nodes may not allow users to edit merge log information.

2.3--ff command

-- ff is the fast-forward command. When merging using fast-forward mode, a new commit node will not be created. By default, git-merge uses fast-forward mode.

For a detailed explanation of the fast-forward pattern, see my other article: the "about fast forward" section of a successful Git branching model.

2.4--no-ff command

Even if you can use fast-forward mode, create a new merge node. This is the default behavior when git merge is merging a tag.

2.5--ff-only command

Unless the current HEAD node is already up-to-date (updates point to the latest node) or can be merged using fast-forward mode, the merge will be rejected and a failed state will be returned.

2.5-- log [=] and-- no-log

-- log [=] will contain log information for up to n merged commit nodes in addition to branch names when the merge is submitted.

-- no-log does not list this information.

2.6-- stat,-n,-- no-stat command

The stat parameter will display the status of file differences at the end of the merge result. The status of file differences can also be configured in merge.stat in the git configuration file.

Conversely, the-n,-- no-stat parameter will not display this information.

2.7--squash and-- no-squash

-- squash when a merge occurs, from the other branch node after the common ancestor node of the current branch and the other branch to the top node of the other branch will be compressed together, and the user can submit after review to generate a new node.

Note 1: this parameter conflicts with-- no-ff

Note 2: the result of using this parameter is similar to submitting a new node in the current branch. This parameter is very useful in some cases, such as when using Git Flow (for Git Flow, please refer to a successful Git branch model). When a functional branch is developing a functional requirement, the developer may submit a large number of meaningless nodes locally, and when it needs to be merged into the develop branch, it may only need to use a new node to represent the modification of this long list of nodes. At this point-- the squash command will work. In addition, if multiple submissions of functional branches are not trivial but meaningful, it is more appropriate to use the-- no-ff command.

-- no-squash does just the opposite.

2.8s and-- strategy=

-s and-- strategy= are used to specify the strategy for the merge. By default, if this parameter is not specified, git uses the default merge policy as follows:

When the merged node contains only a single parent node (such as in fast-forward mode), the recursive strategy is adopted (described below).

When the merged node has multiple parent nodes (such as in no-fast-forward mode), the octopus strategy is adopted (described below).

2.9-X and-- strategy-option=

Specify the specific parameters for the policy at-s (described below).

2.10-- verify-signatures,-- no-verify-signatures

Used to verify that the merged nodes have GPG signatures, and ignore those nodes that do not have GPG signature verification in the merge.

(the following quote is from a reprinted article. Because I could not find the original author, I cannot provide the original author information and the original text link. If there is any infringement, please let me know by private message or comment. I will delete the following quotation.)

GPG is encryption software, you can use the public key generated by GPG to securely spread your files and code on the Internet.

Why is it safe? Repo developed by Google as an example, repo is using GPG verification, each milestone tag with GPG encryption verification, if you want to make changes in milestone v1.12.3, modify after the deletion of the tag, and then create a tag of the same name to point to your modification point, this must be possible. However, when you clone your modified project again, you will find that your changes to this milestone tag are not approved and validation fails, resulting in your changes not being implemented properly here. This is the role of GPG validation, which ensures that the milestones set by the project author (private key holder) will not be modified by others. In that case, it can be said that the author's code is safely propagated.

Why is there such a need? A project from development to release, and then to the later update iteration, there must be a number of stable versions and development versions (there are unstable factors). As the initiator and owner of the project, he or she has the right to define a stable version approved by him or her, and this stable version will not allow other developers to make changes. Also take Google's repo project as an example. The project owner defines point An in the development process of the project as stable version v1.12.3, then users must use the project and product generated by point An after downloading v1.12.3, even if other developers can reassign v1.12.3 locally to their modified point B, but the final modified version is used by users. There will be a problem that GPG signature verification fails, that is, such a change is not valid.

2.11-summary,--no-summary

And-- stat are similar to-- no-stat and will be removed in future versions.

2.12Q and-- quiet

Silent operation, no merge progress information is displayed.

2.13-v and-- verbose

Displays detailed merge result information.

2.14-progress and-no-progress

Toggles whether to display progress information for the merge. If neither is specified, the information will be displayed on the connected terminal when a standard error occurs. Note that not all merge strategies support progress reporting.

2.15 Mutual [] and-- gpg-sign [=]

GPG signature.

2.16-m

Sets the submission information used to create the merge node.

If the-- log parameter is specified, the short log of the commit node will be appended to the submission information.

2.17 no--[no-] rerere-autoupdate

Rerere, or reuse recorded resolution, reuses the documented solution. It allows you to ask Git to remember how to resolve a block conflict so that the next time you see the same conflict, Git can automatically resolve it for you.

2.18--abort

Discard the current process of merging conflicts and try to rebuild the pre-merge state.

3. Other concepts about merging 3.1 Detection before merging

When merging external branches, you should keep your branches clean, otherwise there will be a lot of trouble when there is a merge conflict.

To avoid recording irrelevant files during merge commit, the git-pull and git-merge commands will stop if there are any uncommitted files registered in the HEAD node that index points to.

3.2fast-forward merger

In general, branch merging results in a merge node, but in some special cases. For example, when calling the git pull command to update the remote code, there is no need to generate a merge node if the local branch does not have any commits. In this case, there will not be a merge node, and the HEAD points directly to the updated top code, and the strategy for this merge is fast-forward merge.

3.3 merger details

In addition to the fast-forward merge mode mentioned above, the merged branch will be tied to the current branch through a merge node, which has both the top node of the current branch before the merge and the top node of the other branch as the parent node.

A merged version will make the changes of all relevant branches consistent, including commit nodes, HEAD nodes and index pointers, and node trees will be updated. As long as the files in these nodes do not overlap, the changes to these files will be changed and updated and saved in the node tree.

If these changes cannot be significantly merged, the following occurs:

The node pointed to by the HEAD pointer remains unchanged

The MERGE_HEAD pointer is placed on top of the other branches

The merged clean paths are updated in both the index file and the node tree.

For collision paths, the index file records three versions: version 1 records their common ancestor node, version 2 records the top of the current branch, that is, HEAD, and version 3 records MERGE_HEAD. The files in the node tree contain the results after the merge program is run. For example, the three-way merging algorithm will produce conflicts.

Nothing else has changed. In particular, your previous local changes will remain as they are.

If you try a merge that leads to a very complex conflict and want to start over, you can use git merge-abort

About the three-way merging algorithm:

The three-way merging algorithm is a way to solve the conflict. When a conflict occurs, the three-way merging algorithm will obtain three nodes: the B node of the local conflict, the C node of the other branch, and the common nearest ancestor node An of the Bline C node. The three-way merging algorithm merges according to these three nodes. The specific process is that the BMague C node is compared with the A node. If a file of the BMague C node is the same as that of the A node, then there is no conflict; if only one of the B or C nodes changes compared with the A node, then the file will adopt the changed version. If B and C and A have changed, and the changes are not the same, then you need to merge them manually; if both B and C have changed and the changes are the same, then there will be no conflict and the changed version will be adopted automatically. After the final merger, there will be a D node, which has two parent nodes, B and C, respectively.

3.4 merge tag

When merging a tag, Git always creates a merged commit, even if fast-forward mode can be used at this time. The template of the submission information is preset to the information of the tag. If the tag is signed, the signed detection information will be appended to the submission template.

3.5 how is the conflict expressed

When a merge conflict occurs, this section is represented by. The part before = is the case on this side of the current branch, and the part after = is the case of the other branch.

3.6 how to resolve conflicts

After seeing the conflict, you can choose the following two ways:

Decided not to merge. At this point, the only thing to do is to reset the index to the HEAD node. Git merge-- abort is used in this case.

Resolve the conflict. Git marks the conflict, then uses git add to join the index after the conflict is resolved, and then uses git commit to generate merge nodes.

You can use the following tools to resolve conflicts:

Use the merge tool. Git mergetool will invoke a visual merge tool to handle conflict merging.

View the differences. Git diff will show the three-way difference (the three-way comparison algorithm used in the three-way merge).

View the differences of each branch. Git log-- merge-p will show the difference between HEAD version and MERGE_HEAD version.

View the pre-merge version. Git show: 1: the file name shows the version of the common ancestor, git show: 2: the file name shows the HEAD version of the current branch, and git show: 3: the file name shows the MERGE_HEAD version of the other branch.

4. Merger strategy

Git can specify the merge policy by adding the-s parameter. Some merge strategies even have their own parameter options, and the parameter options for these merge strategies are set through-X. (don't forget that merging can happen in git merge and git pull commands, so this merge strategy also applies to git pull.)

4.1resolve

Just use the three-way merge algorithm to merge the top nodes of the two branches (such as the current branch and the other branch you pull down). This merging strategy follows the three-way merging algorithm, which is carried out by the HEAD nodes of two branches and the common child nodes.

Of course, what really bothers us is the situation of criss-cross merge. The so-called cross-merge refers to the situation where there are multiple common ancestor nodes, for example, when two branches are merged, it is very likely that there are two common ancestor nodes. At this time, it is impossible to merge according to the three-way merging algorithm (because the common ancestor nodes are not unique). The resolve strategy deals with cross-merge issues like this, see "Version Control with Git" here:

In criss-cross merge situations, where there is more than one possible merge basis, the resolve strategy works like this: pick one of the possible merge bases, and hope for the best. This is actually not as bad as it sounds. It often turns out that the users have been working on different parts of the code. In that case, Git detects that it's remerging some changes that are already in place and skips the duplicate changes, avoiding the conflict. Or, if these are slight changes that do cause conflict, at least the conflict should be easy for the developer to handle

There is more than one merge datum point (common ancestor node) in the case of cross-merge, and the resolve strategy works like this: select one of the possible merge datum points and expect this to be the best result of the merge. Actually, it's not as bad as it sounds. Usually, users modify different parts of the code, in which case, many merge conflicts are redundant and repetitive. When merging with resolve, conflicts are easier to deal with, and there are very few cases in which code is actually lost.

4.2recursive

Use only the three-way merge algorithm to merge two branches. Unlike resolve, in the case of cross-merging, this merging method is called recursively. Starting from the different nodes of the two branches after the common ancestor node, the three-way merge algorithm is called recursively to merge. If there is a conflict, then the file no longer continues to merge and directly throws the conflict; other files that do not cause conflicts will be executed all the way to the top node. In other fields, this method can also detect and handle operations involving the modification of file names. This is the default merge operation for git merge and pull code.

The recursive merge strategy has the following parameters:

4.2.1 ours

This parameter forces the version of the current branch to be used automatically when a conflict occurs. This merging approach will not cause any confusion, and even git will not check for conflicting content contained in other branch versions. This way will discard any conflicting content in the other branch.

4.2.2 theirs

Just the opposite of ours.

Both the theirs and ours parameters are suitable for merging binary conflicts.

4.2.2 patience

With this parameter, git merge-recursive takes some extra time to avoid missing merging unimportant lines (such as function parentheses). If the separation between the current branch and the version branch of the other branch is very large, this merge method is recommended.

4.2.3 diffcomm = [patience | minimal | histogram | myers]

Tell git merge-recursive to use a different comparison algorithm.

4.2.4 ignore-space-change, ignore-all-space, ignore-space-at-eol

Treats space conflicts according to the specified parameters.

If the other party's version only adds a space change, then the conflict merge uses our own version.

If our version contains spaces, but the other party's version contains a large number of changes, then the conflict merge uses the other party's version

Adopt the normal treatment process

4.2.5 no-renames

Turn off rename detection.

4.2.6subtree [=]

This option is an advanced form of the subtree merge strategy and will guess how the two node trees will move during the merge. The difference is that the specified path is removed at the beginning of the merge so that other paths can match when looking for a subtree. (for more information on the subtree merger strategy, see below)

4.3octopus

This merge method is used for more than two branches, but the merge is rejected when there is a conflict that requires a manual merge. This merging method is more suitable for bundling multiple branches together, and it is also the default merge strategy for multi-branch merging.

4.4ours

In this way, any number of branches can be merged, but the merge result of the node tree is always the part of the current branch that conflicts. This approach can be very efficient in replacing the old version. Note that this approach is different from the ours parameter under the recursive policy.

4.5subtree

Subtree is a modified version of the recursive policy. When merging tree An and tree B, if B is a subtree of A, B first adjusts to match A's tree structure instead of reading the same node.

When using the three-way merge strategy (the default recursive policy), if a file (or a line of code) changes in both the current branch and the other branch, but later falls back in one of the branches, then the fallback change will be reflected in the result. This may confuse some people. This is because during the merge process, git only focuses on the common ancestor node and the HEAD nodes of the two branches, rather than all the nodes of the two branches. Therefore, the merge algorithm will treat the fallback part as unchanged, so that the merged result will become the changed part of another branch.

So much for sharing what merge refers to in git. I hope the above content can be helpful to you and learn more knowledge. If you think the article is good, you can share it for more people to see.

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.