Git

git

Git's logomark
Release Status	Maintained
Last Release	2.50.0 (2025-06-16)
Language(s)	C
Developer(s)	Linus Torvalds and Contributors
Website	https://git-scm.com

Git is a powerful, efficient, flexible free and open-source distributed version control system (VCS) designed to track changes in files, typically used for source code management in collaborative software development between multiple developers, by maintaining a full history of changes locally on each user's computer, enabling work without constant network access.

Git is widely regarded as the de facto standard version control system in the industry, supported by different online repository hosting providers such as GitHub, GitLab, Gitea, and Codeberg.

History

Git was created in April 2005 by Linus Torvalds after the Linux kernel development team lost free access to BitKeeper, a proprietary version control system they had used since 2002. The BitKeeper license was revoked due to disputes involving reverse engineering of its protocols. Torvalds needed a distributed version control system that was fast, efficient, and could handle the large-scale, non-linear development of the Linux kernel, with patch application times under three seconds, unlike existing systems that were too slow or centralized.

Torvalds started developing Git on April 3, 2005, announced it on April 6, and by April 7, Git was self-hosting its own repository. The first merge of multiple branches occurred on April 18, and by April 29, Git was capable of applying patches at a rate of 6.7 patches per second to the Linux kernel source. Git managed the Linux kernel 2.6.12 release in June 2005.

On July 26, 2005, Torvalds handed over maintenance of Git to Junio Hamano, who became the lead maintainer and released Git version 1.0 in December 2005. Git's early design emphasized a distributed workflow similar to BitKeeper's but with strong safeguards against corruption and a focus on speed and simplicity. Over time, Git evolved with the addition of graphical user interfaces and integration with platforms like GitHub, which launched in 2008 and transformed collaborative software development.

Usage

In a repository (repo), Git manages different versions (revisions) of files. There are 3 kinds of revision:

• A commit is a single immutable moment in the repository. When the user chooses to create a “backup” of their code-base, they add and commit their changes. The git commit command does exactly the latter, as explained later in this section.
• A tag marks a commit, giving it a custom label. This is done using the git tag command.
• A branch marks the latest commit in a consecutive list of commits made to a repo.

A repository when initialised with git init comes with no commits. The “first backup” (initial commit) marks the start of the commit history. It is special since it is the only permitted commit in a repo that does not come with a parent, and other commits must have at least 1 parent commit.

The default branch for a repository is usually named master or main. Branches serve as identifiers for the latest commit that does not have a child (next commit in line). When a commit is created in a branch, the branch updates and points to that new commit instead. New branches can be made using git checkout -b new_branch_name or git switch -c new_branch_name. Think of the repo as a tree, with branches as branches of the tree, and commits as leaves on the branches. Adding more commits to a repository is just like having more leaves on the branches of a growing tree. A repository can have multiple branches, each representing a different line of development. Branches allow developers to work on separate features or bug fixes without interfering with each other. When a feature is complete, it can be merged back into the main branch using git merge. This process ensures that the main branch always contains the latest and most stable code.

Stage and Commit

To stage changes, use git add. This command adds files or changes to the staging area, which is a temporary area where changes are prepared for the next commit. Once changes are staged, they can be committed using git commit. This command creates a new commit with the staged changes, along with a commit message that describes the changes made.

A stage is a temporary area where changes are prepared for the next commit. It is a way to group changes together before committing them to the repository. Staging changes allows developers to selectively include or exclude changes from a commit, making it easier to manage and track changes over time. Unstaged files are ignored and not tracked by Git.

In addition to staging changes, you can also use git rm to remove files. Alternatively, git rm --cached can be used to remove files from the staging area without deleting them from the repository.

git commit -a is a shortcut for staging all modified files and committing them with a single command. This command is useful when you want to commit all changes in a single step.

Merge and Rebase

A graphical representation of the three merge methods in Git.

A merge is a commit that combines the changes from two or more branches into a single branch. It is created using the git merge command. The merge commit has two parents, one for each branch being merged.

A rebase is a process that changes the base of a branch by applying its commits on top of another branch. It is done using the git rebase command. The rebase commit has one parent, the branch being rebased onto.

A squash is a process that combines multiple commits into a single commit. It is done using the git merge --squash command. The squash commit has one parent, the branch being rebased onto.

Stash

Stashing is a way to temporarily save changes that are not ready to be committed. This command creates a stash entry that contains the staged changes, and removes them from the working directory.

Stashes act as a stack. Stashed pushed onto the stack using git stash can be popped using git stash pop. You can also list all stashes using git stash list, drop a stash using git stash drop, clear all stashes using git stash clear, and apply a stash using git stash apply.

Checkout

The git checkout command is a very powerful command: it can be used to switch between revisions, create new branches, discard changes, obtain files from other revisions into the current working directory, and more.

Usages of git checkout

Action	Command
Switch to master branch	git checkout master
Create and switch to develop branch	git checkout -b develop
Create and switch to feature branch, based on develop	git checkout -b feature develop
Obtain files from develop into working directory	git checkout develop -- file1 file2
Discard changes in the current working directory	git checkout -- file1 file2

Remote

Remote repositories are repositories that are not on the local machine. They are used to share code with other developers, and to collaborate on projects.

If you would like to clone a remote repository, you can use git clone. This will create a new local repository that is a copy of the remote repository. A default remote named origin will be created, pointing to the original repository.

The git remote command is used to manage remote repositories. It can be used to add, remove, rename, and view remote repositories.

After your changes are committed, you can push them to the remote repository using git push.

To pull changes from a remote repository, you can use git pull.

Revert and Reset

git revert creates a new commit that reverses the changes made in the specified commit. This is useful for undoing a commit that has already been pushed to a remote repository.

git reset is used to reset the current branch to a previous commit. The local files are preserved.

git reset --hard is used to reset the current branch to a previous commit and discard all changes made after that commit.

Bisect

git bisect is used to find the commit that introduced a bug. It works by dividing the commit history into two halves, and then testing each half to see if the bug is present, and then repeating the process until the commit that introduced the bug is found. This process is called binary search.

git bisect start starts the bisect process. Here the user should use git bisect good and git bisect bad to mark the known good and bad commits. After that, git will checkout to the commit to be tested. The user should then test the commit and mark it as good or bad using git bisect good or git bisect bad.