[BART-devel] [BART] Implement an optimized git branching model

[aj-foster]

The following is an archived message from the BART-devel mailing list, which has now closed.

From: jh***@ph*** (Joe Harrington)
Date: Mon, 22 Jun 2015 11:38:48 -0400
Subject: [BART-devel] [BART] Implement an optimized git branching model
to improve your workflow. (#17)
In-Reply-To: </issues/17***@gi***> (message from Chris Campo
on Sat, 20 Jun 2015 12:19:56 -0700)

Let's try to keep policy-level talk and even how-do-I-implement-X on the
ba***@ph***mail list, and restrict the github
conversations to the details of pull requests, merges, branches, etc.

I'm not sure who is reading on github, but it will make it easier to
filter the chatter that's mostly relevant to a few individuals at a time
(the github talk) from the higher-level things everyone needs to see.
Chris, I've invited you to join BART-devel and BART-user. They're
mailman.

Chris describes the kind of workflow I was talking about, with the
addition of the develop branch. I think we should go with this idea,
including semantic versioning, which AJ also me***@th***eeting
last week. Chris, do you think you can make it to a meeting any time
soon? How about tomorrow?

Patricio, this will mean that your current repo needs to move to
exosports, and then people (including you) branch or fork it to use for
papers and dissertations. We'll call these "research" branches, as
opposed to development branches. Researchers can then track activity in
develop and choose what to merge into their own research branches, and
things will stop changing out from under them. It will be important, of
course, to merge changes in those research branches back into
development branches, but only the ones that aren't hacks!

--jh--

X-Spam-Status: No, score=-6.9 required=4.0 tests=BAYES_00,HTML_MESSAGE,
RCVD_IN_DNSWL_HI,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,T_DKIM_INVALID
autolearn=ham autolearn_force=no version=3.4.0
Date: Sat, 20 Jun 2015 12:19:56 -0700
From: Chris Campo <no***@gi***>
Reply-To: exosports/BART <reply+00***@re***>
To: exosports/BART <BA***@no***>
Subject: [BART] Implement an optimized git branching model to improve your
workflow. (#17)
Content-Type: multipart/alternative;
boundary="--==_mimepart_5585bcdc2b702_21f73fd6e12bf2bc7723d";
charset=UTF-8

[1:text/plain Hide]

Hi all

Since you all seem to be using git pretty regularly, and are taking advantage of pull request (awesome, PRs are a great tool), I'd like to offer the suggestion of switching to the git flow branching model.

You can read more about git flow here (the original proposal):
http://nvie.com/posts/a-successful-git-branching-model/

Also Atlassian has a great overview as well:
https://www.atlassian.com/git/tutorials/comparing-workflows/feature-branch-workflow

In any case, it's fairly simple. You have your standard master branch which represents your "production" branch. That is, any commit to master is a fully working and tested release. This is code that you would release to customers or the public, or code that you would use yourself for actual work.

Alongside that, you have a develop branch which represents the bleeding edge of development. This is where all pull requests would go. Basically, as the name says, all the actual development takes place on this branch, with the caveat being that it should always be able to build successfully (this isn't a hard rule but it's a good one to follow when possible).

Then, you have feature branches where you implement actual new features/changes. You do your actual work in these feature branches, and when it's done, you merge back into develop. You can (and should) rebase your feature branch on to develop occasionally if develop has progressed since you started your branch, and you want to include the changes from develop into your branch. Usually users do not push feature branches to the main remote repository, but rather instead working on them in their own clones... however if multiple people are working on the same feature branch, you can make an exception in this case.

Git flow purists recommend merging with the --no-ff flag to preserve the concept of a branch when merging back into develop, although I personally have no preference here.

Finally, you have release branches which you always create before you issue a release of the code. The point of these branches is to cut a release, test the code, and then any bug fixes you find go in this release branch. When everything is considered stable, you merge the release branch back in to develop AND master. This is the only time you should merge into master, and this represents "releasing" a version of the code. Typically you'll tag each commit in master with a version number, e.g. 1.0.1 and 2.0.0. A good versioning scheme to follow is "semantic versioning", although you're always best sticking with the most adopted versioning scheme in the community.

In my experience, this is one of the best ways of structuring git for multi-person teams, and it also preserves nearly every bit of history. It gives you the ability to have very finely grained releases, and works well with CI (your CI server can automatically build every commit to develop and/or master, for example). Finally, it allows you to experiment and play with the code without breaking anybody else's work!

If any of this sounds intriguing to you all, let me know and I'd be happy to give you a demo and set the repository up for you. If not, I'd still re***@le***eading the articles! :)

Hope all is well, and let me know what you think!

---

Reply to this email directly or view it on GitHub:
#17

[2:text/html Show]