Workflow & Tools
Git Branches & Merging
Parallel realities: How I develop new features without endangering my stable project.
Imagine you had an exact copy of your entire project in which you could absolutely break everything, while the original remains safely locked away in the cupboard. That's exactly what branches are.
In the past, I built new features directly into the main code. When an urgent bugfix came in, I had a problem: my code was a mix of construction site and stable parts. Today, the main-branch is sacred to me. I'll show you how I work with branches to tinker stress-free on multiple ideas at the same time.
1. The Role Distribution
To keep my time machine from descending into chaos, I strictly distinguish between three types of branches. Each has a clear purpose:
2. Creating & Switching Branches
Instead of typing two commands, I use this shortcut. It creates the new reality and beams me there immediately.
3. Worlds Converge: The Merge
When my feature is finished, the big moment comes: I bring the changes back home. Important to understand: A merge always happens into the branch you're currently on.
# 1. Switch back to the main branch
git checkout main
# 2. Merge the feature branch into main
git merge feature/new-login-design
# 3. Delete the local branch (optional, but clean)
git branch -d feature/new-login-design
# 4. Delete the remote branch (optional, keeps GitHub clean)
git push origin --delete feature/new-login-design
I call that the 'finish line'. First I switch to the target (main), then I pull the feature towards me.
After a successful merge, I usually delete the feature-branch immediately with git branch -d. This keeps the list clean and prevents me from getting tangled up in old branches.
4. Live Simulation: Branch & Merge
Try it live here. Create a branch, make a few commits and merge them back into the main branch. Watch how the lines draw your project's history.
5. Merge is Not the Same as Merge
Depending on the situation, Git decides for itself how a merge is performed. The result looks different, but in both cases it's correct.
Fast-Forward Merge
The target branch hasn't changed since the branch-off. Git simply moves the pointer forward – no new commit is created.
Classic Merge
Both branches have evolved. Git creates an additional commit that merges the histories together.
Both variants are completely normal. What matters is not the form of history, but that it remains clear when and why code was merged.
6. My Rules in Daily Work
Branches are not an end in themselves. With a few simple rules, the workflow remains clear and predictable – even after weeks or months.
I never work directly on main. Not even for small changes. Once you break this rule, it quickly becomes a habit.
Before I merge, I always consciously switch to the target branch. This way I keep control over where the code actually flows.
Long-lived feature branches increase the risk of merge problems. Better to merge more often than work in isolation for weeks.
After a successful merge, I consistently delete feature-branches. Old branches only cause confusion and are almost never needed again.
7. Classification & Outlook
Branches give me the freedom to work on ideas in parallel without endangering my stable project. Merges are the controlled moment when these ideas are brought back together.
Conflicts, rebasing, or more complex strategies are also part of everyday Git, but would go beyond the scope here. That's why I cover these topics in separate guides in much more detail.
If you keep branches clean and perform merges consciously, you've already understood the most important part of Git. Everything else builds directly on that.