If you’re working in a repository that contains more than one version of your code, then here’s an approach to manage adding a feature that should appear in multiple versions.
This will often happen with micro services, once a breaking change is introduced and all clients can’t immediately upgrade. This could also happen with a library that needs to support multiple versions of an underlying framework.
If there’s no build configuration with embedded versions in it, then this could be as simple as adding the feature starting on one version’s branch, and then merging the commit into both version’s branches.
But more often then not, there will be differences between the 2 branches to generate the appropriate versions, and this will be embedded in build files. Think Maven pom.xml files or Gradle build.gradle files.
This post describes an approach that allows for using mandatory Pull Requests through something like Github, Gitlab or Bitbucket.
First, add the new feature to a branch originating on one of the version’s master branch. In this case, it was added to Version 1’s master branch.
Once the feature has been developed, create a Pull Request and once approved, merge it into Version 1’s master branch.
Odds are it won’t be possible to create a Pull Request for the feature branch into master-v2 as there will likely be conflicts in the build configuration.
In order to overcome this, we will have to take some control over the merge process.
Create a new branch rooted at master-v2. Call it something like feature/merge-add-stuff. Then merge feature/add-stuff into feature/merge-add-stuff, resolving any conflicts that occur. Remember that this is effectively a merge into the master-v2 branch, so any conflict resolution should be to ensure the code works for Version 2.
Perform any tests, and any additional fixups required to incorporate this change into master-v2. I leave it to you if you want to use
commit --amend so that the merge looks like it was done in one go, or if you wish to add fixups as new commits. I prefer the former, but that’s a team decision.
Once all conflicts are resolved, push the feature/merge-add-stuff branch to your central server, and create a Pull Request from feature/merge-add-stuff to master-v2.
Once it is approved, merge it into master-v2, and delete the feature/add-stuff branch.
Ideally, your tool will allow for a fast-forward merge, so then it will appear as if you directly merged feature/add-stuff into master-v2, rather than introducing an additional commit, but again, this is a team decision.