This post walks through how I created a simple Git workflow on GitLab, worked across branches, and handled my first merge conflict with confidence.
So I built a small project called daph-git-tree to visualize the flow of branching and merging. It wasn’t about complex code,just understanding how branches evolve and come back together.
I began with a few commits on main:
Initial commit
first commit
second commit
third commit
Then I created a branch from an older commit instead of the latest one. GitLab’s dropdown didn’t make that obvious, but I found the option by opening the commit details and creating a new branch from there. That’s how feature-branch was born.
From there, I worked on both branches in parallel — small text changes, nothing dramatic, but it made me appreciate how Git isolates work.
When it was time to merge, GitLab threw my first conflict warning. Both branches had modified the same README section differently, so Git needed me to decide what stayed. It looked something like this:
<<<<<<< feature-branch
My changes
Main branch changes
main
I picked the final version I wanted, removed the markers, saved the file, and completed the merge. N
Opening the repository graph afterward was the best part. I could see my branches split and merge visually, which is exactly how teams collaborate every day.
Along the way, I made some small mistakes: committing to the wrong branch, getting confused in the Web IDE, or forgetting which file I’d just edited.
By the end, I’d practiced:
Creating and merging feature branches
Handling merge conflicts
Reading Git graphs to visualize work history
Making (and fixing) real mistakes without fear
It reminded me that Git isn’t about memorizing commands and more about building habits around clarity, versioning, and collaboration.
The repo graph now has extra commits from my learning curve, but I kept them all. They tell the real story of how understanding grows through use.
Top comments (0)