Pilen
2011-10-11

spotd branching strategy

I recently started using GIT in my work, and thought I would give it a shot for some private projects as well. On spotd I have mixed branches and branch-names pretty wildly, and thought that it soon might be time to think about some overall strategy and naming schemes.

So what will my strategies and schemes look like? I don't know yet, I should still have some time to think about it.

But it might be something like this:

  • Every developer must have his or her own development branch
  • There should be integration branches, where developers changes are merge before being merge into master
  • When a release of a new version is imminent, a release branch should be created. It is only merged to from master
  • Bug-fixes should be made on separate branches
  • Commit only one "thing" at a time, i.e. do not put multiple features in a single commit
  • Branches should be hierarchical if possible

Naming will be as follows:

  • Branch names should not contain spaces, use underscores if needed
  • Developer branches should be prefixed with the dev
  • A developers private developer branch should contain the developers github username, eg. dev/pileon/daemon/spotify where pileon is the username
  • Bugfix-branches should be prefixed with fix/, a short name of the branch, and end with a slash and the ticket number
  • Release branches are prefixed with rel/
  • Every release on a release branch must be in the form Rmajor.minor.patch
  • Semantic versioning will be used for version numbers
  • Development branches should have part of the branch name as dev

Here are some example branch names (might conflict with the rules above):

  • A developers general development branch: dev/joachimp (Branched of from the master branch)
  • A release integration branch: int/Rx.y (Branched of from the master branch)
  • A release branch: rel/Rx.y (Branched of from the int branch)
  • A tag on a release branch: Rx.y.z
  • A bug-fix branch: fix/some_wierd_bug/1234 (Branched of from the int branch)
  • A feature branch (Branched of from the master branch):
    • From a feature-request ticket: topic/name_of_feature/2345
    • For milestone: topic/name_of_feature/Milestonename
  • A bug-fix for a feature: fix/name_of_feature/3456 (Branched of from the topic branch)

This is just some thoughts, and may not follow any best-practices that I know of, but at least it's a start to work from.

Any reader want to chime in with ideas or thoughts?

I edit this post from time to time to update with the latest thoughts and ideas I have.

No feedback yet


Form is loading...

March 2021
Mon Tue Wed Thu Fri Sat Sun
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        
 << <   > >>
A place where it's possible to read the ramblings of two members of the Pileborg clan.

Search

  XML Feeds

Stack Overflow

Stack Overflow profile for Joachim Pileborg

Twitter

free blog tool