Day 18 - Git (Version Control) (n.)⚡️
Please don't stop the flow (⚡️BetterFriend Project Day 8 - 38)
Git [git]
noun.
: a contemptible person, often a fool
: a bastard (I’m not making this up)
Quick Recap:
Stay in touch w/ Friends
We are building a simple v0.1 of BetterFriend app by using WhatsApp Chatbot to remind people their loved one’s birthday with AI.
MISSION ABORT!
The first thought that comes to mind when I think of using AI for anything is how can I stop this beast when things go wrong. It’s like owning a tiger, I need to be able to tell it to stop before it kills everything. Maybe this say more about me being a control freak, but I know I’m not alone in this.
The good news is, there is a way to stop the terminators and even go back in time like in the movies. We use a tool called Git. No it doesn’t mean bastard in the British Dictionary. It’s this:
Git is a distributed, open-source version control system. It enables developers and data scientists to track code, merge changes and revert to older versions. It allows you to sync changes with a remote server. Due to its flexibility and popularity, Git has become an industry standard as it supports almost all development environments, command-line tools, and operating systems.
History of Git is pretty cool. It was created in 2005 out of necessity.
Everyone’s overly excited about vibe coding and not enough people are learning about Git Best Practices. When AI is going berserk we need Version Control more than ever. Just look at the latest Replit Scandal:
https://x.com/jasonlk/status/1946239737368592629
Time Machine
At one point or another, every man comes to face an IKEA table that looks nothing like what’s in the instruction book. Even with step by step guides, we screw on the wrong side all the time. Unwinding this sucks.
Software is even worse. Code is added and deleted all the time. It’s infinitely more complex than an IKEA table. Luckily for us, we have a tool to go back in time - JUST before the wrong part was screwed on to the table. Only if we use the best practices.
It’s just like in Pokemon or any game we have to manually click save before fighting a big boss in case we die. When we die, we can start over from before the boss battle and not from the beginning. Git determines these save points for building software.
I found the OG best practice that created what’s known as Git Flow (Best Practice) from 2010 that MOST of engineering teams follow. The graphics that describe the process at first glance looks absolutely insane for a normal person to read:
The OG article also referenced Github’s text instructions that’s still confusing in my opinion: https://docs.github.com/en/get-started/using-github/github-flow.
Honestly the article explain it pretty well but I’m going to take a stab at explaining it to myself as an outsider who doesn’t code.
Git Flow
We are going to stare at this graph for the next few minutes:
Basically we got 5 different branches like a tree. There’s the trunk - the tree itself.
This thing dies the tree dies. The other branches can die and can grow back.
We call it MASTER = Tree Trunk. We have one job, don’t kill this thing.
Master - I want to think of the Instagram app that we can open right now on our phones. We crash this you are dead. 2 Billion IG addicted will threaten to murder our family because the app is down. It’ll be a global headline.
Hotfixes - Think if we found out that someone can steal sensitive information or money from our app. We use it to only fix that MISSION CRITICAL BUG and we put it live into Master.
Tree analogy: we found a deadly fungus growing on the trunk, we need to kill the fungus immediately by spraying on it with anti-fungal.Release Branches - This is the getting ready to share with the world stage. Before putting it live for billions of people to use. We want to make sure nothing is wrong. Squash all the bugs. Tighten the screws. Clean up. Not adding any new features to this.
Develop - This is basically where the magic happens. This is like the second biggest branch that’s the most important besides the Master. It holds all the new features that are added to it and this is where we can experiment. When we are ready, we push this into Release Branches.
Feature Branches - Small branches attached to the big Develop branch. Here we can add new stuff, anything we want. Can be a new way to click a button or adding video or image, or a new upgrade of the user interface. Everything is on these branches and then get merged into the Develop.
So if Instagram wants to add a new button:
The button is added on these branches:
Feature → Develop → Release → Master
We can manually create these branches or there are FREE tools for it - we are lucky to be in 2025.
New Best Practice
Big companies are still sticking with Git Flow because they have too much to lose.
Startups since 2016 have switched over to something a lot faster called:
The original website absolutely sucks at explaining it for a non-developer like me:
Basically all you need to know is - you create a branch as it goes, you name it one of these things:
We merge them into the MASTER or in this case MAIN a few times per day or once per day however we want, and we delete the branch.
Also need to set up Github Action for automated tests.
Ask ChatGPT this:
”how to set up github action for automated tests”
It will walk us through step by step.
Tools to manage Git Flow!!!
If you hate Terminal as much as I do, you would find every tool that has a beautiful drag and drop UI. Per recommendation above, I’ll use GitKraken and let you know how it goes in future stories.
Ultimately, I don’t see the point of Terminal or code only solutions - sorry devs.
Sam Altman seems to agree with me:
We were invited to chat with Sam Altman. One of the most interesting conversations I’ve ever had.
I asked him: “What’s the future of software engineering beyond the IDE?”
His answer?
“Starcraft.”
Straight face.
We all paused: “Haha…what?”
Then he explained:
“You tell your workers to build a fortress here, send your troops to gather resources elsewhere, and trust the work gets done. You’re not monitoring every step, but you can zoom in at any time to see what’s happening.”
That image stuck with me.
Not code editors. Not dashboards.
Just a map, commands, and trust in autonomous systems.
Last Thoughts
In the Git Flow vs. Trunk Based Development (TBD) fight to manage version control, I think we will see a new version of Git Flow emerge with AI agents.
I’ve already heard about 5-10 AI agent engineers developing different features at the same time and then it’s reviewed by a human engineering manager. I think using the TBD, a single trunk branch structure creates friction in this case. I’d much rather review all new features and updates all together than have them separately commit and update when it’s ready. Me, the human, I’m now the bottle neck for AI coders.
And if we have 10~20 AI agent engineers building, we will need even more structure in place, not less.
This is the most cutting edge of AI development - someone somewhere will invent a new way of managing AI Agents and their deployment. Maybe it will be an adaptation of Git Flow, or something else entirely new. Exciting times ahead.
See ya tomorrow!
(⚡️BetterFriend Project Day 8 - 38)