A system that records every change to the code, who made it and when, and lets many people work without overwriting each other.
Why it exists
When several people change the same code, saving over each other's work and losing history is a disaster waiting to happen, and emailing files around does not scale past one person. Git and version control exist to track every change with its author and reason, so work can be merged, reviewed, and rolled back, and nobody's edits are silently lost.
How it actually works
Five engineers editing the same files would be chaos without a system. Git records the full history of the code as a series of changes. Everyone works on their own copy, and Git merges their work together, flagging conflicts when two people changed the same thing.
Because every version is saved, you can see exactly what changed, when, and by whom, and return to any earlier point. It's the memory and the safety net of software work.
A senior PM walks you through it
A junior PM, stuck
Delivery fee showed 0 taka for a whole day, and when I asked when it broke, Rafi pasted git log and git blame output at me. It is a column of hashes and names and I cannot read which change did it or when. I need to answer "when did this break" in the incident notes and not just guess.
This is the code's own history, and it answers your exact question: who changed a line, when, and in which commit. git log lists the recent commits newest first; git blame pins each line of a file to the commit that last touched it. Here is Rafi's paste for checkout.ts. Read the blamed delivery-fee line, then look its hash up in the log.
Answering "when did it break" with a guess. The blamed line dates the exact change; "sometime this week" makes eng hunt from scratch, while "c4d81f9, Tuesday" opens the change in one click.
Reading the commit message as the truth. "Simplify checkout fee calculation" sounds safe; the same commit set the fee to 0. Trust the blamed line, not the sentence describing it.
Turning blame into blame. Naming Rafi in the incident notes as the culprit misses that a review approved this too; the point of history is finding the change fast, not pinning fault on a person.
Confusing the top of the log with the moment of breakage. The newest commit is not necessarily the one that broke this; blame points at the specific line, which here is several commits down.
Put in the incident notes: "Delivery fee reads 0 because checkout.ts line 15 was set to 0 in commit c4d81f9, by Rafi, last Tuesday 2026-03-03, in the fee-calculation refactor. Reverting that line restores the fee." You used git blame to turn "sometime this week" into an exact commit, author, and date.
Where a PM meets this
Git history is why "when did this break?" is answerable: teams can find the exact change that introduced a bug.
It underpins code review, releases, and rollback; the whole shipping process sits on top of it.
Hear it in a meeting
"Git blame shows that line changed in last Tuesday's release."