Katana VentraIP

Git

Git (/ɡɪt/)[8] is a distributed version control system[9] that tracks changes in any set of computer files, usually used for coordinating work among programmers who are collaboratively developing source code during software development.

For other uses, see Git (disambiguation).

Original author(s)

Junio Hamano and others[2]

7 April 2005 (2005-04-07)

2.44.0[3] Edit this on Wikidata / 23 February 2024

Primarily in C, with GUI and programming scripts written in Shell script, Perl, Tcl and Python[4][5]

English

Git's goals include speed, data integrity, and support for distributed, non-linear workflows (thousands of parallel branches running on different computers).[10][11][12] Git was originally authored by Linus Torvalds in 2005 for development of the Linux kernel, with other kernel developers contributing to its initial development.[13] It was prompted by the revocation of the free license of BitKeeper, the proprietary source-control management system used for Linux kernel development since 2002. Since 2005, Junio Hamano has been the core maintainer of Git. As with most other distributed version control systems, and unlike most client–server systems, every Git directory on every computer is a full-fledged repository with complete history and full version-tracking abilities, independent of network access or a central server.[14] Git is a free and open-source software shared under the GPL-2.0-only license.


Git's design benefits from Torvalds' experience with Linux and file-system performance, leading to features such as support for non-linear development, efficient handling of large projects, and cryptographic authentication of history. Its toolkit-based design allows for pluggable merge strategies and flexibility in managing version control tasks. Despite its comprehensive feature set, Git has faced security challenges, leading to updates and patches that address vulnerabilities. The trademark "Git" is registered by the Software Freedom Conservancy, marking its official recognition and continued evolution in the open-source community.


Git's adoption has grown rapidly, becoming the most popular distributed version control system, with nearly 95% of developers reporting it as their primary version control system as of 2022.[15] It is the most widely used source-code management tool among professional developers. There are offerings of Git repository services, including GitHub, SourceForge, Bitbucket and GitLab.[16][17][18][19][20]

Take the (CVS) as an example of what not to do; if in doubt, make the exact opposite decision.[12]

Concurrent Versions System

Support a distributed, -like workflow.[12]

BitKeeper

Include very strong safeguards against corruption, either accidental or malicious.

[11]

Hosting the Git server using the Git Binary.

[87]

a Git server configurable to support code reviews and provide access via ssh, an integrated Apache MINA or OpenSSH, or an integrated Jetty web server. Gerrit provides integration for LDAP, Active Directory, OpenID, OAuth, Kerberos/GSSAPI, X509 https client certificates. With Gerrit 3.0 all configurations will be stored as Git repositories, and no database is required to run. Gerrit has a pull-request feature implemented in its core but lacks a GUI for it.

Gerrit

a spin-off from Facebook. As Facebook primarily uses Mercurial, Git support is not as prominent.[88]

Phabricator

Community Edition (CE), supporting Git, Mercurial and Subversion with an AGPLv3 license.

RhodeCode

supporting both Git and Mercurial, developed in Python with GPL license.

Kallithea

External projects like gitolite, which provide scripts on top of Git software to provide fine-grained access control.

[89]

There are several other FLOSS solutions for self-hosting, including Gogs and Gitea, a fork of Gogs, both developed in Go language with MIT license.

[90]

a distributed file synchronization system based on Git

git-annex

a set of Git extensions to provide high-level repository operations for Vincent Driessen's branching model

git-flow

a repository organizer & tool for automating rebase/merge/pull/push operations

git-machete

The master branch is created by default with git init [105] and is often used as the branch that other changes are merged into.[106] Correspondingly, the default name of the upstream remote is origin[107] and so the name of the default remote branch is origin/master. The use of master as the default branch name is not universally true; repositories created in GitHub and GitLab initialize with a main branch instead of master,[108][109] though the default can be changed by the user.

[61]

Pushed commits should usually not be overwritten, but should rather be reverted (a commit is made on top which reverses the changes to an earlier commit). This prevents shared new commits based on shared commits from being invalid because the commit on which they are based does not exist in the remote. If the commits contain sensitive information, they should be removed, which involves a more complex procedure to rewrite history.

[110]

The git-flow workflow and naming conventions are often adopted to distinguish feature specific unstable histories (feature/*), unstable shared histories (develop), production ready histories (main), and emergency patches to released products (hotfix).

[111]

Pull requests are not a feature of git, but are commonly provided by git cloud services. A pull request is a request by one user to merge a branch of their repository fork into another repository sharing the same history (called the upstream remote).[113] The underlying function of a pull request is no different than that of an administrator of a repository pulling changes from another remote (the repository that is the source of the pull request). However, the pull request itself is a ticket managed by the hosting server which initiates scripts to perform these actions; it is not a feature of git SCM.

[112]

Git does not impose many restrictions on how it should be used, but some conventions are adopted in order to organize histories, especially those which require the cooperation of many contributors.

Security[edit]

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


On 17 December 2014, an exploit was found affecting the Windows and macOS versions of the Git client. An attacker could perform arbitrary code execution on a target computer with Git installed by creating a malicious Git tree (directory) named .git (a directory in Git repositories that stores all the data of the repository) in a different case (such as .GIT or .Git, needed because Git does not allow the all-lowercase version of .git to be created manually) with malicious files in the .git/hooks subdirectory (a folder with executable files that Git runs) on a repository that the attacker made or on a repository that the attacker can modify. If a Windows or Mac user pulls (downloads) a version of the repository with the malicious directory, then switches to that directory, the .git directory will be overwritten (due to the case-insensitive trait of the Windows and Mac filesystems) and the malicious executable files in .git/hooks may be run, which results in the attacker's commands being executed. An attacker could also modify the .git/config configuration file, which allows the attacker to create malicious Git aliases (aliases for Git commands or external commands) or modify extant aliases to execute malicious commands when run. The vulnerability was patched in version 2.2.1 of Git, released on 17 December 2014, and announced the next day.[115][116]


Git version 2.6.1, released on 29 September 2015, contained a patch for a security vulnerability (CVE-2015-7545)[117] that allowed arbitrary code execution.[118] The vulnerability was exploitable if an attacker could convince a victim to clone a specific URL, as the arbitrary commands were embedded in the URL itself.[119] An attacker could use the exploit via a man-in-the-middle attack if the connection was unencrypted,[119] as they could redirect the user to a URL of their choice. Recursive clones were also vulnerable since they allowed the controller of a repository to specify arbitrary URLs via the gitmodules file.[119]


Git uses SHA-1 hashes internally. Linus Torvalds has responded that the hash was mostly to guard against accidental corruption, and the security a cryptographically secure hash gives was just an accidental side effect, with the main security being signing elsewhere.[120][121] Since a demonstration of the SHAttered attack against git in 2017, git was modified to use a SHA-1 variant resistant to this attack. A plan for hash function transition is being written since February 2020.[122]

Trademark[edit]

"Git" is a registered word trademark of Software Freedom Conservancy under US500000085961336 since 2015-02-03.

Comparison of source-code-hosting facilities

Comparison of version-control software

List of version-control software

Edit this at Wikidata

Official website

at Open Hub

Git