Install Git on Ubuntu

Git is an open-source distributed version control system that is available for everyone at zero cost. It is designed to handle minor to major projects with speed and efficiency. It is developed to co-ordinate the work among programmers. The version control allows you to track and work together with your team members at the same workspace.

Git is the most common source code management (SCM) and covers more users than earlier VCS systems like SVN. Let's understand how to install Git on your Ubuntu server.

Introduction to Git

Git focuses on data integrity, speed, and non-linear, distributed workflow support. Originally, git was started in 2005 by Linus Torvalds for the Linux kernel development, with other developers of the kernel contributing to its starting development. Junio Hamano has been the main maintainer since 2005.

Unlike almost every client-server system, and with almost every distributed version control system, all Git directories on all computers are a completely developed repository with full version-tracking and history abilities, free from a central server or network access. Git is an open-source and free software distributed upon the GPL-2.0-only license.

Brief History of Git

In April 2005, Git development started after several kernel developers gave up using BitKeeper, an SCM (source control management) system they had been utilizing to manage the project.

Linus Torvalds wished for a distributed system that could be used like BitKeeper, but the available open-source systems don't meet his requirements. Torvalds specified an instance of a source-control management system requiring thirty seconds to use a patch and update every related metadata and esteemed that it wouldn't scale to the requirements of the development of the Linux kernel, in which synchronizing with associate maintainers could need 250 such operations at once. He cited that patching shouldn't take 3+ seconds with his design principle and included three more purposes:

• Add robust safeguards opposed to corruption, either malicious or accidental.
• Support a BitKeeper-like, distributed workflow.
• Take CVS (Concurrent Versions System) as an instance of what not to do; make the same opposite decision if not sure.

Design of Git

The design of Git was inspired by Monotone and BitKeeper. Originally Git was developed as a low-level engine for the version control system, where others can specify front ends like StGIT or Cogito.

Characteristics

The design of Git is the synthesis of the experience of Torvalds with Linux in managing a bigger distributed development project with his file-system performance knowledge gained from a similar project and the requirement to generate an active system. These conditions led to the below implementation options:

• Non-linear development support: Git supports fast merging and branching and contains special tools for navigating and visualizing a non-linear development history. A basic thought is that modification will be combined more frequently than it's written in Git because it's passed across several reviewers. In Git, the branches are lightweight, and a branch is just a reference to a single commit. The structure of a full branch can be made using its parental commits.
• Distributed development: Like Monotone, Bazaar, Mercurial, BitKeeper, and Darcs, Git provides all developers a copy of the complete development history, and modifications are copied from such repositories to others.
• Compatibility with older protocols and systems: Repositories can be released by a Git protocol, FTP, HTTP, or HTTPS on either a Secure Shell or plain socket.
• Efficient handling of bigger projects: Torvalds has defined Git as being very scalable and fast, and performance tests implemented by Mozilla represented that it's an order of magnitude rapid differentiating bigger repositories than GNU Bazaar and Mercurial.
• History cryptographic authentication: The history of Git is stored in a form that the ID of a specific version relies on the full development history causing that commit.
• Toolkit-based structure: Git was developed as a collection of programs specified in C and many shell scripts that offer wrappers across these programs. However, most of these scripts have been since re-specified in C for portability and speed.
• Pluggable strategies: Git contains a well-defined structure of a lacking merge, and it contains two or more algorithms to complete it as an element of its toolkit structure.

Data structures

The primitives of Git are not a source-code management system inherently. Git has integrated the full set of aspects expected of a classic SCM, with aspects mostly being made as required, then refined and increased over time from this starting design approach.

Git includes two different data structures. The first data structure is a mutable index (also known as cache or stage) that caches details about the active directory and the upcoming revision to be devoted. The second data structure is an append-only immutable object database.

The immutable database includes five object types:

• Blob
• Tree
• Commit
• Tag
• Packfile

Blob: A blob is short for a binary large object and a file's content. Blobs have not included proper timestamps, file names, or other metadata. All blobs are a file version in git, it holds the data of the file.

Tree: A tree object is the same as a directory. It includes a file name list, each with a few type bits and a tree object or blob reference that is the content of that file, directory, or symbolic link. These objects are the source tree snapshots.

Commit: A commit object connects tree objects with history. It includes a tree object name, a log message, a timestamp, and none or more parent commit object names.

Tag: A tab object can be described as a container that includes a reference to other objects and can keep added meta-data associated with the other objects. It is most commonly used for storing a digital signature of any commit object related to a specific data release being followed by Git.

Packfile: A packfile object gathers several other objects in a zlib-compressed group for ease of transport and compactness on network protocols.

Git additionally stores labels known as refs (or references) to represent the location of several commits. They are:

• Heads (branches)
• HEAD
• Tags

All objects are recognized by their content's SHA-1 hash. Git figures out the hash and applies its value to the name of the object. The object is set into a directory which is the same as its hash's initial two characters. The remaining hash is utilized as a file name for the object.

Besides, Git stores all file revisions as a special blob. The relationships between these blobs can be detected by examining the commit and tree objects. Freshly added objects are reserved in their unity with the help of zlib compression. It can quickly consume a large disk space amount, so objects can be merged into packs, which apply delta compression for saving space, reserving blobs as their modifications associative to other blobs.

• Heads (branches): Heads are named references that are automatically advanced to the new commit as soon as a commit is created on top of them.
• HEAD: It is a stored head that will be analyzed against the active tree to build a commit.
• Tags: These are the same as the branch references but set to a specific commit. Tags are used for labeling essential points in history.

References

In the Git database, references are all objects that aren't referred to probably cleaned up automatically or with a garbage collection command. An object might be referred to by an explicit reference or another object. Git knows distinct reference types. The commands to make, move, or remove references differ. The git show-ref command can list every reference. A few types include:

• heads: locally refers to the object,
• remotes: refers to any object which is available inside a remote repository,
• meta: for example, a configuration within a bare repository; the namespace, i.e., refs/meta/config was retrospectively announced, utilized by Gerrit.
• stash: refers to any object not committed yet.

Implementations of Git

Primarily, Git is developed in Linux. Also, it supports the most dominant operating systems, such as BSDs (FreeBSD, OpenBSD, NetBSD, and DragonFly BSD), Windows, macOS, and Solaris.

The first Git Windows port was mainly a Linux-emulation structure that hosts the version of Linux. Under Windows, installing Git makes the same named directory of program files having the Mingw-e64 port of the MSYS2, Perl 5, GNU Compiler Collection, and many other Windows emulations or ports of Linux libraries and utilities. Native Windows Git builds are currently distributed as 64- and 32-bit installers. Currently, the official website of Git manages a Git build for Windows, still utilizing an MSYS2 environment.

• Git's JGit Implementation is a pure library of Java software, developed to be installed in the Java applications. JGit is utilized in the code review tool, i.e., Gerrit, and in EGit, which is the Git client for Eclipse IDE.
• Go-Git is the Git open-source implementation purely written in Go.
• Currently, it is used to back up projects as an interface of SQL for Git code repositories and offering Git encryption.
• For the 3.5, 3.4, and 2.7 versions of Python, the Git Dulwich implementation is a pure component of Python software.
• Git libgit2 implementation is a library of ANSI C software without other dependencies, built on two or more platforms, such as BSD, macOS, Linux, and Windows. It contains bindings for several programming languages, such as Haskell, Python, and Ruby.
• JS-Git is an implementation of JavaScript of a Git subset.

Git Server

Git could be utilized as a server because it is a distributed system for version control. It's exported with the git daemon built-in command which begins a basic TCP server active on the GIT protocol. Committed Git HTTP server support by including access control, showing Git repository contents through the web interfaces, and handling two or more repositories.

Already available Git repositories can be duplicated and distributed to be utilized as a centralized repository by others. Also, it can be accessed by a remote shell only by installing the Git software and letting a user login. Typically, Git servers listen on the 9418 port of TCP.

Open source

• Managing the Git server with the help of the Git Binary.
• Phabricator, which is a spin-off through Facebook. The support of Git isn't as prominent because Facebook mainly uses Mercurial.
• Gerrit, which is a Git server configurable to help code reviews and give access through ssh, an improved OpenSSH or Apache MINA, or an improved Jetty web server. Gerrit offers integration for X509, Kerberos/GSSAPI, OAuth, OpenID, Active Directory, and LDAP https client certificates.

Every configuration will be reserved as Git repositories with the 3.0 version of Gerrit, and the database isn't needed to execute. Gerrit includes a pull-request aspect running in its core, although absence of a GUI for it.

• Kallithea supports both Mercurial and Git, integrated in Python using a GPL license.
• RhodeCode CE (Community Edition), supports Git, Subversion and Mercurial using an AGPLv3 license.
• Many other FLOSS solutions are available for self-hosting, such as Gitea and Gogs, both designed in the Go language using an MIT license.
• External projects, such as gitolite, give scripts over Git software to facilitate elegant access control.

Git server as a service

Several Git repository offerings are available as a service. Some most famous are GitLab, Bitbucket, SourceForge, and GitHub.

Adoption of Git

As of May 2014, the Eclipse Foundation stated in its survey that Git is the most widely utilized tool for source code management, along with 42.9% of professional application developers stating that they utilize Git as their main source-control system. Black Duck Open Hub open-source directory reports the same uptake between open-source projects.

On the other hand, Stack Overflow has added version control in their survey in 2015, 2017, 2018, and 2022. In these surveys, Git was the favorite of answering developers, stating as high as 93.9% in 2022.

Extensions

Several Git extensions, such as Git LFS, are available, which was initiated as a Git extension in the GitHub community, and it is now extensively utilized by other repositories. Usually, extensions are developed and managed independently by several people, although an extensively utilized extension can be combined with Git in the future at some point.

Some other open-source extensions of Git include:

• git-flow is a group of Git extensions to offer high-level repository tasks for Vincent Driessen's branching model.
• git-annex is a distributed system of file synchronization which is Git-based.
• git-machete is a repository organizer and tool to automate rebase/merge/push/pull tasks.

Microsoft developed VFS (Virtual File System) for Git (formerly GVFS or Git Virtual File System) extension to manage the source code tree size of Windows as part of their migration in 2017 from Perforce. Git Virtual File System permits duplicated repositories to utilize a proxy whose contents can be downloaded when a file is used.

Security of Git

Git doesn't offer access control techniques but was developed for tasks with other tools that train in access control.

An exploit was detected affecting the macOS and Windows Git client versions on 17 December 2014. An attacker could implement arbitrary code execution on the target system along with Git installed by establishing a mischievous Git tree called .git in a distinct case with some malicious files inside the subdirectory, i.e., .git/hooks, on the repository that was created by the attacker or on the repository that was modified by the attacker.

The 2.6.1 version of Git, published on 29 September 2015, included a security vulnerability patch that permitted arbitrary code execution. This vulnerability was unsuspicious if the attacker could satisfy a victim to duplicate a named URL because the arbitrary commands were set in that URL itself. Also, recursive clones were vulnerable because they permitted the repository controller to define arbitrary URLs through the gitmodules file.

Git Installation

I have done this installation on Ubuntu 16.04 LTS. But the given commands should also work with the other versions.

Below are the steps to install the Git on Ubuntu server:

Step1: Start the General OS and Package update

First of all, we should start the general OS and package updates. To do so, run the below command:

Now we have started the general OS and package updates. After this, we will run the general updates on the server so that we can get started with installing Git. To do so, run the following commands:

Step2: Install Git

To install Git, run the below command:

The above command will install the Git on your system, but it may ask you to confirm the download and installation.

Step3: Confirm Git the installation

To confirm the installation, press 'y' key on the editor. Now, Git is installed and ready to use.

When the central installation done, first check to ensure the executable file is set up and accessible. The best way to do this is the git version command. It will be run as:

Output:

git version 2.24.0

Step4: Configure the Git for the First use

Now you can start using Git on your system. You can explore many features of the version control system. To go with Git, you have to configure the initial user access process. It can be done with the git config command.

Suppose I want to register a user whose user name is "javaTpoint" and email address is "<a href="/cdn-cgi/l/email-protection" class="__cf_email__" data-cfemail="377d5641564347585e5943774f4e4d">[email&#160;protected]</a>", then it will be done as follows:

To register a username, run the below command:

To register an email address for the given author, run the below command:

Now, you have successfully registered a user for the version control system.

It's important to understand that the git config tool works on a user according to the user. For example, if we have a user "john" registered on Git. Then there can be another user "Mike" on the same machine registered on Git. To do this, Mike must run the same command from his user account. The commits made by both the users will be done under their details in Git.

To go in-depth with the git config command, visit Here.