Branching workflow

Branching workflow

[Javier Domingo]

Hi,

I have been using a very basic workflow for branching, features each
in a branch.

My branches would be:
- develop <= Main upstream branch
- feature/* fix/*  <= Feature and fix branches
- master <= Integration of the whole feature and fix branches

So I have now came up with a very difficult task. I just discovered
that one of those branches, lest call it feature/bad, is evil and is
making the integration branch (master) fail horribly.

In my workflow, I tend to merge develop (official updates) into my
feature branches, and them into master.

So now I have the big problem on how to undo all changes from
feature/fix. I have been told that one alternative workflow would be
to revert the last merge and remerge it into master, so that I have
always just one commit to revert if necessary (instead of the
monstrous quantity I have now to).

The workflow proposal should be in order of importance:
- Let me stay up-to-date with develop branch
- Easy to revert in master
- Have a clean history
- Easy to follow

I think I should be capable of doing some sort of merge/rebase
branching workflow to avoid having to do that. I have thought about
rebasing always the feature branches, and rebasing master into all of
them, but it seems pretty strange to me.

If anyone can give any advice, I would fully appreciate!

Javier Domingo Cansino

Re: Branching workflow

[John Keeping]

On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:
> I have been using a very basic workflow for branching, features each
> in a branch.
> 
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/*  <= Feature and fix branches
> - master <= Integration of the whole feature and fix branches
> 
> So I have now came up with a very difficult task. I just discovered
> that one of those branches, lest call it feature/bad, is evil and is
> making the integration branch (master) fail horribly.
> 
> In my workflow, I tend to merge develop (official updates) into my
> feature branches, and them into master.
> 
> So now I have the big problem on how to undo all changes from
> feature/fix. I have been told that one alternative workflow would be
> to revert the last merge and remerge it into master, so that I have
> always just one commit to revert if necessary (instead of the
> monstrous quantity I have now to).
> 
> The workflow proposal should be in order of importance:
> - Let me stay up-to-date with develop branch
> - Easy to revert in master
> - Have a clean history
> - Easy to follow
> 
> I think I should be capable of doing some sort of merge/rebase
> branching workflow to avoid having to do that. I have thought about
> rebasing always the feature branches, and rebasing master into all of
> them, but it seems pretty strange to me.
> 
> If anyone can give any advice, I would fully appreciate!

It sounds like you want a throwaway integration branch.  This is similar
to the workflow Junio uses with git.git's "pu" branch, which involves
rebuilding a branch by:

    * resetting it to some base ("develop" in your case)
    * merging in the required feature branches

This may not quite be what you want because it does mean that you cannot
build on the integration branch - it is intended to be rewritten often,
but it does provide a good platform for testing features and then
merging them to a stable branch once they have proved to be good.

The advantage is that you know that the integration merges are temporary
and you can test on top of that without having set the result in stone.

<shameless plug>If you are interested in such a workflow then you may
want to try my git-integration program [1] to manage integration
branches.

There is also a reimplementation in Ruby with a slightly different
feature set [2]

[1] http://johnkeeping.github.io/git-integration
[2] http://github.com/felipec/git-reintegrate

Re: Branching workflow

[Javier Domingo]

Hi John!,

Thanks a lot for your tip, but I have the problem that I would need to
have a linear history in master (forgot to mention it explicitly) ;(

I build on master branch, and getting to a previous version is hereby needed.

I had thought about the revert workflow, but using --no-commit. I
would then have a way to mark stuff as re-mergeable.

I am pretty lost with this. Is like a non-ending hell, because I have
to provide linear history to master and develop, and allowing master
to be revertable.

Isn't there something like git revert <branch-name> so that all
commits that have been merged from that branch, and don't belong to
any other, can be reverted?

With this history:
A<-B<-C := develop
B<-D<-Z<-Y := feature/bad
B<-D<-G<-H := feature/good
A<-B<-C<-z<-g<-y<-h := master

(caps original commits, regular merged commits)

so that:
git checkout master
git revert feature/bad

would revert z and h in master history, in one single commit, and
making available merging feature/bad when it's ready, with all
conflicting if needed.

Ideas welcome =)
Javier Domingo Cansino


2013/12/3 John Keeping <john@keeping.me.uk>:
> On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:
>> I have been using a very basic workflow for branching, features each
>> in a branch.
>>
>> My branches would be:
>> - develop <= Main upstream branch
>> - feature/* fix/*  <= Feature and fix branches
>> - master <= Integration of the whole feature and fix branches
>>
>> So I have now came up with a very difficult task. I just discovered
>> that one of those branches, lest call it feature/bad, is evil and is
>> making the integration branch (master) fail horribly.
>>
>> In my workflow, I tend to merge develop (official updates) into my
>> feature branches, and them into master.
>>
>> So now I have the big problem on how to undo all changes from
>> feature/fix. I have been told that one alternative workflow would be
>> to revert the last merge and remerge it into master, so that I have
>> always just one commit to revert if necessary (instead of the
>> monstrous quantity I have now to).
>>
>> The workflow proposal should be in order of importance:
>> - Let me stay up-to-date with develop branch
>> - Easy to revert in master
>> - Have a clean history
>> - Easy to follow
>>
>> I think I should be capable of doing some sort of merge/rebase
>> branching workflow to avoid having to do that. I have thought about
>> rebasing always the feature branches, and rebasing master into all of
>> them, but it seems pretty strange to me.
>>
>> If anyone can give any advice, I would fully appreciate!
>
> It sounds like you want a throwaway integration branch.  This is similar
> to the workflow Junio uses with git.git's "pu" branch, which involves
> rebuilding a branch by:
>
>     * resetting it to some base ("develop" in your case)
>     * merging in the required feature branches
>
> This may not quite be what you want because it does mean that you cannot
> build on the integration branch - it is intended to be rewritten often,
> but it does provide a good platform for testing features and then
> merging them to a stable branch once they have proved to be good.
>
> The advantage is that you know that the integration merges are temporary
> and you can test on top of that without having set the result in stone.
>
> <shameless plug>If you are interested in such a workflow then you may
> want to try my git-integration program [1] to manage integration
> branches.
>
> There is also a reimplementation in Ruby with a slightly different
> feature set [2]
>
> [1] http://johnkeeping.github.io/git-integration
> [2] http://github.com/felipec/git-reintegrate

Re: Branching workflow

[Junio C Hamano]

Javier Domingo <javierdo1@gmail.com> writes:

               
> Hi,
>
> I have been using a very basic workflow for branching, features each
> in a branch.
>
> My branches would be:
> - develop <= Main upstream branch
> - feature/* fix/*  <= Feature and fix branches
> - master <= Integration of the whole feature and fix branches
>
> So I have now came up with a very difficult task. I just discovered
> that one of those branches, lest call it feature/bad, is evil and is
> making the integration branch (master) fail horribly.
>
> In my workflow, I tend to merge develop (official updates) into my
> feature branches, and them into master.

I think the standard advice is not to contaminate feature branches
with unrelated changes, whether from an upstream updates or from
other unrelated feature breanches.

You would still want to make sure that your feature branches in
work-in-progress state would work with updated upstream from time to
time, but that is much better done by having a test integration
branch you maintain with:

    : always start from the tip of upstream
    $ git fetch upstream
    $ git checkout -B develop remotes/upstream/master

    : merge everything you want
    $ git merge feature/A
    $ git merge feature/B
    ...
    $ git merge fix/Z

And you will never merge 'develop' into 'master'.  Only after you
are satisfied with a single feature (or fix), you merge that to
'master', while your other features may still be suspect.

Re: Branching workflow

[Javier Domingo]

I will start to rebase all feature branches because I have no real
dependency on those, but master needs to have a linear history, as I
build from it regularly, and I need to assure that people can get a
previous version of master.

The problem with that is that I wouldn't be able to have a linear
history on master. I had also thought about doing a snapshot branch of
the integration branch, so that I could maintain history of
integration, and just update it with integration snapshots, but I am
trying to get another more git-ish way to achieve all these
requirements of all branches (they are really driving me crazy).

Thanks a lot for the idea. I will mantain clean feature branches from now on,

Javier Domingo Cansino

Re: Branching workflow

[Javier Domingo Cansino]

Hello!,

I have been using this workflow you suggested, and I happen to find it
really good fitting in many projects I am.

I would like to seek for a little more advice. I keep rebasing all my
work each time master branch is updated, and I would like to know if
this is usually done or not.

The workflow is not using emails, but each developer has his clone
where he works, and occasionally sends work to the gerrit tool we use,
upgrading the patch with each master update.

I know this is a crazy workflow, and I would like to know when you
usually consider to update the sent patch with a rebase.

Cheers,

-- 
Javier Domingo Cansino

Re: Branching workflow

[Junio C Hamano]

Javier Domingo Cansino <javierdo1@gmail.com> writes:

> I would like to seek for a little more advice. I keep rebasing all my
> work each time master branch is updated, and I would like to know if
> this is usually done or not.
>
> The workflow is not using emails, but each developer has his clone
> where he works, and occasionally sends work to the gerrit tool we use,
> upgrading the patch with each master update.
>
> I know this is a crazy workflow, and I would like to know when you
> usually consider to update the sent patch with a rebase.

When a rerolled set of patches come, I try to apply them to the same
commit as the previous fork point.  When there is no reroll, there
is no reason to ever do any rebase myself.

The trial integration branch 'pu' is rebuilt from scratch every day,
starting from the tip of 'master' and merging all the topics that
have not been merged to 'master'.

By not doing unnecessary rebase, we won't risk breaking each topic.
By merging topics together to updated 'master', we make sure changes
done in other topics do not negatively affect each topic.