Git is a version control system for tracking changes in computer files and harmonizing work on those files among many people. It is usually used for source code management in software development. But it can also be used to keep track of changes in any set of files. As a dispensed revision control system it is directed at speed, data integrity, and support for distributed, non-linear workflows. Git was created by Linus Torvalds in 2005 for the development of the Linux kernel, with other kernel developers contributing to its starting development. Its current maintainer since 2005 is Junio Hamano.
As with most other popular version control systems, and unlike most customers’ server systems. Every Git directory on every computer is a full-fledged repository with complete history. And full version tracking responsibilities, independent network access or a central server.
History of GIT
In April 2005, Git started development, after when so many developers of the Linux kernel given up access on Bit Keeper. A relating source control management (SCM) system that they had formerly used to maintain the Git project. The copyright holder of BitKeeper, Larry McVoy, withdrawn the free use of the product after claiming that Andrew Tridgell had reverse-engineered the BitKeeper protocols. (The same incident would also prompt the creation of another version control system, Mercurial.)
Why Git was Created
Linus Torvalds wanted a issued system that he could use like BitKeeper. But the available free systems could not meet his needs, especially when it comes to performance. Torvalds discovered an example of a source-control management system that needs 30 seconds to apply a patch and update all associated metadata. And known that this would not scale to the needs of Linux kernel development. Where syncing with fellow maintainers could demand 250 such actions at once. For his design standard, he specified that patching should take nothing more than three seconds, and he added three more points and these are:
- Take Concurrent Versions System (CVS)
- Support a distributed, BitKeeper-like workflow
- Include very strong safeguards against corruption, either accidental or malicious
These criteria removed every then-extant version control system except Monotone. Performance deliberations excluded it, too. So immediately after the 2.6.12-rc2 Linux kernel development was release, Torvalds then set out to write his own system.
Torvalds joked about the name git (which means annoying person in British English slang). I’m an egotistical bastard, and I name all my projects after myself. The man page describes Git as “the stupid content tracker”.
Git Pack File and it Snapshots Directory Trees of Files
Git stores each newly created object as a different file. Although specially compressed, this takes a great deal of space and it is incompetent. This is resolved by the use of packs that store a large number of objects in one file (or network byte stream) called pack file, delta-flatten among themselves. Packs are flatten using the heuristic that files with the same name are probably similar. But do not depend on it for quality.
A corresponding index file is made for each pack file, telling the offset of each object in the pack file. Newly added histories are stored alone, and periodic re-packaging is needed to maintain space regulation. The process of packing the repository can be computationally costly. By allowing objects to live in the repository in a loose, but quickly caused format. Git allows the costly pack operation to be postponed until later, when time matters less, like the end of a work day. Git does regular repacking automatically but manual repacking is also possible only with the git gc command. For data honesty, both pack file and its index have SHA-1 checksum inbuilt, and also the file name of pack file contains a SHA-1 checksum. To check integrity, you can check the git fsck command.
Git Snapshots Directory Trees of Files
Another feature of Git is that it acquire a history of changes affecting a given file. The earliest systems for tracking versions of Source Code Control System (SCCS) and Revision Control System (RCS), worked on individual files and highlighted the space savings to be gained from interleaved deltas (SCCS) or delta encoding (RCS) the most common versions. Later revision control systems maintained this idea of a file having an identity across multiple revisions of a project. However, Torvalds declined the concept. And for this reason, Git does not record file revision relationships explicitly at any level below the source code tree.
How Git can Acquire a History of Changes Affecting a Given File
It is slightly more costly to observe the change history of one file than the whole project. To acquire a history of changes affecting a given file, Git must walk the global history. And then decide whether each change modified that file. This method of testing history does, however, let Git produce with equal order a single history showing the changes to a random set of files. For example, a sub directory of the source tree plus an associated global header file is a very common case.
Renames are handled completely rather than explicitly. A common complaint with CVS is that it makes use of the name of a file to identify its revision history. So moving or renaming a file is not possible without either interrupting its history. Or renaming the history and thereby making the history inexact. Most post-CVS revision control systems solve this by giving a file an excellent long-lived name (comparable to an anode number) that survives renaming. Git does not record such an identifier, and this is claimed as an advantage. Source code files are sometimes split or renamed, merged, and recording this as a simple rename would freeze an inaccurate description of what happened in the (immutable) history.
How Git addresses the issue by detecting renames
Git addresses the issue by detecting renames while browsing the history of snapshots rather than recording it when making the snapshot. However, when there is no like-named file in revision N−1. It searches for a file that existed only in revision N−1 and is very similar to the new file.) However, it does require more CPU-intensive work every time history is reviewed, and several options to adjust the heuristics. This mechanism does not always work; sometimes a file that is renamed with changes in the same commit is read as a deletion of the old file and the creation of a new file. Developers can work around these restrictions by committing the rename and changes separately.
As Git is a dispersed version control system, it can be used as a server out of the box. Commited server software helps, among other features, to add access control, showcase the contents of a Git repository via the web, and aids managing multiple repositories, controls file store and shell access: A Git repository can be cloned to a shared file system, and obtained by other people. It can also be accessed via shell remote just by having the Git software installed and allowing a user to log in