I’ve been in several different companies now, and each of them has had different ideas on what the ideal branching method is. There is no one perfect branching strategy for your company/product. You can probably get any strategy to work with your team if you want. Today, I’m going to introduce you to a few of the methods that I have previously used. From Github Flow to a straightforward Git strategy, you’ll find something that works for your team.
Simple Git Strategy
This is something that I’ve used when I’ve worked on a project myself. You might just think: commit to master all the time. Unfortunately, that’s not so great. What if you’re working on a new feature or refactoring something and a very important bug on live happens? Well, you could commit your current changes and then go back to the last commit that you released to live and branch off that. But then you have to merge into your existing code, and it’s just complicated.
The simple Git strategy that I have for myself is:
- Master is what you have in your live environment. Always keep master as the branch that can be redeployed. You never know when you might need to redeploy to deploy to a different server. Keep this branch clean.
- Create a branch from master when making any change. Even bug fixes. You can name them anything you want. Merge back into master when you deploy.
Simple. This will keep your master branch deployable and allow you to create features/bug fixes/etc., without having to worry about deploying because you know you can trust master. If you break master with a change, it’s easy to revert that code you made if it’s going to be a big fix. You can see where you’ve merged into master and can click Revert.
Github Flow
It’s almost identical to the simple strategy above, but you start to introduce pull-requests. These are useful when working with a team. You also know that master is always ready to deploy. If you want to see how it works in action, you can visit https://guides.github.com/introduction/flow/. They have a nice explanation with cool graphics.
Git Flow
In my opinion, this is the most complicated workflow and only really useful if you release once every x months or every quarter or so. If you have daily releases, this strategy is far too complicated and will take up too much of your time. I guess it’s also useful if you’re many teams working on the same website. But again, if you release more often, Github flow is likely to be better than Git flow.
- Master is what you have released. Master is your truth. Never commit directly to master.
- Develop is you dev branch. It’s kind of like master for developers. This is the branch that you’ll use to create releases.
- Create feature branches from the develop branch. You will merge back into the develop branch whenever you finish a feature or bug fix or whatever. Some people may even commit to the develop branch directly if they have small changes. It’s all okay because you build up the develop branch to create a release.
- A release branch is created from the develop branch at any point of time you feel you have enough features for a release. This is what you’ll test and deploy before merging into master and develop again.
- A hotfix branch can be created from the master branch. This is for when you have a bug on your release that can’t wait until your next release. You’ll merge this back into master and develop branches when finished.
For a nice visual representation, I recommend looking at https://danielkummer.github.io/git-flow-cheatsheet/. Although it’s not as interactive as the Github flow, it’s still a very good visual representation and guide.
So, one thing to always do is: Keep master clean. Keep master deployable. Use branches. As for the preferred way to use Git, that depends on your requirements and team size and how often you release. Just remember that the more complicated your branch strategy is, the harder it will be to onboard new developers. If you have processes around all these things, new developers may be unsure when they’re allowed to do what. In my opinion, I do like the Github strategy. It’s simple and easy to implement and keeps your developers honest.
Reposted on Medium.
Leave a Reply