Project Ramon

A learning journey from a Ruby noob perspective

Semantic Versioning: Intro to the Git Branching Model

semantic_versioning_2

Hello and happy Wednesday!

In my last post we looked at what semantic versioning was, how it worked and looked at some benefits to using this versioning approach.

Today, I’ll be sharing my review of applying semantic versioning with the Git branching model.

What is a Git Workflow?

Here’s a nice excerpt I found on the official Git site:

Some people refer to the branching model in Git as its “killer feature” , and it certainly sets Git apart in the VCS community. Why is it so special? The way Git branches is incredibly lightweight, making branching operations nearly instantaneous and switching back and forth between branches generally just as fast. Unlike many other VCSs, Git encourages a workflow that branches and merges often, even multiple times in a day. Understanding and mastering this feature gives you a powerful and unique tool and can literally change the way that you develop.

There appears to be a few different Git workflows, this tutorial from Atlassian covers them quite well:

Git Branching Model

First off, let me share the primary resource I reviewed to learn this. If you have the time, go check out that blog post.

The Git branching model is composed of two types of branches.

All subsequent branches will fall into either one or the other of these branch types:

  • Main Branches
  • Supporting Branches

As implied by their names, one difference between main branches is that they will have an infinite lifetime throughout the life of your project, whereas supporting branches will have a limited lifetime depending on whats happening in your project’s development cycle.

Main Branches

The two branches that will always have a label of main branches are named master and develop. If you’ve spent anytime using Git with GitHub or BitBucket then you know that all repositories come standard with a master branch.

origin/master

This is where the HEAD source code will always reflect a production-ready state.

origin/develop

And this is the branch that contains the latest delivered development changes for the next release. It’s also where our nightly builds are constructed from.

When the source in the origin/develop reaches a stable enough point to be released, all changes should be merged back into master and then given a Git tag that includes a release number. So every time changes are merged back into master, there is a new production release.

Main Branches in Action

Lets look at some quick examples to ensure that I am understanding this correctly.

  • Step0: Create a new sample rails app rails new git_workflow_sample
  • Step1: Initialize git in our terminal && create a repo on GitHub.
    Screen Shot 2014-07-16 at 3.43.43 PM
  • Step2: Add our remote origin && push to our master branch
    Screen Shot 2014-07-16 at 3.44.29 PM

Now that we have that out of the way, lets see if I can’t create a simple mock scenario of the develop and master branches working together.

Step1: First lets build our develop branch.
Screen Shot 2014-07-16 at 3.56.23 PM

Step2: And now let me add some trivial new_thing to the code in our new branch
Screen Shot 2014-07-16 at 3.59.44 PM

Now that we have our mock source code improvement created (which is the model NewThing), we can look into our next step which is Git tagging.

Git tagging

Before I go forward, here is a link from the Git documentation about creating and viewing tags. The resource link goes into much greater detail than I will, so be sure to take a peak.

To view a list of currently created tags, we can just type git tag into our terminal.

Here’s an excerpt from the Git documentation site about creating tags that I thought was important enough to include:

Creating Tags

Git uses two main types of tags: lightweight and annotated. A lightweight tag is very much like a branch that doesn’t change — it’s just a pointer to a specific commit. Annotated tags, however, are stored as full objects in the Git database. They’re checksummed; contain the tagger name, e-mail, and date; have a tagging message; and can be signed and verified with GNU Privacy Guard (GPG). It’s generally recommended that you create annotated tags so you can have all this information; but if you want a temporary tag or for some reason don’t want to keep the other information, lightweight tags are available too.

Since I haven’t yet created a tag for this sample project, let me illustrate how I plan to proceed.
For this tutorial I’m gonna go with the lightweight tag, but in my whizcharts app that I’m learning the Git workflow for, I will probably go with a tag of an annotated sort.

Screen Shot 2014-07-16 at 4.22.46 PM

And now we can merge our develop branch (since we’ve theoretically completed the NewThingy build) into master. This step is designed to illustrate how to push a stable point in the develop branch, which is now ready to be merged into our ‘pristine’ master branch.

Conclusion

In my next post, I’ll be continuing this Git branching model workflow. And we’ll have a chance to see how supporting branches fit into this picture.

Stay tuned…

Advertisements

Categories: Versioning

Tags: , ,

1 reply

Trackbacks

  1. Git Branching Model [Support Branches ]: A look at the Feature Branch | Project Ramon

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s