We're adopting a new branching policy to work with Agile and to enable us to release on a feature by feature basis, whereby we have a master
branch and a QA
branch as perpetual branches. Nightly builds will be based on QA
and releases will come from master
. Developers will create a feature branch for each story. All feature branches are to be branched off master
, and then merged into QA
for testing, followed by a merge of the feature branch into master
for subsequent release. This is fine, until the following scenario:
feature/RodsFeature
, carried out some work and merged into QA
(but not yet master
)feature/JanesFeature
, carried out some work and is now attempting to merge into QA
QA
by Rod's merge of feature/RodsFeature
If Jane were to bypass QA and merge feature/JanesFeature
into master
, there'd be no conflicts as feature/RodsFeature
is not yet in master
. However, Jane must merge into QA
for obvious reasons. In order to resolve the conflict, she could pull and integrate Rod's changes into her feature branch, resolve the conflicts and then carry out the merge - with the undesirable consequence that once she merges her feature branch into master
it'll also introduce Rod's changes which are still pending QA testing.
So - a workaround would be to resolve conflicts directly on the QA
branch, leaving Jane's feature branch intact for later merging into master
. However, this breaks code review policies, as merges should be approved by a peer - by doing this, she has merged into QA
locally and pushed to remote without any pull request or peer review.
What would be considered 'best practice' in this situation?
Check out Git Flow. It comes closest to what you're trying to accomplish.
Developers would branch their feature branch off the qa
branch (called develop
in Git Flow). complete their feature (regularly picking up the latest state of QA) and merge back to develop
whenever possible (a feature is complete or it is in a stable state or it is turned off).
What you run as a qa
branch would likely be the release
branch in Gitflow.
Any change to master is immediately merged back to develop
.
See also:
tl;dr: add a dev
branch to do pull requests of specific 'task' branches with the changes for code reviews.
On some team projects I've been on there was also a dev
branch to do "pull requests" on Github or some repository manager where a senior dev looks over what has changed and sees if that specific change is well-written etc.
In online repo host environments like Github, they have explicit ui showcasing the changes back to back with the original branch etc. After looking over a branch, the senior dev then moves it into the Dev branch to ultimately be hosted in a qa environment to be looked over by the end of the sprint.
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