Git and Version Control: The Infrastructure Nobody Notices Until It's Missing
Branches, merge requests, code reviews: the shared language of a team.
Mert Celal Yılmaz · Full Stack Developer · Updated:
What happens when two developers touch the same line of the same file at the same time? Git's answer sits in the commit history: every change to a codebase gets tracked, tied to who made it and when. Branches let you build a feature away from the main codebase, then merge it back in once it's done.
At ARCA we work on GitLab and track tasks in Jira, inside an Agile setup. When a sprint starts, it's clear which branch maps to which task and who's reviewing which merge request. Skip that structure and even a small team ends up stepping on each other's work in the same repo.
On an apartment management system, I ran sprint planning, task tracking and code review for a two-person team. Even with just two people, merge conflicts, review comments and whether commit messages actually make sense shape how fast the work moves. I picked up BTK Akademi's 'Version Control: Git/GitHub' certificate around the same period, mostly to close gaps in day-to-day usage.
Being able to tell which merge request closed which task months later is the most concrete payoff of a Git workflow that people actually stick to.
Git doesn't store diffs between commits, it stores a snapshot of the whole project tree at each commit; files that didn't change just point back to the earlier version, which is why checking out an old commit is fast rather than replaying a chain of patches. That's also where rebase and merge diverge: merge takes two branch histories and joins them with a new commit that has two parents, while rebase replays your commits on top of another branch's tip, rewriting history in the process. Rebasing a branch other people have already pulled is asking for trouble, since their work now hangs off commits that no longer exist; I keep rebase to my own local branch, before anything's pushed, just to keep the log readable.
It's easy to assume Git resolves conflicts for you whenever it can, but that's only true at the line level. If two branches change different lines that are still logically connected, say one changes a method's signature and the other still calls it with the old one, Git merges them cleanly and the conflict only shows up later at compile time or, worse, at runtime. That's part of why code review isn't just checking whether the diff looks clean, it's checking how the two branches actually interact, and small, frequent commits make that a lot easier to catch than one large merge request.