hadoop-common-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Colin McCabe <cmcc...@alumni.cmu.edu>
Subject Re: [DISCUSS] Proposal for allowing merge workflows on feature branches
Date Wed, 19 Aug 2015 19:04:00 GMT
+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.wang@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

Mime
View raw message