hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrew Wang <andrew.w...@cloudera.com>
Subject [VOTE] Using rebase and merge for feature branch development
Date Fri, 21 Aug 2015 20:44:49 GMT
Hi common-dev,

As promised, here is an official vote thread. Let's run it for the standard
7 days, closing on Aug 28th at noon. Only PMC members have binding votes,
but of course everyone's input is welcomed.

If the vote passes, I'll put the text on the website somewhere as
recommended by Steve.

Previous discussion threads:

http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2bPWeV2Hk%2B67%3DDamWpVfLTM6nkjb_wG3n4%3DWAN890zqfA%40mail.gmail.com%3E

http://mail-archives.apache.org/mod_mbox/hadoop-common-dev/201508.mbox/%3CCAGB5D2aDXujQjwdmadVtg2-qrPAJeOgCS2_NHydv8jke8or1UA%40mail.gmail.com%3E

Proposal:

====

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.

====

Thanks,
Andrew

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message