Integrating changes
During the lifetime of a project, the contents of individual elements diverge as they are branched and usually converge in a merge operation. Typically, the project manager periodically merges most branches back to the main branch to ensure that the code base maintains a high degree of integrity and to have a single latest version of each element from which new versions can safely branch. Without regular merges, the code base quickly develops a number of dangling branches, each with slightly different contents. In such situations, a change made to one version must be propagated by hand to other versions, a tedious process that is prone to error.
As a project manager, you must establish merge policies for your project.
Typical policies include the following:
- Developers merge their changes to the main branch. This can work well when the number of developers or the number of changed files is small and the developers are familiar with the mechanics of merging. Developers must also understand the nature of other changes they may encounter when the merge target is not the immediate predecessor of the version being merged, which happens when several developers are working on the same file in parallel.
- Developers merge their changes to an integration branch. This provides a buffer between individual developers’ merges and the main branch. The project manager or system integrator then merges the integration branch to the main branch.
- Developers must merge from the main branch to their development branch before merging to the main branch or integration branch. This type of merge promotes greater stability by forcing merge-related instability to the developers’ private branches, where problems can be resolved before they affect the rest of the team.
- The project manager designates slots for developer merges to the main branch. This is a variation on several of the mechanisms already described. It provides an additional level of control in situations where parallel development is going on.