GitHub Flow – implementation and overview

22nd January 2024| Katarzyna Radecka

While talking about software development, choosing the proper workflow and branching strategy is crucial for the project’s success. After all, we all want stable environments where changes can be applied quickly and deployed on time. Over time, multiple branching strategies were developed, each of them with its own pros and cons. Today we will have a closer look at GitHub flow and why and when it can be appropriate for your team.

Following the Git Flow, which offered us clear branching strategy and workflow, the simpler version was developed, called GitHub Flow. GitHub Flow simplifies the concept of repository, getting rid of develop branch, and focusing only on main branch. Instead of implementing new changes on develop to merge them later to main, we create feature branches directly from main branch and pull request them also directly to main.

Why would we want that? Isn’t it dangerous, to commit all our changes instantly to main branch? Don’t we create the risk to destabilise the release environment?

Such doubts are completely reasonable and it is absolutely ok to have them, so let’s firstly define, when GitHub Flow will only bring you profits with minimal risks.

1. Your team is experienced, or just good at following the instructions – there is no way someone decides “I will just rebase this, I don’t feel like solving the conflicts today”. First thing we need to understand while choosing GitHub Flow – the main branch is sacred, we will develop on it, we will deploy from it, everyone must respect that. If your team is good at following the flow, you’re good to go!
2. Become friends with tags! Once we pull request everything to main, it can get crowded with commits on the branch, and it’s always good to have all your affairs in order. Start tagging the milestones on repository. Create tags for each release you do, in case new release needs to be rolled back, you can always just go back to the tagged version.
3. Have your configuration in order. If we are working with GitFlow, we can allow some configuration to be hardcoded and Gi ignored. With GitHub Flow this gets a little trickier. Our code for all environments will be kept on just one, main branch. Before you decide to switch to GitHub Flow, analyse all the configuration carefully.
4. Each deployment is preceded with regression – you need to ensure the code is thoroughly tested on the main at all times.

If you can follow those requirements,

the GitHub Flow is just for you! But why would you want to choose and follow this flow? Well, if your project requires continuous deployment or you’re working on SaaS project, it is just the simplest approach you can follow.

Main pros of GitHub flow include:

Convenience: you have to maintain only one main branch, even if you need to apply quick fix to production, you don’t have to worry about cherry-picking hotfixes, you can follow basically the same strategy as for any other fix: 

       o Create hotfix branch based on last release tag,

       o Fix the bug

       o Deploy the fix to production

       o Merge hotfix branch to main to integrate it with the rest of new code

• Easy onboarding: in case any new developer joins your team, GitHub Flow is much easier to learn than classic Git Flow. Easier onboarding and very simple flow makes the environment less prone to glitches
• Minimal risk related to merging: after we develop and test the code, and regress the main branch, we never move this code across repository again. This eliminates the risk of wrong conflict solving while merging the code to production environment.
• Stability: at any time we can be 100% sure, that the code we have already tested and regressed is exactly the same one running on production, not a single commit will be different between our environments.

Speed: you will never consume any time again to think “Where should I create hotfix branch” or “Is it bugfix or a feature”, you don’t have to differentiate between develop and main anymore, because there is simply no develop. All the work you do will always just be the same steps: new branch -> coding -> pull request.

We hope our short overview of the GitHub Flow was at least a little helpful for you, and we can assure – it makes life easier. Believe us, we know!

If this is of interest and you would like to explore further then please contact info@anyaconsultancy.com

For more information on ACS, technology and domain expertise, please visit our website at www.anyaconsultancy.com

About Anya Consultancy Services

ACS is a global SI headquartered in the UK with offices On-shore in England and Scotland, Near-shore in Romania and Portugal and Off-shore in India.

We started in 2010 as an integration specialist, working with big enterprises to integrate ERP, Manufacturing, Warehouse and e-Commerce solutions.

Since that time, we have widened our portfolio via a mix of organic growth and acquisitions to encompass a Hi-tech engineering capability, our successful IT services business and a growing portfolio of SaaS solutions from in store radio station management through to Digital catering solutions feeding ‘000s of NHS patients every day.