13

I am trying to spend as much time as I can on GitHub nowadays (even I am the only person in team at work) to really feel how it is going to be like for a real world corporate application.

One question I am having is to controlling the version. Let's say we started a project. Then, team members created some branches and develop there. When we are ready for the production, we merged all of branches with master branch. At the end, we go live with version 1.0.

Now that version 1.0 is live and we have some issues filed for that version of that software. We would like to start developing for version 1.1 in order to fix those issues that we had introduced by rushing the project.

Now, the question is this:

How should we control the versioning here?

Should we create a new branch for v1.0 and keep the version 1.0 of the software there and develop on some branches (or not), merged them with master, go live with version 1.1?

Is there convention out there for those kind of situations?

Improve this question

2 Answers 2

Reset to default
20

I have found (and started to adopt) the following branch model:

Image from nvie.com

(image from the article)

There are lots of great practices and strict rules described in that article, I highly recommend it.

Points of interest:

  • The master branch is where you tag your versions. No development happens here. In case of a bug that was deployed in production, you fix the bug on a hotfix branch, merge back and tag a new version.
  • Development happens on the devel and feature branches. Personally, I do bugfixing on the devel branch and features on feature branches.
  • When the software starts to reach a release, I branch off to release branch. The release branch is where I do the final touches. Bump version numbers, change metadata etc. And minor bugfixes. When it is finished, I merge it to master, tag and call it a version.
  • The two main branches: master is the "holy branch"; its HEAD is always the latest production code, and develop is the nightly branch; its HEAD always reflects the latest (but possible unstable) additions to the code.

In your specific case, the steps would depend on how rushed was that version. If it's features that were left out, I would go back to the develop release and do the whole thing again. If it's bugs in the deployed version, I would branch off to a hotfix branch, fix the bugs, merge back and tag v1.1. If it's both, I would fix the bugs first, then add the features second as described.

Improve this answer
5
  • Very informative and detailed. And also a perfect practice. It also makes a lot of sense. Having master for the prod only makes it easy to maintain. I am so unfamiliar with tagging a branch (or commit?). Can you give me some details on that? how we can do according to above model?
    – tugberk
    Jan 8, 2012 at 13:25
  • 1
    In git, the target of the tagging is a commit. It means that you say: "here is this commit, and I call it 'v1.3' from now on". In practice that means you switch to the master branch, merge in the (now stable) devel branch, commit and tag. Then you can list all the tags, revert to that code in case you need to see what went into production in a past release. There is a little more to tags than that (which is useful for large-scale distributed development such as the linux kernel). If you are interested, I suggest the progit book.
    – Tamás Szelei
    Jan 8, 2012 at 13:34
  • ProGit is one of the books that I will definitely read from scratch. For now I am only reading the parts I am interested to get the job done. So far, we have developed on master branch and I think I should maintain that. But I will open another branch called production and use it as master branch according to above model.
    – tugberk
    Jan 8, 2012 at 13:42
  • while I am trying out this model, one thing I am struggling is that: there are some supporting branches as discussed at the given article, feature and release branches. there can be multiple future branches. For example, FeedbackForm is one future branch and ContactForm is another. This is ok for this model I guess? Should there be multiple release branches as well? and if so, how should I name them?
    – tugberk
    Jan 8, 2012 at 15:25
  • First of all, you don't need to follow it to the letter, just have established rules that you keep. Do what is best for you & your team's style. Second, yes, multiple feature and release branches are normal unless you have short-lived project with one feature and one release :). Naming, according to the article is release-* and feature-*. I guess you put the future version number in place of the asterisk for the release, and the issue tracker id in case of the feature branches.
    – Tamás Szelei
    Jan 8, 2012 at 15:46
1

What I've witnessed most of the time is:

  • Master is for you product. Eventually all your future version x.0 will be on master.
  • You create a tag/branch for each version in production so you can still support them for any customer that requires it.
  • Merging fixes from one or the other is to deal on a per case basis.
Improve this answer
2
  • thanks! so you think that it is reasonable to keep a branch named v1.0, v1.2 is reasonable?
    – tugberk
    Jan 8, 2012 at 10:50
  • @tugberk as long as the corresponding software exists at that version, it makes sense to keep the branches around so that you are able to quickly fork off them if you need a specific hotfix branch. When the software does not exist anymore at that version (is not supported anymore so no more work can happen) it can make sense to do a final merge of the branch and then delete it. You can even create a final empty commit (I do it often at the start of the branch), just to say "Closing branch XXXX", otherwise you will not keep branch history (reflog can help a little but this is per repository)
    – Patrick Mevzek
    Nov 13, 2019 at 18:43

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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