cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wido den Hollander <>
Subject Re: [DISCUSS] git rebase vs git merge in your feature branch?
Date Sun, 31 Mar 2013 10:54:48 GMT

On 03/30/2013 10:03 PM, John Burwell wrote:
> Alex,
> It seems appropriate to me to use both rebase and squashed commits.
> To my way of thinking, we should rebase when syncing features branches
> with master (or the eventual target branch) to keep the revision
> history of the eventual patch as concise as possible.  We should merge
> from feature branches to master (or the appropriate target branch)
> using a squashed commit to properly record the history if adding the
> feature to the branch in a coherent manner.

+1, with the note that it might be useful to squash the feature branch 
first to make life a bit easier.

So you don't get all these "short fix commits" in the master branch.

Features should be merged in cleanly so they can be traced back.


> Those are my thoughts,
> -John
> On Mar 30, 2013, at 11:21 AM, Alex Huang <> wrote:
>> Dave and I have talked on IRC at one point about this.  We both thought feature branch
merges should come in as a squashed commit because it's easier to see exactly what the changes
that merge branch brought in were and easier to revert.  Something to consider when talking
about this.
>> --Alex
>>> -----Original Message-----
>>> From: Edison Su []
>>> Sent: Friday, March 29, 2013 4:36 PM
>>> To:
>>> Subject: [DISCUSS] git rebase vs git merge in your feature branch?
>>> Hi all,
>>>      I am trying to review some feature branches, when I see merge requests
>>> coming from mailing list, one thing that makes code review almost unrealistic
>>> is that, developers tend to use "git merge" to master branch whenever
>>> rebase is needed. I don't know other people really do review feature branch
>>> or not, if so, how to review a feature branch, with several "merge branch
>>> "master""  on the feature branch. I really don't find a better way to do that.
>>>     If, all we use "git rebase" to master branch, then the code review will be
>>> much easier, at least, what kind of commits you did on the feature branch
>>> can be easily identified. For example, I worked on storage_refactor branch
>>> for a few months, with a lot of changes, before sending out merge request,
>>> there are only less than 10 commits on the branch, reviewer can use "git diff
>>> since..HEAD" to get all the changes.
>>>    Should we advocate "git rebase" in

View raw message