Don’t lose your flow with Sourcetree and Gitflow

Probably you use Git every day, at the office or on your projects, alone or in a team. But, Have you ever asked which metodology is the best for you and your team needs?

If you never did this, check this guide from Atlassian, from this guide I will bring you more info about how to work with Gitflow, the metodology that I like so much and I always use if I can.

The workflow scheme

To explain gitflow I did my own scheme, but is totally inspired by the guide from the article that I wrote few lines ago, this scheme is to bring you more and detailed info about that.

When you open Sourcetree you have the master branch, maybe you have old commits on this branch, it’s not a problem.

We have to configure Gitflow on this repo, click on Gitflow button and check branches names, in this case I respect default names for these.

Now, we have two branches, master and dev, for the first one we have to configure a build and a release to our production server on each commit, but for the second we configure the build and a release to development server. (Obviously we don’t configure this on Sourcetree, you can use something like TFS from Microsoft).

Cool, now we have to check our iteration or sprint and to look that we have a list of stories, that we have to implement. We are going to create a branch for each story like feature/story_name, with Sourcetree you only have to click on Gitflow button and add a new feature.

Write the name of the feature, specify that you want to start from latest commit from dev and a new branch will be created (a temporary branch) now you can see that you have the new folder called feature but that’s only to group all the branches like feature/… there isn’t any real folder, you can check with ‘git branch’ command.

Time to code, probably you will generate some commits, and finally you finish your feature, we have to finish this on our repo, click on the same button and be sure to mark rebase on dev (You can find different opinions about rebase or merge, I took this decision after read on internet, after check Sourcetree options and my personal opinion)

This is our scheme after create some features following this guide.

Now you need to create a new release and you want to do this without affecting to the workflow, click on the Gitflow button and select release, specify a name, for example the name of the version. (v.0.0.1)

Testing your release on PRE server, you will find some things to fix, fix them and create some commits. Finish the release, when you do that you can add an optional tag from this relase to have it on master.

On this point we have a merge to master and another merge to dev (we don’t want to lose our work from release) and this is the result.

As you can see on the scheme, the difference between to do a rebase or a merge is that the first one will put the commits one by one on our history.

Woops! an error appears on PRO server, but we have the hotfixes, from Sourcetree, we have to click on Gitflow button and create a new hotfix, we can change that we want and finish the hotfix to save on master and dev (merges).

This the final aspect of our flow.

And yep a bonus track this image represents some events and actions that are related with our flow, like builds, the validation of a story, etc.

I hope that you have increased your information about workflow Gitflow with git, you can find more info on the post of Vincent Driessen he wrote a lot of theoric info about that.

If you want, you can read this article in spanish, check blog.ckgrafico.com

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.