Last Updated: January 3, 2026
Merging code is at the heart of collaborative software development. But beyond the basics of merging, the merge strategy used can greatly influence the stability and clarity of your project’s history.
Understanding the available strategies in Git allows developers to make informed decisions that align with their workflow and project requirements.
Merge strategies dictate how Git combines multiple branches. When you merge, Git applies changes from one branch onto another, and the strategy determines how this happens.
Each strategy has its own approach:
Understanding these strategies empowers you to choose the right one for your workflow, especially in complex or multi-branch scenarios.
The recursive strategy is Git's default merge strategy when merging two branches. It is designed to handle complex merge situations, particularly those that involve multiple branches diverging significantly over time.
When you employ the recursive strategy, Git creates a new merge commit that combines the histories of both branches. Here’s how it works:
This strategy is effective for most scenarios, but it does have nuances. If the branches have diverged significantly, you may need to resolve conflicts manually, as previously covered.
The recursive strategy automatically handles conflicts and attempts to merge as much as possible. If conflicts arise, Git will prompt you to resolve them.
The octopus strategy is designed for merging more than two branches at once. It is most effective in scenarios where you have multiple feature branches that need to be merged into a main branch simultaneously.
When using the octopus strategy, Git combines the changes from all specified branches. However, it can only handle conflicts that are non-overlapping. If any of the branches have conflicting changes, the octopus merge will fail, and you will need to resolve those conflicts manually.
Here’s how you might use the octopus strategy:
The octopus strategy is ideal for integrating multiple feature branches that are independently developed and can be merged without conflict. Always ensure that the branches do not have conflicting changes.
The resolve strategy is a simpler merging approach and is typically used in scenarios with straightforward changes. This method is limited to two branches and is less sophisticated than the recursive strategy.
The resolve strategy performs a basic three-way merge, but it does not attempt to resolve conflicts as comprehensively as the recursive strategy. If conflicts occur, you will need to resolve them manually.
The resolve strategy is not recommended for complex merges. Use it in simpler scenarios where you are confident that conflicts will be minimal or nonexistent.
The subtree strategy is particularly useful when you want to incorporate one repository as a subdirectory within another repository. This is common in situations where you want to combine multiple projects or libraries into a single repository while keeping their histories intact.
The subtree strategy allows you to merge a remote repository into a specific subdirectory of your current project:
This command adds a remote repository and merges it into your current branch. The --allow-unrelated-histories flag is crucial when merging two unrelated repositories.
If you have a library repository you want to integrate into your main project as a subdirectory, the subtree merge strategy allows you to maintain the library's commit history while keeping it organized within your main project.
Choosing the appropriate merge strategy is crucial for maintaining a clean and understandable project history. Here are some considerations:
Understanding the strengths and weaknesses of each strategy helps you navigate merges effectively.
To further enhance your merging process, consider the following best practices:
By following these practices, you can streamline your merging process and improve collaboration within your development team.
Now that you understand the various merge strategies available in Git and how to apply them effectively, you are ready to explore how to abort a merge when things go wrong.
In the next chapter, we will look at the process of safely stopping a merge and recovering from mistakes, ensuring that your development process remains smooth and controlled.