However, as the codebase and feature set have grown, we started running into situations like:<\/p>\n
- \n
- “Wait, what was the purpose of this commit again?”<\/li>\n
- “Ah, I accidentally pushed a slightly risky change straight to main…”<\/li>\n
- “I want to revert to a past state, but the history is such a mess that it’s painful to look through.”<\/li>\n<\/ul>\n
This made us realize that just because it’s a solo project doesn’t mean we should neglect the main branch.<\/p>\n
Our goal this time is simple:<\/p>\n
\n
Implement branch protection on GitHub to prevent force pushes to the main branch.
Since we’re doing it anyway, we want to try adopting a standard 3-way merge workflow.<\/p>\n<\/blockquote>\nTarget Workflow: No Direct Pushes to main + A Casual 3-Way Merge<\/h2>\n
The key here isn’t to tie ourselves down with overly strict rules, but rather to:<\/p>\n
- \n
- Disallow direct pushes to main<\/li>\n
- Create a separate branch for any work and push that<\/li>\n
- Open a Pull Request on GitHub and merge it<\/li>\n
- Use GitHub’s standard 3-way merge (the Merge pull request button)<\/li>\n<\/ul>\n
In other words, it’s a pretty relaxed setup that still enforces just the bare minimum necessary.<\/p>\n
We aren’t going as far as setting up mandatory reviews, required CIs, or CODEOWNERS\u2014
none of that “heavy-duty production set” for now.<\/p>\nWhat’s Inconvenient About the Current Way<\/h2>\n
When you’re working alone and pushing directly to main, you run into issues like:<\/p>\n
- \n
- Commit units tend to get messy\n
- \n
- Commits like “saving for now” pile up<\/li>\n<\/ul>\n<\/li>\n
- Bugs slip in unnoticed\n
- \n
- You only realize “uh oh” after it’s already live on main<\/li>\n<\/ul>\n<\/li>\n
- History is hard to read when you want to roll back\n
- \n
- It’s hard to tell at a glance where new features were added versus where bugs were fixed<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
And above all,<\/p>\n
- \n
- The psychological pressure of “I can break main at any second.”<\/li>\n<\/ul>\n
Since the thought of pushing experimental code straight to main started feeling a bit scary,
we wanted to draw a clear line: “Only things that have been properly checked get merged into main.”<\/p>\nApplying “Bare Minimum” Protection to main on GitHub<\/h2>\n
The settings we applied are truly minimal.
Steps:<\/p>\n- \n
- Open https:\/\/github.com\/nando256\/twbridge<\/li>\n
- Click on the Settings tab at the top<\/li>\n
- Click on Code and automation \u2192 Branches in the left menu<\/li>\n
- In the “Branch protection rules” section,
click Add branch ruleset
\n![\"\"](\"https:\/\/donguri3.net\/wp-content\/uploads\/2025\/12\/fa785f46e27f3f1063c45f76a6ef8ceb-1024x658.jpeg\")
<\/a><\/li>\n- Configure the settings as follows:\n
- The psychological pressure of “I can break main at any second.”<\/li>\n<\/ul>\n
- It’s hard to tell at a glance where new features were added versus where bugs were fixed<\/li>\n<\/ul>\n<\/li>\n<\/ul>\n
- Commit units tend to get messy\n
![\"\"](\"https:\/\/donguri3.net\/wp-content\/uploads\/2025\/12\/fa785f46e27f3f1063c45f76a6ef8ceb.jpeg\")
<\/a><\/li>\n