Merging changes is crucial in collaborative software development, especially with version control systems. A critical aspect of an efficient development workflow is deciding when to merge changes. Merging too often can cause frequent conflicts and instability, while delaying merges can lead to large, complex changes that are difficult to integrate. This article details steps, methods, and considerations for a smooth merge.
Understanding Application Version Merging
In application versioning, merging is the act of integrating one branch into another. All elements—modules, components, layouts, module settings—in the current (source) branch are inserted (merged) into the target branch. If any inserted elements create conflicts, like modifications to existing components, then they must be reviewed and resolved in the merge conflict review process. Creators review merge conflicts using the Merge tool, choosing whether to keep the new configuration or reject it from the merge.
When to Merge
Creators must know when to merge based on the branching strategy they’ve chosen.
Learn more about branching strategies in our Branching Strategies article.
Click on the tabs below to learn when to merge by strategy:
Trunk-Based Development
Because Trunk-Based Development operates with a single branch, you do not need to complete any merges. Instead, the main branch is published as a new version at intervals dictated by your team’s application and goals. If you make an experimental branch and resolve an issue, you should reapply the change to the main trunk instead of merging to avoid introducing issues. That said, you should confer with your team to ensure you do not disrupt anyone else’s work.
Hotfixes
If you are using the trunk-based development strategy, you should use the following procedure for hotfixes:
Create a hotfix branch from the latest production version.
Make the required changes.
Publish a hot fix version from the branch.
Merge the hotfix version into trunk.
Feature Branching
In Feature Branching, you might need to merge once your feature is complete, tested, and ready to be published to a version. If additional versions have been published with other features between the time a branch was made and when it’s ready to publish, you’ll merge the latest version into your branch before publishing to ensure those other updates are preserved in the published version. Failing to merge these changes will result in a version that does not contain all of the features completed by others. For larger projects, establishing regular merge intervals can help you keep branches synchronized and reduce the complexity of individual merges.
Hotfixes
If you are using the feature branching strategy, you should use the following procedure for hotfixes:
Create a hotfix branch from the latest production version.
Make the required changes.
Publish a hot fix version from the branch.
Merge the hotfix version into each feature branch.
Release Branching
This strategy requires the branches of branches feature and we do not recommend its implementation without branches or branches. This feature is schedule for the 7.30 Unqork release. View the release calendar and release notes for information on branches of branches availability.
Release Branching requires a similar merge pattern to feature branching. It differs in that, when a feature is completed, tested, and ready to be published, instead of being published directly from the feature branch, it should be merged into the appropriate release branch. Maintaining a release branch lets teams ensure all new features and updates are working together as they are added. You must keep your branch in sync with the release branch; otherwise, large conflicts might become cumbersome.
Hotfixes
If you are using the feature branching strategy, you should use the following procedure for hotfixes:
Create a hotfix branch from the latest production version.
Make the required changes.
Publish a hot fix version from the branch.
Merge the hotfix version into each feature branch and the associated release branches.
Dealing with Merge Conflicts
There are two types of changes in a merge:
Auto-Resolved: The changes are compatible and able to be merged. In this case, you can only review the changes.
Conflict: The changes need manual resolution because they are not compatible.
Conflicts arise when multiple developers work on overlapping sections of the application simultaneously, or when changes made in one branch contradict or override those in another. Resolving conflicts is a critical skill for effective merging because it determines how your output branch will behave once the changes are combined.
In the Branch & Version Management page, Unqork provides a clear view of the differences between branches or between a branch and a version. When a merge is initiated, the system highlights the conflicting components or properties in the Merge Tool, letting you review both versions side by side. You can then decide whether to:
Accept one change (keeping the source or target branch’s version).
Combine elements.
Manually adjust the configuration to preserve the intended functionality from both branches.
Learn more about merging branches in our Merge Tool article.