Design goals of Git include speed, data integrity, and support for distributed, non-linear workflows — thousands of parallel branches running on different computers.

A repository is stored on each computer in a standard directory with additional, hidden files to provide version control capabilities.

Git was originally created by Linus Torvalds for version control during the development of the Linux kernel.

[14] The trademark "Git" is registered by the Software Freedom Conservancy, marking its official recognition and continued evolution in the open-source community.

For his design criterion, he specified that patching should take no more than three seconds, and added three more goals:[10] These criteria eliminated every version-control system in use at the time, so immediately after the 2.6.12-rc2 Linux kernel development release, Torvalds set out to write his own.

[28] Torvalds turned over maintenance on 26 July 2005 to Junio Hamano, a major contributor to the project.

Git's design is a synthesis of Torvalds's experience with Linux in maintaining a large distributed development project, along with his intimate knowledge of file-system performance gained from the same project and the urgent need to produce a working system in short order.

These influences led to the following implementation choices:[14] Another property of Git is that it snapshots directory trees of files.

Later revision-control systems maintained this notion of a file having an identity across multiple revisions of a project.

[50] Consequently, Git does not explicitly record file revision relationships at any level below the source-code tree.

Also, this can detect and handle merges involving renames.Git's primitives are not inherently a source-code management system.

Torvalds explains:[58] In many ways you can just see git as a filesystem—it's content-addressable, and it has a notion of versioning, but I really designed it coming at the problem from the viewpoint of a filesystem person (hey, kernels is what I do), and I actually have absolutely zero interest in creating a traditional SCM system.From this initial design approach, Git has developed the full set of features expected of a traditional SCM,[59] with features mostly being created as needed, then refined and extended over time.

Additionally, Git stores labels called refs (short for references) to indicate the locations of various commits.

Some types are: Git (the main implementation in C) is primarily developed on Linux, although it also supports most major operating systems, including the BSDs (DragonFly BSD, FreeBSD, NetBSD, and OpenBSD), Solaris, macOS, and Windows.

[72][73] The first Windows port of Git was primarily a Linux-emulation framework that hosts the Linux version.

[80] The libgit2 implementation of Git is an ANSI C software library with no other dependencies, which can be built on multiple platforms, including Windows, Linux, macOS, and BSD.

These GUIs provide visual representations of project history, including branches, commits, and file changes.

[97] GUI clients make Git easier to learn and use, improving workflow efficiency and reducing errors.

Version control systems used by responding developers: The UK IT jobs website itjobswatch.co.uk reports that as of late September 2016, 29.27% of UK permanent software development job openings have cited Git,[105] ahead of 12.17% for Microsoft Team Foundation Server,[106] 10.60% for Subversion,[107] 1.30% for Mercurial,[108] and 0.48% for Visual SourceSafe.

VFS for Git allows cloned repositories to use placeholders whose contents are downloaded only once a file is accessed.

Git does not provide access-control mechanisms, but was designed for operation with other tools that specialize in access control.

[121][122] Git version 2.6.1, released on 29 September 2015, contained a patch for a security vulnerability (CVE-2015-7545)[123] that allowed arbitrary code execution.

Recursive clones were also vulnerable since they allowed the controller of a repository to specify arbitrary URLs via the gitmodules file.