Date: Wed, 18 Nov 2015 23:55:29 -0600 From: Robert Goldman rpgoldman@sift.net To: Steven N??ez steven.nunez@illation.com Cc: ASDF-devel asdf-devel@common-lisp.net Subject: Re: Suggestions for procedure going forward Message-ID: 564D6451.1080106@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