Install git with Homebrew

Project links

• Homepage
• Repository

Commands and aliases

• git
• git-cvsserver
• git-receive-pack
• git-shell
• git-upload-archive
• git-upload-pack
• scalar

Project history

Git began in 2005 after the Linux kernel community lost access to the proprietary BitKeeper workflow it had been using. Linus Torvalds wrote the original implementation to support Linux-scale development, emphasizing speed, integrity, distributed operation, and cheap branching.

The design departed from centralized version-control systems by making every clone a full repository with local history and branch operations. That choice made offline work, fork-based development, and patch exchange natural rather than exceptional.

After its Linux origin, Git evolved into a broadly portable tool with a large manual set, porcelain commands for everyday work, and plumbing commands for scripts and higher-level tools. The kernel.org repository remains the canonical upstream source location, while git-scm.com provides the public documentation hub.

Adoption history

Git's adoption accelerated with distributed open source development and the rise of Git hosting services such as GitHub, GitLab, and related forges. The official Git site characterizes the core project as a command-line tool surrounded by hosting services, graphical clients, editor integrations, and other command-line helpers.

By the early 2010s, Git had moved from a Linux-kernel tool into the common denominator for open source collaboration, commercial software teams, CI systems, package ecosystems, and code review platforms. Its repository model also became the foundation for workflows outside source code, including documentation and data-adjacent projects.

How it is used

Practitioners use Git to initialize or clone repositories, stage and commit changes, branch and merge work, inspect history, exchange commits through remotes, and recover earlier states. Its local-first model makes common commands fast because most history and metadata are on the developer's machine.

Teams layer policy on top of Git through protected branches, pull requests, signed commits, release tags, submodules, worktrees, hooks, and CI triggers. The same executable serves both interactive daily work and automation in release scripts, package recipes, deployment systems, and source archives.

Why package nerds care

Git is one of the central dependencies of package-manager culture. Formulae, ports, distro source packages, language registries, and build systems routinely fetch from Git repositories, pin commits or tags, generate source archives, and use Git metadata to derive versions.

Its significance also comes from its stability as an interchange format. Even tools that wrap Git, avoid the Git CLI, or store files elsewhere usually need to speak in Git concepts: commits, refs, remotes, branches, tags, diffs, and patches.

Timeline

• 2005: Git was created for Linux kernel development after the BitKeeper transition.
• 2005: Early Git releases established the distributed repository model.
• 2010s: Hosted Git forges and pull-request workflows made Git the dominant version-control system for many developer communities.
• 2020s: Git remained a base dependency for package managers, CI, source archives, and developer tools.

Related projects

• Linux kernel development drove Git's original requirements.
• GitHub, GitLab, Gitea, Forgejo, and other forges build hosted collaboration around Git repositories.
• Git LFS and Git Xet extend Git workflows for large-file storage.
• Scalar, included with Git packages, targets very large repository workflows.

Sources

• https://git-scm.com/about
• https://git-scm.com/book/en/v2/Getting-Started-A-Short-History-of-Git
• https://git-scm.com/docs
• https://git-scm.com/docs/git
• https://git.kernel.org/pub/scm/git/git.git