Peter, assuming that
the release branch and master have some common point where they
branched from (which, ideally, is a tag for the x.0.0 version of the
release)... this is how I would do the bugfixes:
* Branch at the tag/common point
* Fix the bug
* Merge that branch into both the release branch and the master branch.
The problem with both cherry-pick and rebase is you'll end up with two
commits. If you have a lot of bugfixes, it could
quickly become a headache to track which have been merged into both branches.
The version.h files wouldn't run into any conflict unless you're
editing them in the bugfix commits, which you probably shouldn't be
(I'm assuming those files' changes are what you want to keep unique to
each release branch).
In short, don't work directly in master or the release branches, aside from
changing your version.h files. Work in topic branches at all times, and
merge them into the master/release branch when the topic branch is tested
and ready to be integrated into one of those releases.
Tekkub
Github Tech Support
http://support.github.com/
Join us on IRC: #github on freenode.net
Discussion group: [email protected]
On Tue, Jul 21, 2009 at 2:21 PM, Peter Shenkin <[email protected]> wrote:
>
> We're new to Git but are dealing with the same issue. We need to have
> several long-lived branches: the master, for new development, and the
> most recent release branch, for bug fixes. Bug fixes go to both
> branches but we don't want to merge the master to the release branch,
> since we want to keep new development out of the release branch.
>
> I think we're going to wind up with the following:
>
> (1) Fix the bugs in the release branch:
> Create a bug-fix branch off the release branch.
> Merge other release-branch changes into the bug-fix branch.
> Rebase the bug-fix branch to put the locally made bug-fix changes at the
> head.
> Merge the bug-fix branch into the release branch.
>
> (2) Propagate the bug fixes to the master.
> Cherry-pick the locally made bug-fix changes from the bug-fix branch
> into the master. (Rebasing, above, makes cherry-picking easier.)
>
> An alternative strategy is to replace (2) with a merge from the
> release branch into the master. But in our build methodology, we have
> a number of "version.h" files which contain codes that track official
> builds. All of these would produce conflicts. Still, it should be
> possible to replace (2) with:
>
> (2') Merge from the release branch to the master
> git checkout master
> gti merge -s ours release_branch
>
> If the Good Lord's wllin' an' the crick don't run dry,, the "-s ours"
> strategy will resolve conflicts in favor of the master's version.h
> files and will propagate only bug fixes from the release branch to the
> master. It seems to me that (2) is safer than (2'), but the jury is
> still out.
>
> -P.
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"GitHub" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/github?hl=en
-~----------~----~----~----~------~----~------~--~---
