git

Git is a distributed revision control system designed to track changes across a codebase with speed and a rich command set, offering both simple day-to-day commands and full access to lower-level internals for people who need them. It's the version control layer under most modern software development, used by solo developers and large open source projects alike, and it runs on essentially any platform.

Key features

• Distributed model: every clone contains the full history of the project, so most operations (commits, diffs, log browsing) happen locally without a network round trip.
• Rich command set: high-level porcelain commands for everyday work sit on top of a set of plumbing commands that expose the internals for scripting and tooling.
• Branching and merging: lightweight, cheap branches are core to the workflow, supporting parallel lines of development that merge back together.
• Wide protocol and tooling support: works over SSH, HTTPS, and local transports, and integrates with a large ecosystem of hosting platforms, GUIs, and editors.
• Extensive documentation: tutorials, a full reference for every subcommand, and a dedicated migration guide for teams coming from CVS.
• Active mailing list development: the project is developed and discussed on a public mailing list, where patches are submitted and reviewed.
• Localization: contributors can help translate Git's error, usage, and informational messages, with instructions maintained in the repository for anyone who wants to help.

Ideal use cases

Git is the default choice for tracking source code on nearly any project, from a single-file script to a large distributed codebase with thousands of contributors. It's especially suited to workflows where people need to work offline, branch experimentally, or collaborate without a single central server being a hard requirement, since any clone can act as a full backup of history.

It's less of a natural fit for versioning very large binary assets (game art, video, datasets) without extensions like Git LFS, since Git's history model wasn't built around large opaque files. If your team needs simple centralized locking for binary files, or you're versioning huge assets by default, look at Git LFS or a purpose-built asset versioning tool alongside it.

Installation

Git is typically installed through your operating system's package manager rather than built from this source repository, though the source is available here for anyone who wants to build it directly. The repository's INSTALL file has full build instructions; standard build tools plus common libraries (zlib, OpenSSL, expat, and others depending on features) are needed to compile from source.

To read the tutorial and command documentation once Git is installed:

man gittutorial
git help tutorial

For everyday command reference:

man git-<commandname>
git help <commandname>

If you're moving a team over from CVS, there's a dedicated guide:

man gitcvs-migration
git help cvs-migration

Bug reports, patches, and discussion happen on the public mailing list at [email protected], with contribution guidelines documented in Documentation/SubmittingPatches and Documentation/CodingGuidelines. Translators working on error messages and UI strings can find instructions in po/README.md, where a po file is described as a Portable Object file holding the translated strings.

To subscribe to the mailing list, send an email to [email protected]; archives of past discussion are available through lore.kernel.org, marc.info, and other archival sites. The maintainer periodically posts "What's cooking" status reports to the list, summarizing the state of various development topics in flight, which is a useful way to see the project's current direction and outstanding work without reading every patch thread. Security-relevant issues should go to the separate Git Security mailing list rather than the general list, so they can be handled privately before any public disclosure.