It has been a long time since I have had the chance to work with a propper workflow and processes. When working for agencies, time was always an issue. Be it because of the small life time of the project, or the almost inexistent time-frame we had to build sites and web applications, I considered it a winning scenario that most of our code was actually being stored on a Git repo.
My developers has a small crush on DropBox for file sync and had little or no patience to work with GIT. There were serious complaints about merges and the cost these had to our workflow and development process(we liked to call it - Extreme Go Horse! - yes with the exclamation at the end). I'll publish an article soon enough about this insanely flawed, inhumane, crazy methodology.
Anyways... all that is in the past.
I have a couple of pet projects I am developing from scratch, on my own, following a strict set of rules (I plan on bringing in more developers in the near future).
One of the aspects of importance to my project is Version Control, both in terms of code and version numbers. Today I will focus my article on how I choose to control my code in my Git Repos and the tools I use.
Starting My Repos
If you are new to the world of git, please read-up on the basics of checkouts, commits, pushs and pulls. I expect you to be able to create repositories, and generally just keep things up to date in them.
If you are like most developers, just having a single repository that keeps the last version of your code up to date in an off site repository is already a fantastic tool. You can access your code from anywhere in the world, you are one step closer to Continuous Integration (CI) and you can safely interact with other developers in a single project.
When you initialize a git repo, you are basically creating a branch called "Master" (you can call it anything you want, but the standard is calling it master.
I setup a minimal commit & push - usually just uploading a README file with the very minimum of information (usually an intro to the project, notes I want to keep handy and so on).
Branching in git is a way to keep your master branch clean and your workflows organized and well documented. It helps track errors and solutions. It also helps track the the life of your project.
The Dev Branch
With my initial commit to master, I instantly create a dev branch.
git checkout -b dev
This creates a snapshot of the current master repository in a branch called dev, and allows me to separate the dev environment from the master(production) environment.
The dev branch, is where most of the magic of git will happen. It is from this branch that I will branch off most of my other branches, and where I will merge in most of them. To make some kind of parallel, the dev branch reflects your dev environment, and master, reflects the production server.
There is no, at least to my knowledge, standard or convention used for naming git branches other that the rules git imposes (like branches cannot end with a period), so as for naming conventions, I would recommend using common sense and what seems logical to your project.
My projects usually have the following conventions:
|ftr_user_session||Feature||New features or functionalities on the system.|
|bfx_user_session||Bug Fix||Bug fixing on features that are being tested|
|hfx_user_session||Hot Fix||Hot fixes are fixes being done directly onto master and are/should rarely be used.|
|rfc_user_session||Refactoring||Used when there is some refactoring that must be made over many modules due to a feature change.|
|rc_0_0_0||Release Candidate||Used when we want to test a production version on our staging environment.|
Practical use of terminologies
Rather than be all conceptual about all of this, I thought I walk you through a simple example. Since I mentioned User Sessions on the table above, let's keep the same example and walk you through a regular branching flow.
Create the feature branch
First thing, make sure you are in the dev branch and that you have the latest version on your machine.
Create a new branch for your feature - in our case, we will create the feature User Session.
git checkout -b ftr_user_session
Work on your feature and commit very frequently, push regularly too. When you are happy, it is tested, re-tested and validadted, you can get ready to merge it into dev.
To do that, make user you have committed and pushed all you work on the feature and checkout the dev branch.
git checkout master git merge ftr_user_session
If all goes well, you should now be on dev, with your new feature in place.
Creating a Release Candidate
This is not obligatory, but, i find it comforting to do. Whenever I am to publish some feature on my system, I like to replicate my prodution server and test out the feature with real live data. Since this is usually done in parallel to other developments (eventual merges in the dev branch) I like to create RC branches which can be used to simulate a production upgrade.
git checkout dev git checkout -b rc_0_1_0
Here I am bumping a minor version - but in a later article we will talk all about Semantic Versioning and ways you can automate this control.
In my staging server, I replicate the production environment, deploy my RC_0_1_0 to it and test the app out.
Let's go with a worse case scenario here. We found some bugs in our RC.
What I like to do is to branch off from the RC my Bug Fix branch, one branch per bug, one bug at a time, for example:
git checkout -b bfx_ie_5_compatibility
I apply my fix, merge it back into my RC, and keep on fixing bugs. When everything is done, I merge back into DEV.
git checkout dev git merge rc_0_1_0
Fix any eventual conflicts to ensure dev is up to date.
Ensure my version numbers are correct (bug fixes generate new patch numbers).
Going back to master
Finally, when everything is OK, I go into my master branch and merge in the RC branch.
git checkout master git merge rc_0_1_0
Again, we fix any conflics (we shouldn't have any though).
Add a tag with the version number
git tag v.0.1.1 -m "Release candidate v0.1.0 with ie bugfix"
Finally your master should be up to date with the latest release candidate. You can eventually erase the merged branches from git to avoid clutter, but I tend to keep mine around for a while after.
Subscribe to Zombiecorp
Get the latest posts delivered right to your inbox