On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman rpgoldman@sift.net wrote:
On 11/18/15 Nov 18 -11:33 PM, Steven Núñez wrote:
With git you can, and usually do, have many branches, including personal ones. The pull request will be against a specific branch. I only read this message of the thread, so hope I'm answering the right question. Github has some good tutorials.
Well the question isn't really about having many branches. The question is what happens when you have stable and development branches, and you want to "jump" the stable branch to mark retiring an old stable version and starting a new one? Doesn't that involve a nasty merge or rebase?
I can do some research, but I was hoping someone knew the answer....
My bet is that they use versioned names for branch, and so never have to jump.
There is no branch called "stable", there is just the 3.1 branch, the 3.2 branch, etc.
That's exactly what we do, just not so fine-grained at the minor number but cutting off the release name at the major number.
We use a 'release-3' branch which contains the tags 3.0.0, 3.1.0, 3.2.0, etc. and when the deveopment branch is ready for preparing 4.1.0, we branch off a 'release-4' which will be tagged 4.0.0 at some point in time.
Depending on how often we change the major version number, we either keep the release-x branches in the repo indefinitely (which is usually the case) or we merge them back into development ('master' in Faré's proposal) using
git checkout master git merge -m "Merging branch release-3 with -s ours" -s ours
After that, the content of master is exactly the same as before, but branch release-3 is merged into master without any conflicts.
Using this method, history is preserved, but the branch can be safely removed to avoid old branches littering the repo.
HTH
Kambiz