This week I read Martin Fowler’s article “Patterns for Managing Source Code Branches.” I thought it was a good fit because in CS348 we’ve been talking about version control and how teams actually get code from peoples machines into a real product, this article is basically about that. Last spring I taught GitBetter, which was a git workshop for the CS department that was mostly freshmen and I wanted to see how someone who’s been doing this for a while thinks about it.
Fowler says that there isn’t one right way to branch. And everything starts with a mainline which is the main shared branch that everyone works off of and that you keep it healthy by building and testing whenever someone commits so it doesn’t break. Then he goes into feature branching vs continuous integration. With feature branching you work on your own branch until the entire feature is done and then you merge it but with continuous integration you merge small pieces into main at least once a day. He also talks about release branches, hotfix branches, git flow, etc. but his main point is that it depends on how you and your team work and what you are comfortable with.
The part that I guess stuck with me most was when he talked about how often you merge things. He says if you merge more often each merge is smaller and less risky, and when teams mess up with a big merge they start merging less which can create one huge issue. And I guess that made me think about one of my past projects, Companion, which was a client side anti-cheat for select video games. I co-founded it with a small team from 2020 to 2023 and we would work super sloppy on it. We would never commit often and when we did we would constantly cross paths and cause a huge mess and man was that a pain. And knowing more about how to properly use git now makes me cringe when I think about it.
Something I didn’t think about before was that pull requests and code reviews mostly came from open source, when people who you don’t know help you out with your project. And Fowler says that a small team that trusts each other means you don’t need all of that stuff and I couldn’t agree more. I think that just becomes something tedious over time and extremely pointless if you’re working in teams with 5 to 15 people.
Right now I am working on Talon, an anti-cheat SDK that I plan on open sourcing. Since different games could be running different versions, this is where release branches actually make sense. For day to day work I am most likely going to stick with feature branching to keep things tidy. If I ever teach GitBetter again I would talk more about how teams work together and not just the commands, because that’s the real purpose of git.