Suggestions for procedure going forward

[Kambiz Darabi]

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