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:
- Centralized Workflow click here for details
- Feature Branch Workflow click here for details
- Gitflow Workflow click here for details
- Forking Workflow click here for details
- Pull Requests click here for details
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.
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.
This is where the HEAD source code will always reflect a production-ready state.
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.
Step2: Add our remote origin && push to our master branch
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.
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.
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:
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.
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.
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.