Re: Branching workflow

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 [off-list ref]:

On Tue, Dec 03, 2013 at 07:06:20PM +0100, Javier Domingo wrote:

quoted

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