+1. Rebasing can really make the history much clearer when used correctly.
Colin On Tue, Aug 18, 2015 at 2:57 PM, Andrew Wang <andrew.w...@cloudera.com> wrote: > 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
