Web Development Craft

A Simple Git Workflow

In my previous post on git I covered the basics of how to host your own repositories for items you wish to not have on Github or that you simply do not want to have to pay for private repositories.

Today I will go over a very basic and simple Git workflow that easily works for small teams and is simple to keep track of in your head.


I like to keep my master branch production ready at any given moment. There are several reasons for this:

  • Many third party tools don’t need to be configured to work with the master branch as it’s almost always the default.
  • When somebody clones your repo the master branch is usually the default that they start with. Having master be the stable production branch is easier on them.

So, once we decide we want our master branch to be the production ready branch we then must move onto how we will develop our workflow.


I normally start with a development branch when starting out and I don’t have anybody else working on the project for the moment.

When working in development I don’t concern myself with whether or not things are in a working state. The goal is to make sure any changes we are making live on the server and we don’t have a long time passing where changes are just sitting on the local development machine.

Since I am assuming the product is very young and nobody is currently working on it I initially use development to flesh out the workings of the application. Once things are good I then will get things passing and merge into master.

Getting The Ball Rolling

Now that we have a stable master branch and a development branch for ourselves this is where you can start implementing a team approach to working on the app.

Team members are encouraged to use a topic branch both locally on their machine and tracking on the server to make sure work is being backed up regularly. When their topic branch is done then they should merge into development. If everything in development looks good you can then merge into master and deploy immediately.

Deploying immediately is very important as you don’t want code sitting in master that isn’t being exercised in production. Only running in production will you know that the code works.


You may wonder why you don’t just make sure your topic branch is good and merge directly into master. This is totally fine if that’s how you want to manage things. With Git there is no ‘one way’ to do things.

I like having a development branch so things can be reviewed before being deployed. If you have people on your team who are not comfortable with deployment it’s good to have a process where you can oversee what’s going on in the system.


So, assuming we have a local repo that is tracking a server repo with just a master branch we can create our development branch like so:

bash console
git checkout -b development

Then push that branch to the server and track it:

bash console
git push -u origin development

You can also create your topic branches the same way:

bash console
git push -u origin topic_branch

Eventually you’ll be all done with your topic branches you can simply remove them by typing:

bash console
git push origin :topic_branch


This isn’t the only right way to manage your development workflow. This isn’t a wrong way either. Pick and choose what will work best for your team and discuss it with them. You may find some things work great for your team and others fail miserably. The beauty of Git is it lets you choose. It also gives you enough rope to hang yourself.