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 <j...@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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
