Git (software)

Git ( [ ɡɪt ], Engl. Dumbass ) is a free software for distributed version control of files that was originally developed for the source control of the Linux kernel.

• 4.1 Name

Properties

Git is a distributed version control system, which in some characteristics different from typical version control systems:

Non-linear development

Both the creation of new development branches ( branching ) and the fusion of two or more branches ( merging ) are an integral part of working with Git, built into the Git tools. Git contains programs that help the non - linear story of a project can be easily visualized and with which one can navigate in this story. Branches in Git (as opposed to other SCMs ) implemented very performant: A Branch is only a reference, ref short, a text file with a commit ID is stored in a repository in the directory .git / refs / heads (for B. .git / refs / heads / master is always present for the master branch ) and refers to a specific commit. About the Parental commits, so Elterncommits, can the Branch structure reconstructed. These properties still can be very large and efficient development structures like Git itself or the Linux kernel realize in which each feature and each developer have a branch or a separate repository from which the maintainer then commits the Merge or Cherry -pick ( benefit of individual commits ) into the main branch of the project ( master) can take over.

No central server

Each user has a local copy of the entire repository, including the version history (history). Thus, most actions can be performed locally without network access. No distinction is made between local development branches and twigs development of remote repositories. Although there is no technical difference between different repositories ( except the one between normal and bare repositories on servers that do not involve working tree, so the "real" files exist), the copy referenced by a project home from valid is often referred to as the "official repository ", in which the revisions to the developer to be transferred. There are special remote -tracking branches, which are references (see Non-linear development ) that point to the state of another repository.

Data transfer between repositories

Data can be transmitted in addition to transmitting the file system level ( file :/ / ) with a variety of network protocols between repositories. Git has its own very efficient protocol that uses TCP port 9418 ( git :/ / ), but can only be used for Fetchen and clones, so the reading of a repository. Likewise, the transfer via SSH ( ssh :/ /, the most commonly used protocol for write operations ), HTTP (http://), HTTPS (https:// ) or ( less efficient) through FTP ( ftp:// ) or rsync ( rsync :/ / ) take place. The transmission in the "official repository " of a project often takes the form of patches, which are sent via email to the developer or a development mailing list. Alternatively, a review system Gerrit be used.

Cryptographic security of the project history

The story of a project is stored so that the hash of any revision ( commit) based on the full story, which has led to this revision. Thus, it is not possible, the version history to manipulate later, without changing the hash of the revision. Individual reviews may be additionally marked ( tagging) and optionally digitally signed with GPG (signed tag ), for example, the state at the time of the release of a new version of the software to identify.

Memory system and file versioning

Unlike CVS, where each file has its own revision number, Git stores a commit at the entire file system from. The store itself is performed by a reference to the project root is stored as a tree object in the commit object that contains references to turn blobs ( binary large objects, the pure contents of files without identification ) and other trees (directories). A tree object references (such as a directory inode ) with its entries on SHA1 checksums, the more trees and identify blobs, similar to inode numbers in file systems. If a file is not changed in a commit, also not the checksum changes, and they need not be stored again. The properties are located in the project under .git / objects. About GIT " means board " can be any arbitrary commit to the associated hash identify ( the checksum / hash) clearly read out separately, merge or even use it as a branching - comparable with the revision numbers in other systems.

Clean the repository

The data deleted and redeemed actions and development branches remain available ( and can be recovered ), until they are explicitly deleted.

Interoperability

There are utilities that make the interoperability between Git and other version control systems. Such assistance programs exist, among other things for GNU arch ( git- archimport ), CVS ( git- cvsexportcommit, git- cvsimport and git- cvsserver ), Darcs ( darcs - fastconvert, darcs2git and others), Quilt ( git -quilt import) and Subversion ( git -svn ).

Web Interface

With gitweb there is a web interface written in Perl. The Team Foundation Server from Microsoft features a Git - binding ( Git -tf ).

Use

Supported Operating Systems

Git runs on almost all modern Unix-like systems such as Linux, Solaris, Mac OS X, FreeBSD, DragonFly BSD, NetBSD, OpenBSD, AIX, IRIX and haiku. On Microsoft Windows, it can be used natively with the client from GitHub, or by using the Cygwin environment, with msysgit or TortoiseGit shell extension ( like TortoiseSVN ).

History

Through a license amendment to the previously used proprietary BitKeeper system, the Linux kernel developers could no longer use this free, thus leaving many developers access denied. Therefore, Linus Torvalds began in April 2005 with the development of a new source code management software and presented a few days after the announcement of a first version.

Torvalds wanted a distributed system that could be used as BitKeeper and fulfilled the following requirements:

An already existing project called Monotone met the first two requirements, the third criterion, however, was met by any existing system.

Torvalds decided against it, Monotone adapt to its requirements, and instead began to develop its own system. One of the main reasons for this step was the way of working is optimized for Monotone by Torvalds view. Torvalds argued that individual revisions by another developer in their own development branch to import would lead to cherry-picking and " messy " repositories. If, however, always whole branches are imported, developers will be forced to clean up. These are " disposable goods" necessary.

"This is my only real gripe with conceptual ' monotonous '. I like the model, But They make it much harder than it Should Be to have throw -away trees due to the fact thatthey SEEM to be working on the assumption of 'one database per developer ' rather than 'one database per tree '. You do not have to follow model did, but It Seems to be what the setup is geared for, and together With Their ' branches ' ​​It Means did I think a monotone database Easily gets very cruddy. The other problem with monotone performance is just right now, but that's hopefully not _too_ fundamental. "

Gits design uses some ideas from Monotone, and BitKeeper, but no source code for it. It is expressly intended to be a stand-alone version control system.

Current maintainer of Git is Junio ​​Hamano.

Name

The name " Git" in British slang means " dumbass ". Linus Torvalds explained his unusual choice of name with a joke, and the fact that the word was still largely unused practicable and in the software world:

" I'm an egotistical bastard, and I name all my projects after myself. First 'Linux', now 'git '. "

"The joke ' I name all my projects for myself, first Linux, then git ' was just too good to pass up But it is so short, easy-to -say, and type on a standard keyboard. And reasonably unique and not any standard command, Which is unusual. "