hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Colin P. McCabe" <cmcc...@apache.org>
Subject Re: [VOTE] Using rebase and merge for feature branch development
Date Mon, 24 Aug 2015 17:59:16 GMT
+1

cheers,
Colin

On Mon, Aug 24, 2015 at 10:04 AM, Steve Loughran <stevel@hortonworks.com> wrote:
> +1 (binding)
>
>> On 21 Aug 2015, at 13:44, Andrew Wang <andrew.wang@cloudera.com> wrote:
>>
>> 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
View raw message