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