DevOps
Git
Distributed version control that records every change as a commit in a graph, enabling branching, merging, code review and a full history you can bisect to find a bug. It is the backbone of team collaboration and CI/CD. Beyond commit and push, real fluency is branches, rebase versus merge, resolving conflicts and recovering work with reflog.
Purpose
Git records every change to a codebase as a commit in a graph, giving software a complete, navigable history. It is distributed — every clone holds the full history — and it is the substrate of modern collaboration: branches, pull requests, review and CI all sit on top of it.
When to Use It
Parallel work on branches merged safely back together; code review via pull requests; git bisect to binary-search history for the commit that introduced a bug; git blame to find why a line exists. Tags and branches also drive release and deployment automation.
Trade-offs
Its model — snapshots, refs, a staging area — is famously unintuitive at first, and history-rewriting commands (rebase, force-push) can destroy shared work when misused. Teams need conventions: branch strategy, commit message style, merge vs rebase.
Implementation
Beyond add/commit/push: branch freely and merge or rebase deliberately (rebase local work for a clean history; never rewrite shared branches). Write commit messages that explain why. When things go wrong, git reflog finds 'lost' commits — almost nothing is truly gone. Keep commits small and focused so review and revert stay easy.