Late as always to these git things.
In the ever increasing madness to the method of making code easier to do, we come to the automation of git-flow. This is a library of git subcommands that helps automate some parts of the flow to make working with it a lot easier if you’re using Vincent Driessen’s model.
This model is not bad, if a little confusing at first:
Jeff Kreeftmeijer already has a good primer for it so these are just my quick notes to add in things that should have been obvious. The basic concept for the model is that you have two main branches, master (the ‘current’ version) and develop (where you’re working on the next version).
Install git-flow
You have to install it to use it. I use Homebrew so it was brew install git-flow and that was that.
Add it to your repo
Again, you have to add it to have it. git flow init is run inside the repo and you’re good, except you may not be.
Since I’m starting from an existing repository, which was up to date in master, I made a new branch: git checkout -b develop
Then I ran git flow init which is not the same as it would be on a new repo:
$ git flow init Which branch should be used for bringing forth production releases? - REL_3.3 - REL_3.3.1 - REL_3.3.2 - master Branch name for production releases: [master] master Which branch should be used for integration of the "next release"? - REL_3.3 - REL_3.3.1 - REL_3.3.2 Branch name for "next release" development: [master] develop How to name your supporting branch prefixes? Feature branches? [feature/] Release branches? [release/] Hotfix branches? [hotfix/] Support branches? [support/] Version tag prefix? [] REL_
Should you happen to do as everyone says and ‘accept the defaults’ you get this:
Branch name for "next release" development: [master] Production and integration branches should differ.
Also if you don’t have a develop branch, it punts you out.
Branch name for "next release" development: [master] develop Local branch 'develop' does not exist.
So a couple ooops along the way. It’s not
Using A Feature
First you make a feature:
$ git flow feature start utility_1.0.3
Switched to a new branch 'feature/utility_1.0.3'
Summary of actions:
- A new branch 'feature/utility_1.0.3' was created, based on 'develop'
- You are now on branch 'feature/utility_1.0.3'
Now, start committing on your feature. When done, use:
git flow feature finish utility_1.0.3
Eventually you’ll be done and use that finish command, which merges it all back into ‘develop’ and changes you back to that branch. Which is good for reasons we get to in a moment. Since I work on multiple computers, I do this at the end of my workday:
$ git push --all Total 0 (delta 0), reused 0 (delta 0) To ipstenu@example.com:/home/ipstenu/repositories/theme-wordpress.git * [new branch] develop -> develop * [new branch] feature/utility_1.0.3 -> feature/utility_1.0.3
So now when I do my pull later on the other computer, it’ll be easily usable. Provided I remember to install git-flow and init it on my other laptop. But it’s a little more complicated than just that.
Releasing a Release
You can only run this from the develop branch, which makes the previous command pretty awesome, right? So now we’ll do this: git flow release start RELEASE
Once we’re good to go, it’s git flow release finish RELEASE
What About Two People?
This is where we want to use publishing. Technically I’m collaborating with myself across two computers, so I always publish my feature to my remote server so it can be used by my other self: git flow feature publish MYFEATURE
To pull the feature down, git flow feature pull origin MYFEATURE is just as logical. And that’s actually how I handled pulling the feature utility_1.0.3 onto my work laptop.
$ git checkout master Switched to branch 'master' Your branch is up-to-date with 'origin/master'. $ git branch develop $ git flow init [snip .. same as before] $ git flow feature pull origin utility_1.0.3 Created local branch feature/utility_1.0.3 based on origin's feature/utility_1.0.3.
There’s a good cheat sheet for help about this called Git Flow Cheatsheet.
Now there’s nothing but to do it.
