Making Your Git Repository Git Flow Ready

Last week, I wrote about using Git Flow as a development model. It is very easy to start using if you are starting a repository from scratch, but if you are trying to change an existing repository to be 'git flow ready', then it is a little bit more complicated.

Here, I will show you some common Git commands that you may need to run to set it all up. You may have a case that actually covers more than one of these scenarios.

Scenario 1: The Master Branch (with tags)

In this scenario, you have been working on a single branch and deploying that as you go. You hopefully have been tagging as you have been going along. This is perhaps the easiest scenario to deal with.

Your master branch may look like one of the 2 below:

a) The master branch has nothing more than the very latest tag.

Scenario 1 Diagram

In this case, it is simple: make a standard branch from your master branch and call it develop:

git branch develop

Then you can just check it out and push it to the remote. You could also run:

git checkout -b develop

which will automatically checkout develop for you.

b) You have further commits past the last tag.

Scenario 2 Diagram

In this case, you are happy to release what you have done, you can just tag it as it is and then refer to a).

But if you do not want to release what you have and it will be a while before you are ready to release then you will want to extract every commit from the master all the way back to the last tag and put them in a new develop branch.

First, make sure you have no uncommitted changes as these will be lost in the following process.

Make a new branch:
git branch develop

If you run git log or look on the online repository, count the number of commits back to the last tag.

Then run
git reset --hard HEAD~n where n is the number of commits you want to take out.

Switch to your develop branch with git checkout develop and then do the standard:
git add --all git commit -m "your message" and push.

You should then switch back to the master branch and push it.

Scenario 2: The Master Branch (without tags)

No tags?! Really?! So you have been pushing a branch to your live system without any versioning?!

Well in this scenario there is an number of things you could do. If you are happy that the master branch is stable and is currently in use as it is, then you can create your first tag with git tag "version number" and then make a new develop branch as discussed earlier.

If you want to role back the master branch before you tag, you can do this using the technique provided in Scenario 1.

Other Scenarios

There are probably a handful of other scenarios but I believe that they can be solved using the same techniques as already discussed.

One of the key things to watch out for is that if you are working in a team where multiple members have copies of the repository, you must make sure that this a coordinated process where they have push all of their changes and will git fetch the new repository when you are finished. In the worst case scenario, they can just re-clone the repository once you have finished and pushed all your changes.


© 2012-2017