Originally published on lavkesh.com

When Linus Torvalds wrote Git in 2005 he wasn’t chasing a buzzword; he needed a system that could handle thousands of kernel contributors pushing changes every day.

Git gives each developer a full copy of the repository, history and all. That means you can commit, browse logs or create a branch without ever touching a central server.

Branching in Git is cheap enough that creating or deleting a branch takes milliseconds. Teams can spin up isolated workspaces for features or bugs, merge them back, and repeat the process dozens of times a day.

For example, at my previous company, we used Git to manage a large monorepo with over 10 million lines of code. We had over 50 developers working on the project, and they would create and merge branches multiple times a day. We used tools like GitFlow to manage the workflow, and it worked remarkably well. The key was to keep the branch lifetime short, usually less than a day, to avoid merge conflicts.

Beyond the familiar add, commit and push, Git ships with rebasing, cherry‑picking, interactive staging and tools that let you rewrite history when a mistake slips through.

I've seen cases where a developer accidentally committed a large binary file, causing the repository size to balloon. In such cases, using Git's filter-branch command can help remove the offending file from the history. However, this comes with a trade-off - it rewrites the commit hashes, which can cause problems for other developers who have already pulled the changes. So, it's essential to weigh the benefits of a clean history against the potential disruption to the team.

Every object Git stores is identified by a SHA‑1 hash. If any file or commit is altered the hash changes, so corruption is detected immediately and the distributed copies act as backups.

In practice, this means that even if a developer's local repository becomes corrupted, they can easily recover by cloning the repository again from a remote server. I've seen this happen in production, where a disk failure caused a developer's local repository to become corrupted. We were able to recover the changes by using Git's reflog command to find the last good commit, and then reapplying the changes on top of that.

Because each developer works on their own clone, code reviews become a regular part of the flow rather than a last‑minute scramble. Pull requests simply surface the differences you already have locally.

The same commands that feel natural on a single‑file script also scale to monorepos with millions of lines. Whether you’re building a hobby project or a multinational codebase, Git stays out of the way.

Hosting services such as GitHub, GitLab and Bitbucket built entire ecosystems around Git, providing webhooks, CI pipelines and marketplace extensions that extend the core workflow.

Starting a new repo is as simple as running git init in an empty folder. To join an existing project you run git clone URL, then git branch new‑feature followed by git checkout new‑feature. Stage changes with git add, record them with git commit -m "message", and share them with git push origin new‑feature. The model respects how developers actually work, not how managers think they should.