Hi all,
Our current git workflow is confusing with the *forward branches and
cherry-picking. Its hard to track on what all releases the commit has gone into
unless I do some git log greping. Also, as a contributor, I endup creating
patches for each branch as it doesn’t cleanly apply on different branches.
I think we should have some guidelines. Here is what I propose.
1. There should be branch for every major release(ex: 4.3.x, 4.4.x,
5.0.x,5.1.x) and the minor releases should be tagged accordingly on the
respective branches.
2. The branch naming convention is to be followed. Many branches with 4.3,
4.3.0, 4.3.1 etc. is confusing
3. Cherry-picking should be avoided. In git, when we cherry-pick, we have
two physically distinct commits for the same change or fix and is difficult to
track unless you do cherry-pick -x
4. There should always be a continous flow from release branches to master.
This doesn’t mean cherry-picking. They should be merged(either ff or no-ff)
which retains the commit ids and easily trackable with git branch --contains
* Every bug fix should always flow from minimal release uptill master. A
bug isnt fixed until the fix reaches master.
* For ex. A bug 4.2.1 should be committed to 4.2.x->4.3.x->4.4.x->master
* If someone forgets to do the merge, the next time a new commit is done
this will also get merged.
5. There should always be a continuous flow from master to feature branches.
Meaning all feature branch owners should proactively take any new commits from
master by doing a merge from master
6. The commits from feature branch will make to master on code complete
through a merge.
7. There should never be a merge from master to release branches
8. Every commit in LTS branch(targetted to any minor release) should have
atleast bug id and correct author information
* Cassandra's template: patch by <author>; reviewed by <committer> for
CASSANDRA-<ticket>
9. Once the release branch is created(after code freeze), any bug in jira
can be marked with fix version current release(4.4) only on RM's approval and
only they can go to the release branch. This can be done through jira and with
certain rules.(may be using jira vote?) this would save the cherry-picking time
and another branch maintenance.
Please add your thoughts/suggestions/comments.
Ref:
http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
https://www.youtube.com/watch?v=AJ-CpGsCpM0
~Rajani
