Suggestions for procedure going forward

[Jason Miller]

> Date: Wed, 18 Nov 2015 23:55:29 -0600
> From: Robert Goldman <rpgoldman at sift.net>
> To: Steven N??ez <steven.nunez at illation.com>
> Cc: ASDF-devel <asdf-devel at common-lisp.net>
> Subject: Re: Suggestions for procedure going forward
> Message-ID: <564D6451.1080106 at sift.net>
> Content-Type: text/plain; charset=utf-8
On Wed, 18 Nov 2015 23:55:29 -0600 Robert Goldman said...
> 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....

I know the answer.  As long as all merges go in the same direction there
are little to no merge issues when you jump master to be develop.

There are two major schools of thought on this.  One is documented with
"man 7 gitworkflows" and the other is discussed here:
http://nvie.com/posts/a-successful-git-branching-model/

Since they use slightly different terminology, I'll use a theoretical
repository with two branches named "stable" and "testing" in this
repository a release happens when "testing" is merged back to "stable"
and, aside from that, only bug fixes go into "stable";  I'll also use
the terms "newer" and "older" to mean release order, so if you had a
"previous-release" "current-release" "next-release" and "unstable" or
some-such way of branching, that's the order from oldest to newest.

They both share a single common feature: All new commits are based off
of the oldest branch they might be merged into (so new features start
off of the test branch, and bug fixes start off of the stable branch).
If you change your mind (e.g. "this change is too risky for stable" or:
"this new feature fixes a serious bug, it should go into stable too")
then you rebase to the correct branch before doing a PR.

The most important part is that these changes somehow get merged into
the branche it was based off of and every single newer branch that might
ever get merged back.  With the "stable" and "testing" example this
means all changes to stable must also be merged into testing.

This way when it's time to merge your testing branch to your stable
branch, testing is a superset of stable and a merge is guaranteed to
succeed with no conflicts.

-Jason