Welcome to the final part of this review of the Pluralsight course Using Git with a GUI by Xavier Morera.

Xavier is an entrepreneur, project manager, technical author, trainer, Certified Scrum Professional & Scrum Master and Certified Microsoft Professional and Microsoft MVP.

He has spent a great deal of his career working on cutting-edge projects with a primary focus on .NET, Solr and occasionally iOS. He’s also a fellow Simple Programmer blogger.

In the module we go beyond the basics.

Also in this series:

Part 1 – The Case for Git with a GUI
Part 2 – What You Need to Know About Git
Part 3 – Mechanics of Using Git
Part 4 – Git to the next level

Branching Strategies for Every Occasion

In the earlier modules, Xavier taught us the basics, and also some of the not so basic things that we can do with SourceTree.

We’re almost ready to start using SourceTree for our own software projects, but first we need to learn about effective branching strategies, so that we can choose the right one for our project.

Xavier begins wiith Braching 101, giving a quick recap of some of the lessons we learned earlier.

In this module Xavier walks us through 5 branching strategies so that we can pick the one that works best for our own needs.
These strategies are applicable even if you decide to use Git without SourceTree.

Centralized Workflow

This is the easiest way to get started and is just like SVN or TFS, but with the advantages of Git.

These advantages are:
– Local and private repository for each user
– Git branching model for development

This strategy involves rebasing. It doesn’t make use of Git’s full capabilities. Xavier runs through a few different problems with this strategy

Feature Branch Workflow

This creates a dedicated branch for each new feature. It allows parallel work.
Xavier discusses integration with other Atlassian products: BitBucket (Git Repository), Jira (Issue Tracking & Project Management) & Bamboo (Continuous Integration & Build Server)

When pushing feature branches, it’s important to have a clear understanding of merging and pull requests.

Merging incorporates changes from the current feature branch into the master branch. It’s required that the feature branch is up to date with all conflicts resolved.

A pull request is a request to merge. Permissions for merging might be limited to certain developers depending on your setup.

Gitflow Workflow

This strategy came from Vincent Driesson is 2010:
http://nvie.com/posts/a-successful-git-branching-model/

Xavier loves this workflow and says it’s great for complex projects. It allows teams to work in parallel without much disruption.

SourceTree comes with Git-flow integrated.

Demo: Gitflow Workflow from SourceTree

We start with a single master branch. By clicking on the “Git Flow” button, we are shown a dialog for creating our 5 branches, which are:

Production branch
Development branch
Feature branch
Release branch
Hotfix branch

The default names are “master” for the prodction branch, and all other branches name as above.

If we click OK we see the develop branch is created and set to the current context.

Now if we click the “Git Flow” button again we see a dialog with the following options:

Start New Feature
Start New Release
Start New Hotfix
Other Action…

The Start New Feature button displays a new dialog where we enter the feature name and choose where to start at.

If we click on “Git Flow” a third time we have several options including “Finish Feature”, which takes us to a Finish Feature dialog.

Gitflow advises against rebasing, but it is good practice to have a tidy workspace. So it you don’t need your branch anymore you can delete it.

Forking Workflow

The forking workflow is key primarily in open source but is also used in the Enterprise.
All developers push to their own server side repository and changes are integrated back into the main repository via a pull request.

The main repository might keep evolving, so we need to keep up to date with it.
We must pull changes before committing our own changes and doing a pull request.

Dictator and Lieutenants Workflow

This is the workflow that Linux uses. There’s a sort of 3 tier hierarchy here.

At this top, there is a benevolent dictator.

In the middle, there are the lieutenants.

And then there are the lowly developers at the bottom.

There’s a blessed repository that all developers pull from. Developers rebase on master, and lieutenants merge developers’ changes into their branches.

The dictator merges lieutenants branches and pushes to the blessed repository.

That’s a wrap

Alright! We’ve covered a LOT of ground in this course. Git is a big topic, but I found this course has given me quite a bit more confidence using it, and I hope it helps you too.

Xavier also gives a retrospective summary at the end of this course. Thanks to Xavier for producing the course. If you haven’t seen it yet, go watch it! And follow him on Twitter.

Thanks again to Jose Pimienta, UI Engineer at alpisdesign, for the photo. You rock!

And thanks for reading, and keep an eye out for the review of Rob Conery’s Node Application Patterns, out this weekend!