Git Github Gitflow

What is Git

Git is a distributed version control system created by Linus Torvalds in 2005. The same guy who created linux. Genius.

Centralized vs Distributed

Before Git, Apache Subversion (SVN) was one of the popular version control systems. SVN is a centralized version control system which stores all the files in 1 central server. If two developers are working on the same file, they will have to resolve conflicts all the time. The developers cannot commit the changes if they are offline unlike Git.

On the other hand,

Git commands

Below is a list of basic commands to save your changes as commits and push them up to the server (Github) using Terminal. I'm a terminal person. No GUI. I know that VSCode has built-in user interface for git. There are existing Git Clients too.

git checkout develop # Go to develop branch
git add . # add all the files you have edited
git commit -m "Add changes to the files" # add commit message to the files you've added
git push origin master # Push the commits to master branch in the server

Check out this git cheatsheet

Github

A hosting service that works with Git. There are alternative hosting services that work with Git as well. For example, Bitbucket and Gitlab. However, I like Github the best because the UX is smooth af. FYI, Microsoft acquired Github and I find this tweet hilarious.

Gitflow

A popular branching strategy created by Vincent Driessen. My team at HOOQ is using it. We use it together with Git Hubflow and we are puking rainbow. There's no right or wrong branching strategy, you just have to find the most suitable model that suits your team.

Trunk-Based Development Workflow

Everyone works on master branch only. This is useful to avoid long lived branches which result in accumulating merge conflicts.

Branches

1. Master branch

Pros

• Force developers to do small commits and changes frequently
• Easy to understand
• Iterate quickly, ship faster

Cons

• Incomplete features may be released if no feature flag is used
• Introduce bugs easily
• Frequent merge conflicts if developers work on the same files

Gitflow Workflow

Master branch is the stable branch. Nobody touches it. Everyone works on their own feature branch then opens a pull request to merge feature branch into develop branch. A release branch is branched out from develop branch and then merged back to master and develop branches. This encourages continuous delivery.

Branches

1. Master branch
2. Develop branch
3. Feature branch
4. Release branch
5. Hotfix branch

Pro

• Easy to work in parallel
• Release branch is useful to track releasable features

Cons

• A little complicated for first time user

I will direct you to an authentic Gitflow explanation over here by the creator himself.

Git Hubflow

One-line commands for using Gitflow with Github. This amazing tool is created by DataSift You guys are da MVP.

Normal Git commands

git checkout develop
git pull origin develop
git checkout -b release/production-1.0.0
git add .
git commit -m "Add new release"
git push origin release/production-1.0.0
git checkout master
git pull origin master
git merge release/production-1.0.0
git tag production-1.0.0
git push --tags origin production-1.0.0
git checkout develop
git pull origin develop
git merge master
git push --delete release/production-1.0.0

Amazing Git Hubflow Commands

git hf release start production-1.0.0
git add .
git commit -m "Add new release"
git hf release finish production-1.0.0

What is the best workflow?

There are numerous factors to consider when deciding what is the best branching strategy for your team. Does your team require continuous delivery? How comfortable are your team members adopting an entire new workflow versus tweaking existing workflow to suit their needs?

Personally, I like gitflow because of the separation of concerns for different features and the ease of creating a release with releasable features. But I do believe there is no single best workflow.

There are more articles over here and here that compare different workflows and their benefits.

Disclaimer

I have not tried SVN. Not entirely true, I tried playing with SVN but it was too complicated for my liking. I am spoiled by git. There may be parts in the illustration that are inaccurate, please correct me!

Also talk to me at Twitter @linxea_. I'm bored over there.

Also, I made a slide for my workshop tomorrow at https://linxea.github.io/git-github-gitflow. Feeling fancy with reveal.js.

References

https://docs.microsoft.com/en-us/azure/devops/repos/git/git-branching-guidance?view=vsts
https://datasift.github.io/gitflow/IntroducingGitFlow.html
https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow

Comments

[Ivo Limmen]

Technically git is even more cool. When the server is down you can just start gitweb and let your colleague pull and push directly from your local repo.This is the true intention of git. Only because we like to store our code in one central place for backup purposes (+ large corporations don't really get git) we use products like stash/bitbucket and use git like subversion.

[ann lin]

Yes git is awesome! Oh damn, I didn't think of this case before, pulling directly from local machine. 😂 That's definitely useful if the server is down during important merge between features. Will play with gitweb.

Haha, backing up code is definitely one solid good reason! Given a scenario that a malicious hackers hack all the computers, at least the code is still safely stored remotely. Another extreme scenario is that a newcomer will have no access the to codebase if all the employees are away for holiday. Nonetheless, having a central repo in the server (like Github) promotes transparency to what everyone is doing because we can easily see the changes across branches.

The beauty of git is that we can use it in any way that suits us.

[Victor Yarema]

There are many good articles that explain why gitflow is redundant without any actual benefit. And still there are people that continue to advertise it. This is sad.
For those who really want to be effective I recommend to search for and read about "trunk based development in git".

[ann lin]

Don't be sad. I've updated the post to give a slightly more balanced view. There are indeed good articles that explain why gitflow isn't beneficial for some teams and vice versa.

I found a good article at docs.microsoft.com/en-us/azure/dev... which explains how a trunk based development is being used at Microsoft with the goal to encourage small simple changes. I like how they tweak the workflow to meet their needs. However, for an ambitious startup that is continuously churning breaking features, trunk based workflow may not be suitable. There are just so many factors to consider before we can deem it effective or not.

In my team, I can proudly say that we love gitflow. ✌️

[Victor Yarema]

The is also a terrible lie in the article. It states that "A Simple Workflow" has a drawback like "Many merge conflicts". At the same time it says nothing about the amount of conflicts in case of "Gitflow Workflow". The truth is that the amount of conflicts has absolutely NOTHING to do with workflow and is totally the same in any workflow.

[ann lin]

You're right on this one. The amount of conflicts does not depend purely on the type of workflow. I've not added any context to the merge conflict point which causes confusion and a terrible lie.

Given a scenario where 2 developers work on the same file and the same piece of code and commit frequently, it would result in frequent merge conflicts. Of course the two developers can sit together to resolve the issues together in the beginning to prevent more conflicts. However this may occur regularly and result in a waste of time. Personally, I just feel that it's more productive to resolve the conflicts once and for all when the features are done.

[Mario Sánchez García]

Thanks for that easy explanation of GitFlow! I have only seen and used the simple workflow until now, I'll take a look at it. The link of the "advanced version" from the author does not work! I think you need to remove the final dot and it would be fine ^{^}

[ann lin]

Thanks for reading! 👍 👍👍 Gitflow is a scalable branching model which is suitable for a growing team. I have a few comments on the final dot, I HAVE REMOVED IT! THANKS!

[Robert Thompson]

Your Gitflow explanation link has a period near the end that invalidates the URL.

[ann lin]

I know! 😢 I've fixed it! Thanks!