Hi common-dev, Based on the prior [DISCUSS] thread, I've put together a new [VOTE] proposal which modifies the branch development practices edified by the [VOTE] when we switched from SVN to git [1]. This new proposal modifies the third and fourth points of the earlier [VOTE], copied here for your convenience:
3. Force-push on feature-branches is allowed. Before pulling in a feature, the feature-branch should be rebased on latest trunk and the changes applied to trunk through "git rebase --onto" or "git cherry-pick <commit-range>". 4. Every time a feature branch is rebased on trunk, a tag that identifies the state before the rebase needs to be created (e.g. tag_feature_JIRA-2454_2014-08-07_rebase). These tags can be deleted once the feature is pulled into trunk and the tags are no longer useful. Said new proposal expands and modifies as follows: ==== Feature branch development can use either a merge or rebase workflow, as decided by contributors working on the branch. When using a rebase workflow, the feature branch is periodically rebased on trunk via "git rebase trunk" and force pushed. Before performing a force-push, a tag should be created of the current feature branch HEAD to preserve history. The tag should identify the feature and date of most recent commit, e.g. "tag_feature_HDFS-7285_2015-08-11". It can also be convenient to use a temporary branch to review rebase conflict resolution before force-pushing the main feature branch, e.g. HDFS-7285-rebase. Temporary branches should be deleted after they are force-pushed over the feature branch. Developers are allowed to squash and reorder commits to make rebasing easier. Use this judiciously. When squashing, please maintain the original commit messages in the squashed commit message to preserve history. When using a merge workflow, changes are periodically integrated from trunk to the branch via "git merge trunk". Merge conflict resolution can be reviewed by posting the diff of the merge commit. For both rebase and merge workflows, integration of the branch into trunk should happen via "git merge --no-ff". "--no-ff" is important since it generates a merge commit even if the branch applies cleanly on top of trunk. This clearly denotes the set of commits that were made on the branch, and makes it easier to revert the branch if necessary. "git merge --no-ff" is also the preferred way of integrating a feature branch to other branches, e.g. branch-2. ==== LMK what you think about the above, when we finalize I'll kick off a [VOTE]. Last time we did "Adoption of New Codebase" but this feels more like "Modifying bylaws," if it needs a [VOTE] at all. "Bylaws" is easier, since it's just a lazy majority of active PMC members rather than 2/3rds. If the eventual [VOTE] passes, I'll put it on the wiki somewhere for easier reference. I'll also expand said wiki page with discussion about merge vs. rebase based on the mailing list threads, since I think we've got some good information here. Best, Andrew [1]: http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201408.mbox/%3CCALwhT94Y64M9keY25Ry_QOLUSZQT29tJQ95twsoa8xXrcNTxpQ%40mail.gmail.com%3E
