> On Thu, Nov 19, 2015 at 12:55 AM, Robert Goldman <rpgold...@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
