How it works
Git records a project as a series of commits: each one is a snapshot of every file, with a message, an author and a link to the commit before it. Branches let a feature be built alongside the main line of work, and merging brings the two back together. Every copy of a repository (a clone) holds the full history, so Git works offline and no single server is a point of failure.
Linus Torvalds wrote Git in 2005 to manage the Linux kernel, and it has since replaced older systems such as Subversion almost everywhere. It is a command-line program at heart; editors such as VS Code and apps such as GitHub Desktop add a visual layer. Git is not GitHub: Git is the tool, while GitHub, GitLab and Bitbucket are services that host Git repositories online.
Git pros and cons
Pros
- Full history of every change, with who made it and why
- Works offline, and every clone is a complete backup
- Cheap branches make parallel work and experiments safe
- Free, open source and supported by every developer tool
Cons
- Confusing at first: staging, rebasing and merge conflicts take practice
- Handles large binary files such as video poorly without Git LFS
- A committed secret stays in the history until it is scrubbed out
When to use Git
Pick it when
- Any code project, even a solo one
- Several people change the same files
- You want to roll back a bad change quickly
Skip it when
- Tracking big design or video files, where a cloud drive or Git LFS fits better
Git pricing
Git vs the alternatives
Related terms
More in Dev workflow and DevOps
Code and collaboration