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
masterbe 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
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:
Then push that branch to the server and track it:
You can also create your topic branches the same way:
Eventually you’ll be all done with your topic branches you can simply remove them by typing:
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.