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 -~----------~----~----~----~------~----~------~--~---
