Despite having a number of git interfaces available including a half-decent one built right into phpStorm (my fav for any PHP development ESPECIALLY WordPress) , my go-to tool after 5 years remains SmartGit.   I find the graphic interface far superior to any other git “helper” out there.   The branch visuals and right-click shortcuts no only make me far more efficient than command-line it also has made for far fewer mistakes when managing repositories.    This is especially helpful when trying to see what the other developers are doing on the MySLP SaaS project and trying to coordinate a release.

Recently I decided to upgrade to SmartGit 17.  It has been a few years since my last update and I wanted to check out the new stuff they had.   While the majority of the UX remains the same and gave little reason to update there was one new feature that intrigued me.  “Git Flow”, a new button on the tool bar.    One click later I was knee-deep in the “Git Flow” world.     Less than a week later I’m “going for a swim”.

GitFlow

For those that don’t know, GitFlow tackles something we talked about many times with my prior Cyber Sprocket team – how to manage your git repository branches.    Sure, the master branch is fairly easy.  Nearly every team I know makes that THE “live” branch where your most recent “for public consumption” version lives.   But what about the development cycle?    What about branches for bug fixes?  New features?   What branch is THE “ready for testing” / get this on the staging server branch?    How do you handle hot fixes ; the things that should forego all the overhead of standard branch management/integration/testing because a bug got through and is breaking the product for thousands of customers?

While working with DevriX on this project I quickly adopted their “develop” and “master” branches over my “prerelease” and “master” branches.  It just made more sense.   They may even be following this model already, but we never really talked about it as we were too busy pushing forward to get MySLP launched by January (mission accomplished).

Git Flow , at least as far as I can tell, is quickly becoming a de facto  standard for how to define those branches and what to name them.   Rather than get into the details, I’ll leave you with this link to a decent resource that explains the methodology.  And my typical “cheat sheet” on how it works below.

GitFlow Branches

You’ll want to check out the GitFlow post for visuals on these, it will help.

Feature – as in feature/<some-cool-short-thing-here> are all of the different features, non-emergency bug fixes, etc. that the team works on.  Disciplined coders will have a separate feature branch for each functional area they work on for an upcoming release.

They should always be branched from the latest develop branch.

Develop – a merge of all the finished feature branches that are ready for release.  Developers should “finish” their feature branches and merge them to develop when their branch is stable and is a candidate for release.

Release – the develop branch that is ready for testing to be deployed on the beta (staging) system.   I like to tag these as X.Y.Z-beta-n , though that is not part of the GitFlow model.

Any bug fixes needed to get the system to pass testing goes in here and are merged back into develop.

Master – the main production (live) release, tagged with a version number X.Y.Z, only tracks that latest release branches that passed testing are are going to production.

HotFix – you really screwed something up, but that’s human nature.  A critical bug made it to production.  Create the patch on this branch and merge it back to Master when it passes testing.  Also merge it back to develop to ensure it gets back into your baseline code the dev team is working on.

 

SmartGit and GitFlow

The really cool part about this method and using SmartGit is that I can easily follow this model with one button-click; creating a new feature that is super-easy to integrate into the develop branch later with another single-click.    SmartGit , when using the Git Flow integration, will automatically manage the branches including the merging, deleting (as per your choice) the finished feature branch, and all other overhead of the branch management, even ensuring you’ve pulled the latest develop/release master so you don’t get out of sync.

If you get the entire team using the same model, and possibly even using GitFlow-aware tools it will make it far easier for everyone on the team to understand what is going on.   If you don’t already have a well-established branch management model I suggest you make one, or better yet follow a model other teams may also use like GitFlow.    No matter how big and established your team is, at some point it is nearly inevitable you will end up pairing with others outside your organization.  At the very least it will make on-boarding new developers a lot easier if we all speak the same language.