tl;dr: Pick one way to use git and enforce it. Organize your git branches with development/build/release pipelines in mind. Also use GitHub.

Here is your disclaimer

Anyone who started their careers using CVS or SVN (or worse) can attest to how transformative git was for the industry. However, using git badly can really fracture and frustrate a rapidly growing engineering team. It can make or break your company. We have seen this first hand. Let me explain.

DON’Ts

Running your own git server

This one is kind of off topic but worth mentioning. We had someone at a company insist on running our own git server because they were paranoid about “leaking code” onto the internets. Maybe somewhat valid in this case, since they were checking in all sorts of passwords and secrets but I think the real answer here is DON’T CHECK IN SECRETS. Don’t run your own git server, use GitHub. It is good.

Check code into master branch

DO NOT CHECK IN CODE DIRECTLY TO MASTER.

Don’t name your branches randomly

Don’t name master branch “MASTER” or “Master.” Don’t name develop branch “Develop” or “development” or “Development.” Don’t name your feature branch davesbranch1. Consider naming your feature branches the same as your tickets.

Different strategies for different teams

We had 3 different ways of doing git across the organization. One team used a master branch with the linux email patch and maintainer model with gerrit for review (which everyone kept doing incorrectly). One team liked to have a single master branch and directly merge feature branches to master. I forget what the other team did. Anyways, pick one and stick with it. Unless every team has their own dedicated devops and QA teams, you will just make everyone really upset. What strategies are good? We will get to that in a minute. Also, use GitHub.

DO’s

Use GitHub

I really don’t see any reason not to use GitHub. Just use GitHub.

Use Branch Protection

Set master and develop branch to only accept pull request

Git Branching Strategy

Let’s lay down some ground rules:

Always tag releases from master

Always do feature branches from develop

Always merge hotfixes to both develop and master

Your git branching strategy should be tailored for your use case. This is to say, tailor it to your particular build and release requirements. For example, if you want to use CI/CD tools to build your and deploy your dev and staging environments, then you should have something like this:

Drink Me.

There can be variations in where the tagging happens etc, but the general process would be like this:

Make develop Branch from master . Set develop as the default branch in GitHub. Set master and develop as protected branches. This way people will not be tempted to just commit and push directly to these. Make feature branches from develop and develop awesome features. Pull Request and merge back to develop . At this point, CI/CD should trigger automatically and push your new awesome features to dev environment. You do some testing! Everything looks good so you initiate Pull Request from develop to master. Everyone approves this Pull Request and you merge to master . CI/CD should kick off build and push to staging environment. QA, Regression, etc Testing ensues! Things look great. QA gives stamp of approval. Git Tag this release as v0.1 . Your CI/CD should see tag and automatically build and tag your docker image with v0.1 (assuming you are using docker). Deploy person will take tag v0.1 and push to prod!

What about Hotfixes? Hotfixes refer to situations where you need to quickly fix a bug in production. It’s tempting to go fix it on master and push it ASAP. Please don’t! You will end up with situations where the fix gets rolled back down the line because it did not get merged back to develop . Do this:

Branch from master to hotfix1 Do fixing on hotfix1 . (Optional: You can configure CI/CD to always build hotfix* branches and push to staging environment. Depends how you want to approach testing of hotfix branches) Pull request and merge hotfix1 to both develop AND master . Test on staging environment, tag master as v0.1.1 and release to prod!

This is generally a good structure if you are only worried about one version in production at any given time. If you are maintaining multiple simultaneous release versions and will have hotfixing on each, you will probably want to follow something like GitFlow which has actual release branches.

That’s about it! Of course you will have slight variations depending on your requirements, but the important thing is:

Discuss, don’t rush and stick to the process you create!

Have a good one and let us know what you think in the comments! Claps are good too =)