Re: Branching workflow

[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