We just started using git for our production code, and we are running into a slight issue in our workflow. We need to figure out how to handle general code improvements / technical debt fixes that come up while working on a feature.
The workflow we have adopted is to use 'develop' as the main integration branch and develop all features on feature branches off of 'develop'. When a feature is complete, the developer creates a pull request and everyone reviews it to provide comments before it is merged back into develop. This seems to be working very well.
The issue we have is that during routine development on a feature, the developer may end up wanting to modify/refactor some common code to improve the system or clean up some technical debt. This change is valuable, but not directly tied to the feature under development.
Based on our workflow, it should really be done on a different branch that goes through it's own pull request and code review before getting into develop. If we have them do this though, how can they get the change back over onto their feature branch in the meantime while they wait for the full code review to happen and the code to get merged into develop.
The ideas we have are:
1) cherry-pick the changes from the 'refactorX' branch into our feature branch. Continue developing and let git (hopefully) figure out when we merge back to develop that it already has the change from the refactor branch.
2) Merge the 'refactorX' branch into our feature branch and continue development. (note: the branch off develop for 'refactorX' may have been later in the history of develop, so we think this may have problems)
3) Some other smarter option we don't know yet. :)
What we are looking for is some best practice guidance on how to handle this part of the workflow. After talking about it more we know that it will come up frequently and we want to find a smooth and efficient way to handle it in our workflow.
Any recommendations?
A third option is for the developer to rebase all of their feature branches onto the branch which has been refactored (so the refactoring changes are incorporated in all of their work). You then make sure that the refactoring branch is reviewed first and merge that back into the development branch. All of the feature branches will then be based off development and you can merge them in as you would normally (i.e. merge one, rebase the others onto development, repeat).
In ASCII art, prior to reviewing refactoring:
--- development
\
--- refactoring
\
--- feature1
--- feature2
And afterwards:
------ development|refactoring
\
--- feature1
--- feature2
Then, if you finish feature1 and merge it in:
------ refactoring --- development|feature1
\
--- feature2
You rebase feature2 onto development again:
------ refactoring --- development|feature1
\
--- feature2
And then you can merge feature2 in as usual:
------ refactoring --- feature1 --- development|feature2
It appears that you are trying to avoid merging the develop branch back into the feature branch. It is beneficial to avoid this step, but sometimes it is necessary, especially in situations such as this.
A technique that we are starting to use also is git rebase --onto
. Instead of merging the develop branch into the feature branch, the feature branch can be moved to the end of the develop branch in order to acquire the new features.
When you are using a central repository, it's probably most useful to create a new feature branch name. For example we append -v2 onto the new branch name.
The typical move process might look like
git checkout feature
git branch -m feature-v2
git rebase --onto develop develop
git push -u origin feature-v2
Now you have new code in your feature branch but haven't merged the develop branch into the feature branch.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With