After the work branch is developed and tested, the team usually has a few options on how to merge the work branch back into the main branch. What merger strategy does your team use? In this article, we will introduce several merger strategies, along with a brief review of them. So that at the end of this article, you can choose the right merge strategy for your team.

Git Merge Strategy

Whenever we try to merge two branches, we need to use the merge operation. Git attempts to trace the last commit point in the history of both branches back to the commit point. Git has several different methods for finding this co-commit, and these methods are known as merge strategies. Once Git finds the co-commit, it creates a new “merge commit,” where the content of the merge commit is the merge of the different content between the two branches. In fact, a merge commit is itself a different commit, but this time it comes from two parent commits.

The git merge command automatically selects a merge mode if no explicit merge policy is specified. When you execute git merge and git pull, you can pass a -s option (which stands for strategy). Following the -s option is the name of the specified merge policy. If not specified, Git will choose the most appropriate merge strategy based on the branch involved in the merge operation. The following is a description of the optional values for the merge policy options.

Recursive

git merge -s recursive branch1 branch2
Copy the code

The recursive merge strategy operates at the top of both branches. The recursive strategy is the default merge strategy when the pull or merge commands are used to merge branches. In addition, this merge strategy can handle the renaming operation during the merge, but cannot handle the copied files perfectly.

Resolve

git merge -s resolve branch1 branch2
Copy the code

The strategy uses a three-way merge algorithm to resolve the differences between two branches. This approach carefully detects ambiguities in cross merge situations and is generally considered safe and efficient.

Octopus

git merge -s octopus branch1 branch2 branch3 branchN
Copy the code

When more than two branches need to be merged, the Octopus policy is called the default policy for merging. If a conflict that needs to be resolved manually occurs during a merge, Octopus Merge rejects the merge. This strategy is often used to merge a bunch of development branches that have similar functions.

Ours

git merge -s ours branch1 branch2 branchN
Copy the code

The ours policy can be used to merge N different branches. The result of the merge is always benchmarked against the HEAD pointer of the current branch. The policy name “ours” also literally implies that changes from other branches will be ignored during the merge. This policy is used to merge development branches with similar content, ignoring the content of the merged branch and keeping only the merged record.

Subtree

git merge -s subtree branchA branchB
Copy the code

This policy is an extension policy based on recursive policy. When merging branches A and B, if branch B is A subtree of branch A, branch B needs to update the update record of subtree B first and reflect it in branch A. This series of updates is also based on the common ancestor of A and B.

Types of Git merge strategies

Explicit merger

Explicit merge is the default merge type. “Explicit” means that a merge commit is intentionally created when a merge occurs. The merge references created are explicit in the commit history and clearly show the point at which the merge was performed. The content of the merge commit is also explicit, because the history of the merge commit makes it clear which commit came from which branch. Some teams avoid explicit merges because of the argument that merge proposals add too much “noise” to the commit history.

Implicit merging is implemented through rebase or fast-forward

Recursive options related to the merge policy

In the Recursive policy described above, it also has a set of action options of its own

ours
Copy the code

Do not confuse this option with the OURS merge policy. The ours merge policy ignores all changes to the merged branch, while the ours option in recursive ignores changes to the merged branch only in case of conflicts during the merge and automatically preserves changes to the target branch unconditionally. When no conflicts occur during the merge, changes from the merged branch are automatically merged into the target branch.

theirs
Copy the code

As opposed to ours option. The possessive “option will unconditionally choose to use the contents of the merged branch and discard the changes to the target branch when a conflict occurs.

patience
Copy the code

Patience chose to spend more time merging lines of code more precisely to avoid errors and missed lines.

diff-algorithim
ignore-*
​
    ignore-space-change
    ignore-all-space
    ignore-space-at-eol
    ignore-cr-at-eol
Copy the code

The options above are policies for how to handle whitespace characters.

renormalize
Copy the code

This runs a virtual checkout and checks in all three phases of the file when resolving a three-way merge.

no-normalize
Copy the code

The renormalize option is disabled. This overrides the merge.renormalize configuration variable.

no-renames
Copy the code

Disable renaming detection. This overrides the merge.renames configuration variable.

find-renames=n
Copy the code

To enable rename detection, you can set the similarity threshold. This is the default value. This overrides the merge.renames configuration variable.

subtree
Copy the code

This option is a more advanced form of a subtree strategy, where the strategy guesses how two trees must be shifted to match each other when merged. Instead, the path specified is prefixed (or stripped from scratch) to make the shapes of the two trees match.