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 its 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:
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.
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)
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?
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.