Git is a great, popular, distributed source control system that most of us probably have encountered in various projects. It’s really simple:
1. Pull changes from the remote origin master branch to your local master branch.
2. Code.
(3). Merge any changes from the remote origin master branch to your local master branch.
4. Push your local changes on the master branch to the remote master origin branch.
That’s it! Simple, isn’t it? Master is always deployable and changes fast.
So why do many people use complex git branching strategies?
Check out this google search result: https://www.google.com/search?q=git+workflow&tbm=isch
The horror!
If you are living by continues delivery, you do not want to see that. That’s a the opposite of continues integration; continues isolation. You part, you do not integrate. Well, technically you have to part a while when using distributed source control systems (otherwise it would not be distribution), but you’d like to part for as little time as possible. Why? Read my post Continues Delivery – Are You Fast Enough? 🙂
Open Source
So, is branching always bad? Well, no, it would probably not exist if it were 🙂 Open source software published at the git framework Github is a perfect example when branching might be necessary. If you develop an application and put the source code on github as publicly available, anyone can clone your code, create a branch, make changes and request a pull request before it is merged with master.
https://guides.github.com/introduction/flow/
This makes sense. Why? Because you do not necessary know the person changing your code. It can be a rival wanting to destroy your work. It wouldn’t work if that person could directly merge into master. A security gate is needed.
Tight Teams
Being part of a team at a company, you work towards the same agenda. You probably have some agreed code standard, and a process the team follows. No one is working against the team, so there is no need for a security gate in the source control system. Hence, keep it simple, don’t branch, use master.
– But we need feature branchi…
Feature Branching
So, you think you need to branch for developing new features? You don’t. There are some nice strategies to achive doing small changes and commit them to the production code continuously, even though the functionality might not be fully functioning.
Feature Toggling
This is a great tool for hiding any functionality that is not ready for production yet. If you havn’t heard about all the other nice perks of feature toggling, I highly recommend you read this article by Martin Fowler: https://martinfowler.com/articles/feature-toggles.html
Branch by Abstraction
No, it’s not source control branching. This technique let the user incrementally do large changes to the code while continuously integrating with the production code. Again I’d like to forward you to an excellent explanation of the subject by Martin: https://martinfowler.com/bliki/BranchByAbstraction.html
Conclusion
Don’t use branching strategies if you work in a tight team that has the same goal. Keep it simple, stupid.
Be First to Comment