4

I'm using svn without branches (trunk-only) for a very long time at my workplace. I had discovered most or all of the issues related to projects which do not have any branching strategy. Unlikely this is not going to change at my workplace but for my private projects.

For my private projects which most includes coworkers and working together at the same time on different features I like to have an robust branching strategy with supports long-term releases powered by git.

I find out that the Atlassian Toolchain (JIRA, Stash and Bamboo) helped me most and it also recommending me an branching strategy which I like to verify for the team needs.

The branching strategy was taken directly from Atlassian Stash recommendation with a small modification to the hotfix branch tree. All hotfixes should also merged into mainline.

Planned Branching Strategy

The branching strategy in words

  • mainline (also known as master with git or trunk with svn) contains the "state of the art" developing release. Everything here was successfully checked with various automated tests (through Bamboo) and looks like everything is working. It is not proven as working because of possible missing tests. It is ready to use but not recommended for production.
  • feature covers all new features which are not completely finished. Once a feature is finished it will be merged into mainline. Sample branch: feature/ISSUE-2-A-nice-Feature
  • bugfix fixes non-critical bugs which can wait for the next normal release. Sample branch: bugfix/ISSUE-1-Some-typos
  • production owns the latest release.
  • hotfix fixes critical bugs which have to be release urgent to mainline, production and all affected long-term releasees. Sample branch: hotfix/ISSUE-3-Check-your-math
  • release is for long-term maintenance. Sample branches: release/1.0, release/1.1 release/1.0-rc1

I am not an expert so please provide me feedback. Which problems might appear? Which parts are missing or slowing down the productivity?

Improve this question
4
  • 2
    I would recommend at least reading through some of Microsoft's material about branching strategies, its TFS focused but the basic ideas are all the same.
    – Ryathal
    Jun 6, 2014 at 12:23
  • 1
    I don't really understand the distinction between production and release and the direction of the arrows trunk->production and production->release. I would have expected a trunk->release arrow and a release->production arrow (with production effectively being an alias for one of the release branches).
    – Bart van Ingen Schenau
    Jun 6, 2014 at 12:36
  • which branching model is efficient totally depends on project specifics. There can not be one-size-fit-all approach, see To branch or not to branch?
    – gnat
    Jun 6, 2014 at 12:47
  • @BartvanIngenSchenau production is a "flat branch" which contains only the latest release. release is a "tree branch" and just a prefix. but maybe it is better to tag a release branch with "latest" and clone the tag. having a seperate production branch may cause inconsistency.
    – burnersk
    Jun 6, 2014 at 14:17

2 Answers 2

Reset to default
4

The shortest answer: No single branching strategy is going to be optimal for every project, as such the strategy you have above will be perfect for some projects you have, and useless for others.

The various factors you need to keep in mind are (among others, if any more are suggested i will happily edit them into this answer):

  • Does the project have unique releases, or is it continuously released?
  • Is the project software distributed to customers, or made available as a service on your own hardware?
  • If the software has unique releases, do newer releases always obsolete older releases, or will older releases also need to be maintained?
  • How experienced are your contributors? Are they all highly experienced developers or will you need to make concessions to non-technical personnel like designers?
  • How much time am i willing to invest in keeping the project history clean and tidy?

The strategy you described above is optimal for the case of:

  • The project has unique releases.
  • The project code is distributed to customers.
  • Older releases will need to be maintained.
  • ! It does not describe the way merging is handled, i.e. rebase-first, no-ff, existence of merge commit, etc. and as such is ambiguous on the point of contributor experience.
  • ! Since it does not address merging, it is also ambiguous about the point of time investment.

That said, a much more useful question to ask is in this form: "My project is structured like [this], what is the optimal branching strategy for this, what are the drawbacks it has?"

Improve this answer
0

http://nvie.com/posts/a-successful-git-branching-model/ outlines a comparable branching model which the writer claims to have been using successfully on a number of projects.

Key points:

  1. two long-lived branches, master and development, with the former for production-ready code, and the latter being the integration branch.
  2. branches for feature, release and hotfix. These exist just for the duration of the relevant work, unlike the long-lived branches mentioned above.
  3. feature branches come off development and are merged back into it when complete. These typically exist in developer repositories only.
  4. release branches come off development and are merged back into development and master. The goal being to prevent big breaking changes to master causing problems for an imminent release. Hence these branches are typically created just before a release is due.
  5. hotfix branches come off master and are merged back into master and development. These are intended to address critical production issues.
Improve this answer
5
  • So "he" got rid of the release branch replaced it with simple tagging in master. I will read it anyway. Thanks :)
    – burnersk
    Jun 6, 2014 at 12:42
  • would you mind explaining more on what it does and why do you recommend it as answering the question asked? "Link-only answers" are not quite welcome at Stack Exchange
    – gnat
    Jun 6, 2014 at 12:48
  • I happened to be reading that article as we are making some development changes currently, hence referencing it for the original poster as a deployment approach that someone had reportedly used successfully.
    – mc110
    Jun 6, 2014 at 12:50
  • 1
    @BЈовић thank you for the feedback - I've edited the answer to identify the key comments in the original article.
    – mc110
    Jun 6, 2014 at 14:07
  • 1
    I see, but you did it in such a way that you made the key points completely not understandable. Without reading that article, it is not clear what your key points are refering to
    – BЈовић
    Jun 6, 2014 at 14:41

Not the answer you're looking for? Browse other questions tagged or ask your own question.