Git
What is Git?
Git is a an Open Source distributed version control system that is available for free under the GNU General Public License version 2. The Git source code is hosted on GitHub, from where it can be downloaded or installed. Users can also utilize one of the binary installers to deploy Git on their systems. For example, they can use sudo to install Git on Linux, Homebrew on Mac or a downloadable executable file on Windows.
Git is used primarily by developers to manage their source code. Git records changes to files over time, while ensuring the integrity of those changes at each stage of processing. Users can revert to earlier versions and compare different versions at the file level. They can also branch and merge files to support independent development efforts and nonlinear workflows. And Git is not limited to source code. It can be used for database scripts, LaTeX documents, configuration files, content management data or other file types.
How does Git work?
Because Git is a distributed system, it can be used with or without a central repository, unlike centralized version control systems that require a server or hosting service to maintain the primary repository. With Git, each user maintains a local copy, or clone, of the repository, including its entire history. As a result, each clone serves as a backup, eliminating any single point of failure. Most operations that users perform are carried out locally, so they're not impacted by network latency issues. Users can also work out whether or not they're connected to the network.
After installing Git on their systems, users can work with their repositors by entering commands at a terminal or by using a graphical user interface, such as Sourcetree or GitHub Desktop. They can then set up their own projects or join another project. To join a project, users clone the repository from another location to their desktops, where they can modify the existing files or add new ones. The files in a user's local repository are always in one of three states:
- Modified. The user has modified one or more files but has not staged or committed those files. Changes occur in the working directory, which is the project folder that hosts the repository. Any files that are changed or added to this folder are considered to be in a modified state until they are staged.
- Staged. The user has marked the new or modified files as being ready to commit to the repository. Staged files are added to the staging area, which is a logical, intermediate area for reviewing the files before committing them. The staging area is more a designation than a physical location. Staged files are tracked in a special file named index.
- Committed. The user commits the staged files to the repository. Each commit operation represents a version of the repository that is assigned a unique checksum (Secure Hash Algorithm 1), which is used to reference the commit in subsequent operations.
After users commit their changes locally, they can push them out to a central repository or to other users' repositories. Users can also pull changes from a central repository or from other users' repositories. For example, a user might update several files, stage and commit the files, and then push them out to the team's central repository on GitHub. The other team members can then pull the updated files to their own systems to ensure they're working with the latest version. However, there is nothing in Git to prevent users from pushing and pulling changes directly from each other without relying on a central repository.
The history of Git
Linus Torvalds, creator of Linux, along with others in the Linux development community, built and released Git in 2005. They undertook the project because there was a lack of free and open source version control systems that could meet their requirements for Linux kernel development. They needed a system that could support a large-scale collaborative effort and provide the performance necessary to carry out various tasks, such as applying a patch in a few seconds rather than 30.
Git delivered that performance by providing a solution that did not rely on a centralized repository. Instead, it supported a distributed workflow, while safeguarding against file corruption. Git also offered a simple design that supported nonlinear development, making it possible to work on thousands of parallel branches.
Git, as a word, is an alteration of the word get, which itself was shortened from beget. The implicit reference is to illegitimate offspring, and the term is roughly synonymous with twit, dolt, moron or idiot. Within the open source community, the significance of the name choice varies. The readme file in the Git source code on GitHub states this about the name:
The name "git" was given by Linus Torvalds when he wrote the very first version. He described the tool as "the stupid content tracker" and the name as (depending on your mood):
- random three-letter combination that is pronounceable, and not actually used by any common UNIX command. The fact that it is a mispronunciation of "get" may or may not be relevant.
- stupid, contemptible and despicable. simple. Take your pick from the dictionary of slang.
- "global information tracker": you're in a good mood, and it actually works for you. Angels sing, and a light suddenly fills the room.
- "goddamn idiotic truckload of sh*t": when it breaks.
Learn all about the GitHub web-based version control and collaboration platform, see how to adopt the Git version control system for configuration as code and explore seven essential GitHub features for dev and project management.
