GitHub Flow

https://guides.github.com/introduction/flow/

As you know Git is the most popular version control system nowadays which successfully has superseded its predecessors like SVN, Mercurial and Perforce. Probably you’re also familiar with GitFlow which is a branching model for Git, created by Vincent Driessen. The model is a git branching and release management strategy that helps developers keep track of features, hotfixes and releases in software projects. The workflow needs a lot of commands to type and to remember, so there’s even the git-flow library of git subcommands that helps automate some parts of the flow to make working with it a lot easier.

A little description of GitFlow from the Juri Strumpflohner blog:

You have two main branches:

  • master branch contains the latest production code that has been deployed, and versioned with appropriate tags for each release.
  • develop branch that gets branched off master and contains the latest code for the next feature that is being developed. For each new feature there might be lots of feature branches (always branched off the “develop” branch).
    Beside the main branches, there are so-called supporting branches:

Beside those, there are supporting branches:

  • feature branches contain the development state for a single feature of the overall product (i.e. a user story). They are merged off the develop branch.
  • hotfix branches are branches for quick and severe bugfixes. they are usually branched off the master branch, fixed in the hotfix branch and then merged back in master and develop as well.
  • release branch is a branch for preparing the next release. No new features will be developed on this branch but rather it contains some last fixes (also bugfixes) and adjustments for going into production.

A picture is worth a thousand words:

http://nvie.com/posts/a-successful-git-branching-model/

I use GitFlow in my daily basis at work and I find it very useful. It really helps to track changes in the repository, especially in the team consisting of many developers.

When I started developing the GoogleTasksManager project I was wondering whether the GitFlow isn’t too complicated for me. Though there’s no team, I’m the only one who’s working on the project. Maybe there’s a better way of managing the repository than GitFlow in that case? After a quick research on the internet, I found that there’s another way, GitHub Flow.

http://www.nicoespeon.com/en/2013/08/which-git-workflow-for-my-project/

As you can see on the diagram, GitHub Flow approach is much simpler than the previous one. There’s only one important branch master, which should be always stable and ready to deploy to the production at any time. Feature branches are branched directly from the master and merged back to it when the feature is ready. What’s important, the code should be deployed to the production directly from feature branch to check if everything works correctly there, before it has been merged to the master. So there’s no need to have develop and release branches.

http://theodi.github.io

I really like an idea of deploying to the production directly from the feature branch and to not have develop and release branches. I think that GitFlow would be over complicated for me at the moment. So, I decided to give GitHub Flow a chance and it’s been working very well for now.

Sources:
Understanding the GitHub Flow
Implementing the ‘Git flow’
Git Flow vs Github Flow
A successful Git branching model
Introducing GitFlow
Which git workflow for my project?

You may also like

3 Comments

  1. You said that you are currently the only one who’s working on the project. So at the moment, do you also use feature branches in development?

    I’m wondering about the benefits of the flow you described compared to just commiting directly to the master branch (something that I started to do). I guess that in a team branches would be needed for pull requests or to allow independent work on features. Are there other advantages? 🙂

    1. Hi buli. Yes I’m using feature branches now and I think that I’ll continue to use them.

      First of all, feature branches allow you to get more information when you are looking at the code history. Especially if they are related to the task with a description in a work tracking system like Jira. I have to start creating tasks and creating branches related to them. By the way, it’s important to put an effort into writing descriptive commit messages to try to explain why you’ve done the changes. Don’t be afraid of writing long ones.

      What’s more, feature branches also allow you, to work on different aspects of the system at the same time. of course you can do it without them but by using feature branches you can easily change the context of your work. It is also simpler to revert changes related to some functionalities if there is such a need.

      From practical point of view, you can also push your changes to the remote branch even if they aren’t working as expected or even aren’t working at all. At the same time you can have your master branch up and running.

      These are the reasons I’m using feature branches. But remember what is working for me or even for the majority won’t necessarily be the best approach for you. If you are fine having only the master branch and it works well for you, don’t change it because of other people’s opinions 🙂

      And what is your experience of committing directly to the master for now?

  2. Thanks for your explanation! Sorry for late reply, but without email notification it took me some time to discover your response 😀

    All that you mentioned about feature branches is a good reason to use them in a team work or in a complex project.

    For a simple, one-person project, eg. repository with blogposts, I’ll stick with a single master branch, and I even found a logical explanation why this is enough for me 😉 If only one person works on a project, the total time to implement all planned features is constant, no matter in what order we do them. Therefore it brings no benefit to work on features in parallel. So linear history on a master branch truly represents the history of changes, and there’s no reason to complicate it.

    Of course anyone might wants to choose a different workflow 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

*