A version control system (VCS) allows you to manage a collection of files and provides access to different versions of these files.

The VCS allows you to capture the content and structure of your files at a certain point in time. You can use the VCS to switch between these versions and work on them in parallel. The different versions are stored in a storage system which is typically called a repository. The process of creating different versions (snapshots) in the repository is depicted in the following graphic.

In this example, the repository contains two versions. The first has three files, and the second has four: two files are unchanged from the first version, one is modified, and one is new.

VCSs are well-suited for tracking changes in text files. For example, you may track changes in HTML code or Java source code. It is also possible to use a VCS for other file types, but VCSs are not as efficient at tracking changes in binary files.

A localized version control system keeps local copies of the files. This approach can be as simple as creating a manual copy of the relevant files.

A centralized version control system provides a server software component that stores and manages the different versions of the files. A developer can copy (checkout) a certain version from the central server onto their individual computer.

Both approaches have the drawback that they have a single point of failure. In a localized version control system, it is the individual computer, and in a centralized version control system, it is the server machine. Both systems also make it harder to work in parallel on different features. To remove the limitations of local and centralized version control systems, distributed version control systems have been created.

In a distributed version control system, each user has a complete local copy of a repository on their individual computer. The user can copy an existing repository. This copying process is typically called cloning and the resulting repository can be referred to as a clone.

Every clone contains the full history of the files and has the same functionality as the original repository.

Every repository can exchange file versions with other repositories by transporting these changes. This is typically done via a repository running on a server that is always online, unlike the local machine of a developer. While a central server is often used for hosting a repository, each clone is a full copy of it. The decision of which copy is considered the central server repository is a matter of convention.

Git is the leading distributed version control system.

Git originated from Linux kernel development and was created in 2005 by Linus Torvalds. Nowadays it is used by many popular open-source projects, e.g., Visual Studio Code from Microsoft, Android from Google, and the Eclipse developer teams, as well as many commercial organizations.

The core of Git was originally written in the programming language C, but Git has also been re-implemented in other languages, e.g., Java, Ruby and Python.

A Git repository manages a collection of files in a certain directory. A Git repository is file-based, i.e., all versions of the managed files are stored on the file system.

A Git repository can be designed to be used on a server or for a user:

A local non-bare Git repository is typically called local repository.

Git allows the user to synchronize the local repository with other (remote) repositories.

Users with sufficient authorization can send new commits from their local repository to remote repositories via the push operation. They can also integrate changes from other repositories into their local repository via the fetch and pull operations.

Every local repository has a working tree. The files in the working tree may be new or based on a certain version from the repository. The user can change and create files or delete them.

After making changes in the working tree, the user can capture new versions of the files in the Git repository. Alternatively, the user can restore files to a state already captured by Git.

After modifying files in your working tree you need to perform two steps to add them to your local repository.

This process is depicted in the following graphic.

During the stage operation, copies of the specified files are added to persistent storage called the staging area (sometimes also called the index). This allows you to do further modifications to the same file without including these modifications in the next commit. You can repeat the staging operation until you are satisfied and continue with the commit operation.

The commit operation creates a new persistent snapshot called commit object (short form: commit) of the managed files in the Git repository. A commit object, like all objects in Git, is immutable.

A file in the working tree of a Git repository can have one of the following states.

Untracked: the file is not tracked by the Git repository. This means that the file has never been staged or committed.

Tracked: the file has been committed and has not been changed since the last commit.

Staged: the file has been added to the staging area and is included in the next commit.

Dirty / modified: the file has been changed in the working tree but the change has not yet been staged.

Git allows you to work on different versions of your files in parallel. For this, Git uses branches. A branch allows the user to switch between these versions so that they can work on different changes independently of each other.

For example, if you want to develop a new feature, you can create a branch and make the changes in this branch. This does not affect the state of your files in other branches. For example, you can work independently on a branch called production for bugfixes and on another branch called feature_123 for implementing a new feature.

Branches in Git are local to the repository. A branch created in a local repository does not need to have a counterpart in a remote repository. Local branches can be compared with other local branches and with remote-tracking branches. A remote-tracking branch proxies the state of a branch in another remote repository.

Git supports the combination of changes from different branches. The developer can use Git commands to combine the changes at a later point in time.

The following table summarizes important Git terminology. It is intended to be used as a reference, so you can skip this now and return to it if you need clarification.

The most commonly used Git tooling is the git command line tool. The examples in this tutorial use the Git command line tooling.

Without any arguments, this command lists its options and the most common commands. You can get help for a specific Git command using the git help command followed by the command name.

To see all possible commands, use the git help --all command.

The Eclipse IDE provides excellent support for working with Git repositories.

See Using Git with the Eclipse IDE for an introduction to using Git with Eclipse.

Visual Studio Code also provides excellent built-in support for Git.

Various graphical tools are also available.

See GUI Clients for an overview of other available tools. Graphical tools like NetBeans or IntelliJ also provide integrated Git tooling, but are not covered in this description.

The Git download page provides native installers for Windows.

The Git download page also provides native installers for macOS. Git is also installed by default with the Apple Developer Tools on macOS.

On Ubuntu and similar systems, you can install the Git command line tool via the following command:

On Fedora, Red Hat, and similar systems, you can install the Git command line tool via the following command:

To install Git on other Linux distributions, please check the documentation of your distribution. The following listing contains the commands for the most popular ones.

You configure git via the git config command. These settings can be system wide, user or repository specific. A setting for the repository overrides the user setting and a user setting overrides a system wide setting.

You have to configure at least your user and email address to be able to commit to a Git repository because this information is stored in each commit.

Since Git version 2.0 the git push command pushes only the active branch to your Git remote repository by default. If you are using an older version of Git, you should configure this behavior explicitly via the following command.

You learn about the push command in Push changes to another repository.

By default, Git runs the git fetch followed by the git merge command if you use the git pull command. You can configure Git to use git rebase instead of git merge for the pull command via the following setting.

If you want Git to automatically save your uncommitted changes before a rebase you can activate autoStash. After the rebase is done your changes will get reapplied. For an explanation of git stash please see Stashing changes in Git.

The following commands enable color highlighting for Git in the console.

By default, Git uses the system default editor which is taken from the VISUAL or EDITOR environment variables if set. You can configure a different one via the following setting.

File conflicts might occur in Git during an operation that combines different versions of the same files. In this case the user can directly edit the file to resolve the conflict.

Git also allows you to configure a merge tool for solving these conflicts. You can use third party visual merge tools like tortoisemerge, p4merge, kdiff3 etc. A search for these tools helps you to install them on your platform. Keep in mind that such tools are not required, you can always edit the files directly in a text editor.

Once you have installed them you can set your selected tool as default merge tool with the following command.

To query your Git settings, execute the following command:

If you want to query the global settings you can use the following command.

Git can be configured to ignore certain files and directories for repository operations. This is configured via one or several .gitignore files. Typically, this file is located at the root of your Git repository but it can also be located in sub-directories. In the second case the defined rules are only valid for the sub-directory and below.

You can use certain wildcards in this file. * matches several characters. More patterns are possible and described under the following URL: gitignore manpage

For example, the following .gitignore file tells Git to ignore the bin and target directories and all files ending with a ~.

You can create the .gitignore file in the root directory of the working tree to make it specific for the Git repository.

It is a good practice to commit the local .gitignore file into the Git repository so that everyone who clones this repository have it.

Files that are tracked by Git are not automatically removed if you add them to a .gitignore file. Git never ignores files that are already tracked, so changes in the .gitignore file only affect new files. If you want to ignore files that are already tracked you need to explicitly remove them.

The following command demonstrates how to remove the .metadata directory and the doNotTrackFile.txt file from being tracked. This is example code, as you did not commit the corresponding files in your example, the command will not work in your Git repository.

Adding a file to the .gitignore file does not remove the file from the repository history. If the file should also be removed from the history, have a look at the git filter-branch command that allows you to rewrite the commit history. See [filterbranch_definition] for details.

You can also create a global .gitignore file valid for all Git repositories via the core.excludesfile setting. The setup of this setting is demonstrated in the following code snippet.

The global .gitignore file is only locally available.

You can also create local per-repository rules by editing the .git/info/exclude file in your repository. These rules are not committed with the repository so they are not shared with others.

This allows you to exclude, for example, locally generated files.

Git ignores empty directories, i.e., it does not put them under version control. If you want to track an empty directory in your Git repository, it is a good practice to put a file called .gitignore in the directory. As the directory now contains a file, Git includes it in its version control mechanism.

The following commands create an empty directory which is used later in this exercise to contain the working tree and the Git repository.

Use your favorite text editor to create the following files and directory structure in the current folder.

You could also create these files via the command line, for example the following commands create these files on Linux via the command line.

Use the git init command to create a new local Git repository in the created directory. Git does not care whether you start with an empty directory or if it already contains files.

All files inside the repository folder, excluding the .git folder, are the working tree.

View the status of your repository via the following command.

The output looks similar to the following listing.

Inform git that all new files should be added to the Git repository with the git stage command.

Afterwards, run the git status command again to see the current status. The following listing shows the output of this command.

Adjust an existing file.

Validate that the new changes are not yet staged.

Add the new changes to the staging area.

Use the git status command again to see that all changes are staged.

Commit the staged changes to your Git repository.

The commit operation created a new version of your files in the local repository inside the .git folder. Run the git log command to see the history.

You see an output similar to the following.

Use the git show command to see the changes of a commit. If you specify a commit reference as third parameter, this is used to determine the changes, otherwise the HEAD reference is used.

Delete a file. Stage the deletion for the next commit with the git stage . command.

Alternatively, you can use the git rm command to delete the file from your working tree and record the deletion of the file in the staging area.

Use the git restore command to restore a tracked file (a file that was once staged or committed) to its latest staged or commit state. In older versions of Git, git checkout was used for this purpose.

Restore the deleted file by restoring the last version before the current commit (HEAD~1).

Check the status and commit the file again.

You can also replace the content of a file with its last stage version or the version from a certain commit.

In the following example, you reset some changes in your working tree.

If you use git status command you will see that there are no changes left in the working directory.

The git commit --amend command makes it possible to rework the changes of the last commit. It creates a new commit with the adjusted changes.

Assume the last commit message was incorrect as it contained a typo. The following command corrects this via the --amend parameter.

You should use the git commit --amend command only for commits that have not been pushed to a public branch of another Git repository. The git commit --amend command creates a new commit ID and people may have already based their work on the existing commit. If that would be the case, they would need to migrate their work based on the new commit.

Create the following .gitignore file in the root of your Git directory to ignore the specified directory and file.

The resulting file looks like the following listing.

It is a good practice to commit the .gitignore file into the Git repository. Use the following commands for this.

Git allows you to synchronize your repository with more than one remote repository.

In the local repository you can address each remote repository by a shortcut. This shortcut is called remote. Such a remote repository points to another remote repository that can be hosted on the Internet, locally or on the network.

You can specify properties for the remote, e.g., URL, branches to fetch or branches to push.

It is possible that users connect their individual repositories directly, but a typical Git workflow involves one or more remote repositories that are used to synchronize the individual repository. Typically the remote repository which is used for synchronization is located on a server which is always available.

A remote repository on a server typically does not require a working tree. A Git repository without a working tree is called a bare repository. You can create such a repository with the --bare option. The command to create a new empty bare remote repository is displayed below.

By convention the name of a bare repository should end with the .git extension.

To create a bare Git repository in the Internet you would, for example, connect to your server via the SSH protocol or you use some Git hosting platform, e.g., GitHub.com.

Converting a normal Git repository to a bare repository is not directly supported by Git.

You can convert it manually by moving the content of the .git folder into the root of the repository and by removing all other files from the working tree. Afterwards, you need to update the Git repository configuration with the git config core.bare true command.

As this is officially not supported, you should prefer cloning a repository with the --bare option.

The git clone command copies an existing Git repository. This copy is a working Git repository with the complete history of the cloned repository. It can be used completely isolated from the original repository.

Git supports several transport protocols to connect to other Git repositories; the native protocol for Git is also called git.

The following command clones an existing repository using the Git protocol. The Git protocol uses port 9148 which might be blocked by firewalls.

If you have SSH access to a Git repository, you can also use the ssh protocol. The name preceding @ is the user name used for the SSH connection.

Alternatively, you could clone the same repository via the http protocol.

If you clone a repository, Git implicitly creates a remote named origin by default. The origin remote links back to the cloned repository.

You can push changes to this repository via git push as Git uses origin as default. Of course, pushing to a remote repository requires write access to this repository.

If you create a Git repository from scratch with the git init command, the origin remote is not created automatically. Use the following command to add a remote to your repository using the origin name.

You can add further remotes using the git remote add [name] [URL_to_Git_repo] command. For example, to add a remote named github_http for the HTTP protocol:

To rename an existing remote repository use the git remote rename command. This is demonstrated by the following listing.

It is possible to use the HTTP protocol to clone Git repositories. This is especially helpful if your firewall blocks everything except HTTP or HTTPS.

For secured SSL encrypted communication you should use the SSH or HTTPS protocol to guarantee security.

Git also provides support for HTTP access via a proxy server. The following Git command could, for example, clone a repository via HTTP and a proxy. You can either set the proxy variable in general for all applications or set it only for Git.

The following listing configures the proxy via environment variables.

The following listing configures the proxy via Git config settings.

You can synchronize your local Git repository with remote repositories. These commands are covered in detail in later sections but the following command demonstrates how you can send changes to your remote repository.

To see the existing definitions of the remote repositories, use the following command.

To see the details of the remotes, e.g., the URL use the following command.

The git push command allows you to send data to other repositories. By default, it sends data from your current branch to the same branch of the remote repository.

By default, you can only push to bare repositories (repositories without working tree). You can also only push a change to a remote repository which results in a fast-forward merge.

See Push changes of a branch to a remote repository for details on pushing branches or the Git push manpage for general information.

The git pull command allows you to get the latest changes from another repository for the current branch.

The git pull command is a shortcut for git fetch followed by the git merge or the git rebase command depending on your configuration. You configured your Git repository so that git pull is a fetch followed by a rebase.

Execute the following commands to create a bare repository based on your existing Git repository.

Clone your bare repository and checkout a working tree in a new directory via the following commands.

Make some changes in one of your non-bare local repositories and push them to your bare repository via the following commands.

To test the git pull in your example Git repositories, switch to the other non-bare local repository. Pull in the recent changes from the remote repository. Afterwards, make some changes and push them again to your remote repository.

You can pull in the changes in your first example repository with the following commands.

Git allows you to create branches. Branches are named pointers to commits. You can work on different branches independently from each other. The default branch is typically called main (or master in older repositories).

A branch pointer in Git is 41 bytes large, 40 bytes of characters and an additional new line character. Therefore, the creation of branches in Git is fast and cheap in terms of resource consumption. Git encourages the usage of branches on a regular basis.

If you decide to work on a branch, you checkout (or switch to) this branch. This means that Git populates the working tree with the version of the files from the commit to which the branch points and moves the HEAD pointer to the new branch.

HEAD is a symbolic reference usually pointing to the branch which is currently checked out.

If you checkout a commit or a tag directly and not a branch, you are in the so-called detached HEAD mode. If you commit changes in this mode, you have no branch that points to this commit.

It is not recommended to create new commits in this mode because such commits would not be visible on a branch and you may not find them easily. Detached HEAD mode is intended to make it easy to view files referred to by a certain commit.

The git branch command lists all local branches. The currently active branch is marked with *.

If you want to see all branches (including remote-tracking branches), use the -a for the git branch command.

The -v option lists more information about the branches.

To list branches in a remote repository use the git branch -r command as demonstrated in the following example.

You can create a new branch via the git branch [newname] command. This command allows you to specify the commit (commit id, tag, remote or local branch) to which the branch pointer originally points. If not specified, the commit to which the HEAD reference points is used to create the new branch.

To start working in a branch you have to switch to (or checkout) the branch. If you switch to a branch, the HEAD pointer moves to the last commit in this branch and the files in the working tree are set to the state of this commit.

The following commands demonstrate how you switch to the branch called testing, perform some changes in this branch and switch back to the default branch.

To create a branch and to switch to it at the same time you can use the git switch command with the -c parameter.

Renaming a branch can be done with the following command.

To delete a branch which is no longer needed, you can use the following command. You may get an error message that there are uncommitted changes if you did the previous examples step by step. Use force delete (uppercase -D) to delete it anyway.

You can push the changes in a branch to a remote repository by specifying the target branch. This creates the target branch in the remote repository if it does not yet exist.

If you do not specify the remote repository, the origin is used as default

This way you can decide which branches you want to push to other repositories and which should be local branches.

Untracked files (never added to the staging area) are unrelated to any branch. They exist only in the working tree and are ignored by Git until they are committed to the Git repository. This allows you to create a branch for unstaged and uncommitted changes at any point in time.

Similar to untracked files you can switch branches with unstaged or staged modifications that are not yet committed.

You can switch branches if the modifications do not conflict with the files from the branch.

If Git needs to modify a changed file during the checkout of a branch, the checkout fails with a checkout conflict error. This avoids losing changes in your files.

In this case the changes must be committed, reverted or stashed. You can also always create a new branch based on the current HEAD.

To see the difference between two branches you can use the following command.

You can use commit ranges. For example, if you compare a branch called your_branch with the main branch the following command shows the changes in your_branch and main since these branches diverged.

You can use the option -s to create a signed tag. These tags are signed with GNU Privacy Guard (GPG) and can also be verified with GPG. For details on this please see the following URL: Git tag manpage.

If you want to use the code associated with the tag, use:

By default, the git push command does not transfer tags to remote repositories. You explicitly have to push the tag with the following command.

You can delete tags with the -d parameter. This deletes the tag from your local repository. By default, Git does not push tag deletions to a remote repository, you have to trigger that explicitly.

The following commands demonstrate how to push a tag deletion.

You can use the -l parameter in the git tag command to search for a pattern in the tag.

Tags are frequently used to tag a software release. In this case, they are called release tags.

Convention is that release tags are labeled based on the [major].[minor].[patch] naming scheme. These release tags follow the semantic versioning of the software release.

For example, "1.0.0" or "v1.0.0".

If software build tools like Maven or Gradle are used, the released version should also follow the semantic versioning. In this case the tag is typically the same as the release version.

See Semantic versioning for more information.

Git allows you to list the commits between any reference; this includes tags.

This allows you to create a release log, for example via the following commands.

The git status command shows the current status of your repository and possible actions which you can perform.

It shows which files have changed, which are staged and which are not part of the staging area. It also shows which files have merge conflicts and gives an indication what the user can do with these changes, e.g., add them to the staging area or remove them, etc.

The following commands create some changes in your Git repository.

Now use the status command.

The output of the command looks like the following listing.

The git diff command allows you to compare changes between commits, the staging area and working tree, etc. Via an optional third parameter you can specify a path to filter the displayed changes. The path can be a file or directory git diff [path].

The following example code demonstrates the usage of the git diff command.

The git log command shows the history of the Git repository. If no commit reference is specified it starts from the commit referred to by the HEAD pointer.

The following gives an overview of useful parameters for the git log command.

For more options on the git log command see the Git log manpage.

To see changes in a file you can use the -p option in the git log command.

You can use the --pretty parameter to configure the output.

This command creates the output.

You can filter the output of the git log command to commits whose commit message, or reflog entry, respectively, matches the specified regular expression pattern with the --grep=<pattern> and --grep-reflog=<pattern> option.

For example, the following command instructs the log command to list all commits that contain the word "workspace" in their commit message.

There is also the --invert-grep=<pattern> option. When this option is used, git log lists the commits that do not match the specified pattern.

You can use the --author=<pattern> or --committer=<pattern> to filter the log output by author or committer. You do not need to use the full name, if a substring matches, the commit is included in the log output.

The following command lists all commits with an author name containing the word "Vogel".

See also git shortlog for release announcements.

To see the changes introduced by a commit use the following command.

To see the differences introduced between two commits you use the git diff command specifying the commits. For example, the following command shows the differences introduced in the last commit.

To see the files that have been changed in a commit use the git diff-tree command. The name-only tells the command to show only the names of the files.

Using the Git log command and filtering the history is a useful tool for inspecting the project history. However, if you look at a particular file and find a bug in a particular line of code you would like to instantly know who was the last person who changed this line of code. Additionally, you would like to know why the developer did that, i.e., locate the commit in which the change was done.

In Git, this feature is called git blame or git annotate. The git blame command allows you to see which commit and author last modified each line of a file. That is useful to identify the person or the commit which introduced a change.

The output of git blame shows one annotated entry per line of the file. Each entry contains the following information:

The following is a sample git blame output:

A ^ prefix on the commit SHA-1 indicates the boundary commit, i.e., the first commit that introduced the line into the repository.

The following code snippet demonstrates the usage of the git blame command.

The following table lists commonly used options for the git blame command.

Git provides the git stash command that allows you to record the current state of the working directory and the staging area and to revert to the last committed revision.

This allows you to pull in the latest changes or to develop an urgent fix. Afterwards, you can restore the stashed changes, which will reapply the changes to the current version of the source code.

In general, using the stash command should be the exception in using Git. Typically, you would create new branches for new features and switch between branches. You can also commit frequently in your local Git repository and use interactive rebase to combine these commits later before pushing them to another Git repository.

Even if you prefer not to use branches, you can avoid using the git stash command. In this case you commit the changes you want to put aside and amend the commit with the next commit. If you use the approach of creating a commit, you typically put a marker in the commit message to mark it as a draft, e.g., "[DRAFT] implement feature x".

The following commands will save a stash and reapply them after some changes.

It is also possible to keep a list of stashes.

You can also create a branch for your stash if you want to continue to work on the stashed changes in a branch. This can be done with the following command.

If you have untracked files in your working tree that you want to remove, you can use the git clean command.

The following commands demonstrate the usage of the git clean command.

Use the git restore --staged [paths] command to remove staged changes from the staging area. This avoids including these changes in the next commit. In older versions of Git, git reset [paths] was used for this purpose.

This means that git restore --staged [paths] is the opposite of git add [paths]. The changes are still available in the working tree and you can stage and commit them at a later point.

In the following example you create a new file and change an existing file. Both changes are staged.

The output of the git status command should look similar to the following.

Remove the changes from the staging area with the following command.

Use the git status command to see the result.

The git reset behaves differently depending on the options you provide.

Undesired changes in the working tree that are not staged can be undone with the git restore command. This command resets the file in the working tree to the latest staged version. If there are no staged changes, the latest committed version is used for the restore operation.

For example, you can restore the contents of a directory called data with the following command.

If you want to undo a staged but uncommitted change, you use the git restore --staged --worktree [paths] command. This version of the command resets both the working tree and the staging area.

The following demonstrates the usage of this to restore a deleted directory.

The --staged parameter instructs the git restore command to also reset the staging area along with the working tree.

When you have added the changes of a file to the staging area, you can also revert the changes in the staging area based on the last commit.

The git reset command allows you to change the commit your HEAD is pointing to (indirectly or directly). This can for example be used to remove an undesired commit.

If a branch is checked out, this branch pointer will move and HEAD indirectly points to the new commit. If your HEAD points directly to a commit (detached HEAD mode) the HEAD pointer will point to the new commit.

For simplification the following will say that the HEAD pointer moves, independent of whether a branch or a commit is checked out.

The reset command will always move the branch pointer (or the HEAD pointer in case of detached HEAD mode) and update the working tree based on the new commit. The following parameters allow you to define what happens to the current changes in the working tree and changes which were included in the commits between the original commit and the commit now referred to by the HEAD pointer.

Depending on the specified parameters the git reset command performs the following:

Use the --mixed or --soft option to keep file changes.

These parameters are listed in the following table.

The git reset command does not remove untracked files. If you have untracked files in your working tree which you want to remove, you can use the git clean command.

If you specify a path via the git reset [path] command, Git does not move the HEAD pointer. It updates the staging area or also the working tree depending on your specified option.

The git show command allows you to see and retrieve files from branches, commits and tags. It allows seeing the status of these files in the selected branch, commit or tag without checking them out into your working tree.

By default, this command addresses a file from the root of the repository, not the current directory. If you want the current directory then you have to use the ./ specifier. For example, to address the pom.xml file in the current directory use: ./pom.xml

The following commands demonstrate that. You can also make a copy of the file.

You can checkout a file from the commit. To find the commit which deleted the file you can use the git log or the git ref-list command as demonstrated by the following commands.

You can restore arbitrary revisions of your file system via the git switch --detach command followed by a commit reference. This command resets the working tree to the state described by this commit and puts you in detached HEAD mode.

To checkout a specific commit you can use the following command.

Commits are not shown by Git if they are no longer directly or indirectly referred to by a pointer, like a branch or tag. Certain git commands remove commits from your view, e.g.: * git reset may remove commits from your current branch and therefore these commits vanish from your view * Amending a commit also removes the commit from your view

For example, assume you have two commits A→ B, where B is the commit after A. You reset your branch pointer to A, the git log command does not include B anymore.

git reflog command allows you to find such commits by showing the HEAD pointer movements.

Reflog is a mechanism to record the movements of the HEAD and the branches references.

The reflog command gives a history of the complete changes of the HEAD reference.

The git reflog command also lists commits which you have removed.

The following example shows how you can use git reflog to reset the current local branch to a commit which is not reachable from the current branch anymore.

Your local Git repository contains references to the state of the branches on the remote repositories to which it is connected. These local references are called remote-tracking branches.

You can see your remote-tracking branches with the following command.

To update remote-tracking branches without changing local branches you use the git fetch command.

It is safe to delete a remote branch in your local Git repository, this does not affect a remote repository. The next time you run the git fetch command, the remote branch is recreated. You can use the following command for that.

To delete the branch in a remote repository use the following command.

Branches can track another branch. This is called to have an upstream branch and such branches can be referred to as tracking branches.

Tracking branches allow you to use the git pull and git push command directly without specifying the branch and repository.

If you clone a Git repository, your local default branch (e.g., main or master) is created as a tracking branch for the corresponding branch of the origin repository (short: origin/main or origin/master) by Git.

You create new tracking branches by specifying the remote branch during the creation of a branch. The following example demonstrates that.

Instead of using the git switch command you can also use the git branch command.

The --no-track option allows you to specify that you do not want to track a branch. You can explicitly add a tracking branch with the git branch -u command later.

To see the tracking branches for a remote repository (short: remote) you can use the following command.

An example output of this might look as follows.

The git fetch command updates your remote-tracking branches, i.e., it updates the local copy of branches stored in a remote repository. The following command updates the remote-tracking branches from the repository called origin.

The fetch command only updates the remote-tracking branches and none of the local branches. It also does not change the working tree of the Git repository. Therefore, you can run the git fetch command at any point in time.

After reviewing the changes in the remote tracking branch you can merge the changes into your local branches or rebase your local branches onto the remote-tracking branch.

Alternatively, you can also use the git cherry-pick commit_id command to take over only selected commits.

See Applying a single commit with cherry-pick for information about cherry-pick. See Merging for the merge operation and Rebasing branches. for the rebase command.

The git fetch command updates only the remote-tracking branches for one remote repository. In case you want to update the remote-tracking branches of all your remote repositories you can use the following command.

The following code shows a few options for how you can compare your branches.

The above commands show the changes introduced in HEAD compared to origin. If you want to see the changes in origin compared to HEAD, you can switch the arguments or use the -R parameter.

You can rebase your current local branch onto a remote-tracking branch. The following commands demonstrate that.

The git pull command performs a git fetch and git merge (or git rebase based on your Git settings). The git fetch does not perform any operations on your local branches. You can always run the fetch command and review the incoming changes.

If the commits that are merged are direct successors of the HEAD pointer of the current branch, Git performs a so-called fast forward merge. This fast forward merge only moves the HEAD pointer of the current branch to the tip of the branch which is being merged.

This process is depicted in the following diagram. The first picture assumes that main is checked out and that you want to merge the changes of the branch labeled "branch 1" into your "main" branch. Each commit points to its predecessor (parent).

After the fast-forward merge the HEAD points to the main branch pointing to "Commit 3". The "branch 1" branch points to the same commit.

If commits are merged that are not direct predecessors of the current branch, Git performs a so-called three-way-merge between the latest commits of the two branches, based on the most recent common predecessor of both.

As a result a so-called merge commit is created on the current branch. It combines the respective changes from the two branches being merged. This commit points to both of its predecessors.

If multiple common predecessors exist, Git uses recursion to create a virtual common predecessor. For this Git creates a merged tree of the common ancestors and uses that as the reference for the 3-way merge. This is called the ort merge strategy (formerly recursive) and is the default merge strategy since Git 2.34.

If a fast-forward merge is not possible, Git uses a merge strategy. The default strategy called ort (formerly recursive) merge strategy was described in Merge commit.

The Git command line tooling also supports the octopus merge strategy for merges of multiple references. With this operation it can merge multiple branches at once.

The subtree option is useful when you want to merge in another project into a sub-directory of your current project. It is rarely used and you should prefer the usage of Git submodules. See Git Submodules for more information.

The ours strategy merges a branch without looking at the changes introduced in this branch. This keeps the history of the merged branch but ignores the changes introduced in this branch.

You can use the ours merge strategy to document that you have integrated a branch and decided to ignore all changes from this branch.

The git merge command performs a merge. You can merge changes from one branch to the current active one via the following command.

The -s parameter allows you to specify other merge strategies.

For example, you can specify the ours strategy in which the result of the merge is always that of the current branch head, effectively ignoring all changes from all other branches. This is demonstrated with the following command.

The usage of the octopus merge strategy is triggered if you specify more than one reference to merge.

The default merge strategy (ort, formerly recursive) allows you to specify flags with the -X parameter. For example, you can specify the ours option. This option forces conflicting changes to be auto-resolved by favoring the local version. Changes from the other branch that do not conflict with our local version are preserved in the merge result. For a binary file, the entire contents are taken from the local version.

A similar option to ours is the theirs option. This option prefers the version from the branch which is merged.

Both options are demonstrated in the following example code.

Another useful option is the ignore-space-change parameter that ignores whitespace changes.

For more information about the merge strategies and options see Git merge manpage.

If you prefer to have merge commits even for situations in which Git could perform a fast-forward merge you can use the git merge --no-ff command.

The --no-ff parameter can make sense if you want to record in the history at which time you merged from a maintenance branch to the main branch.

When pulling from a remote repository, prefer doing a rebase to a merge. This will help to keep the history easier to read. A merge commit can be helpful to document that functionality was developed in parallel.

You can use Git to rebase one branch on another one. As described, the merge command combines the changes of two branches. If you rebase a branch called A onto another, the git command takes the changes introduced by the commits of branch A and applies them based on the HEAD of the other branch. After this operation the changes in the other branch are also available in branch A.

The process is displayed in the following picture. We want to rebase the branch called branch_1 onto main.

Running the rebase command creates a new commit with the changes of the branch on top of the main branch.

Performing a rebase does not create a merge commit. The final result for the source code is the same as with merge but the commit history is cleaner; the history appears to be linear.

Rebase can be used to forward-port a feature branch in the local Git repository onto the changes of the main branch. This ensures that your feature is close to the tip of the upstream branch until it is finally published.

If you rewrite more than one commit by rebasing, you may have to solve conflicts per commit. In this case the merge operations might be simpler to be performed because you only have to solve merge conflicts once.

Also, if your policy requires that all commits result in correct software you have to test all the rewritten commits since they are "rewritten" by the rebase algorithm. Since merge/rebase/cherry-pick are purely text-based and do not understand the semantics of these texts they can end up with logically incorrect results. Hence, it might be more efficient to merge a long feature branch into upstream instead of rebasing it since you only have to review and test the merge commit.

You should avoid using the Git rebase operation for changes that have been published in other Git repositories. The Git rebase operation creates new commit objects, this may confuse other developers using the existing commit objects.

Assume that a user has a local feature branch and wants to push it to a branch on the remote repository. However, the branch has evolved and therefore pushing is not possible. Now it is a good practice to fetch the latest state of the branch from the remote repository. Afterwards, you rebase the local feature branch onto the remote tracking branch. This avoids an unnecessary merge commit. This rebasing of a local feature branch is also useful to incorporate the latest changes from remote into the local development, even if the user does not want to push right away.

The following demonstrates how to perform a rebase operation.

Git allows you to edit your commit history with functionality called interactive rebase. For example, you can combine several commits into one commit, reorder or skip commits and edit the commit message.

This is useful as it allows the user to rewrite some commit history (cleaning it up) before pushing the changes to a remote repository.

Interactive rebase allows you to quickly edit a series of commits using the following actions:

The setup for the rebase is called the rebase plan. Based on this plan, the actual interactive rebase can be executed.

The following commands create several commits which will be used for the interactive rebase.

We want to combine the last seven commits. You can do this interactively via the following command.

This command opens your editor of choice and lets you configure the rebase operation by defining which commits to pick, squash or fixup.

The following listing shows an example of the selection. We pick the last commit, squash 5 commits and fix the sixth commit. The listing uses the long format of the commands (for example fixup instead of the short form f ) for better readability.

The git cherry-pick command allows you to select the patch which was introduced with an individual commit and apply this patch on another branch. The patch is captured as a new commit on the other branch.

This way you can select individual changes from one branch and transfer them to another branch.

In the following example you create a new branch and commit two changes.

You can check the commit history, for example, with the git log --oneline command.

The following command selects the first commit based on the commit ID and applies its changes to the main branch. This creates a new commit on the main branch.

The cherry-pick command can be used to change the order of commits. git cherry-pick also accepts commit ranges for example in the following command.

If things go wrong or you change your mind, you can always reset to the previous state using the following command.

A conflict during a merge operation occurs if two commits from different branches have modified the same content and Git cannot automatically determine how both changes should be combined when merging these branches.

This happens for example if the same line in a file has been replaced by two different commits.

If a conflict occurs, Git marks the conflict in the file and the programmer has to resolve the conflict manually.

After resolving it, the developer adds the file to the staging area and commits the change. These steps are required to finish the merge operation.

In the following example you perform the merge operation. This operation results in a merge conflict which you solve.

It assumes that repo1 and repo2 have the same origin repository defined.

As this push would not result in a fast-forward merge, you receive an error message similar to the following listing.

To solve this, you need to integrate the remote changes into your local repository. In the following listing the git fetch command gets the changes from the remote repository. The git merge command tries to integrate it into your local repository.

This creates the conflict and a message similar to the following.

The resulting conflict is displayed in Review the conflict in the file and solved in Solve a conflict in a file.

Git marks the conflicts in the affected files. In the example from Create a conflict one file has a conflict and the file looks like the following listing.

The text above the ======= signs is the conflicting change from your current branch and the text below is the conflicting change from the branch that you are merging in.

In this example, you resolve the conflict which was created in Create a conflict and apply the change to the Git repository.

To solve the merge conflict you edit the file manually. The following listing shows a possible result.

Afterwards, add the affected file to the staging area and commit the result. This creates the merge commit. You can also push the integrated changes now to the remote repository.

Instead of using the -m option in the above example you can also use the git commit command without this option. In this case the command opens your default editor with the default commit message about the merged conflicts. It is a good practice to use this message.

During a rebase operation, several commits are applied onto a certain commit. If you rebase a branch onto another branch, this commit is the last common ancestor of the two branches.

For each commit that is applied it is possible that a conflict occurs.

An alias in Git allows you to create a short form of one or several existing Git commands. For example, you can define an alias which is a short form of your own favorite commands or you can combine several commands with an alias.

The following defines an alias to see the staged changes with the new git staged command.

Or you can define an alias for a detailed git log command. The following command defines the git ll alias.

You can also run external commands. In this case you start the alias definition with a ! character. For example, the following defines the git ac command that combines git add . -A and git commit commands.

When you add a file tracked by LFS to your repository, Git LFS replaces its contents with a pointer and stores the file contents in a local Git LFS cache.

When you push new commits to the server, any Git LFS files referenced by the newly pushed commits are transferred from your local Git LFS cache to the remote Git LFS store tied to your Git repository.

When you checkout a commit that contains Git LFS pointers, they are replaced with files from your local Git LFS cache, or downloaded from the remote Git LFS store.

To use Git LFS, you need a Git LFS aware host such as GitHub, GitLab, or Bitbucket.

The git lfs track command creates or updates the .gitattributes file in your repository. Make sure to commit this file to your repository.

The git worktree command allows you to have multiple working trees attached to the same repository. Each working tree is linked to the repository and can have a different branch checked out.

This is useful when you need to work on multiple branches at the same time without having to switch branches or stash your changes. For example, you can work on a feature branch while simultaneously reviewing or testing a fix on a different branch.

Using git worktree has several advantages over switching branches with git switch or using git stash:

To create a new worktree for an existing branch, use the following command.

This creates a new directory ../hotfix-worktree with the hotfix-branch checked out.

To create a new worktree with a new branch, use the -b option.

To see all worktrees associated with the current repository, use the following command.

This shows the path, the HEAD commit, and the branch name for each worktree.

When you are done with a worktree, you can remove it with the following command.

Alternatively, you can delete the directory manually and then run git worktree prune to clean up stale worktree references.

Each branch can only be checked out in one worktree at a time. If you try to create a worktree for a branch that is already checked out in another worktree, Git will report an error.

The git bisect command allows you to run a binary search through the commit history to identify the commit which introduced an issue. You specify a range of commits and a script that the bisect command uses to identify whether a commit is good or bad.

This script must return 0 if the condition is fulfilled and non-zero if the condition is not fulfilled.

Create a new Git repository, create the text1.txt file and commit it to the repository. Do a few more changes, remove the file and again do a few more changes.

We use a simple shell script which checks the existence of a file. Ensure that this file is executable.

Afterwards, use the git bisect command to find the bad commit. First you use the git bisect start command to define a commit known to be bad (showing the problem) and a commit known to be good (not showing the problem).

Afterwards, run the bisect command using the shell script.

git-filter-repo is a versatile tool for rewriting Git repository history. It is the recommended replacement for the deprecated git filter-branch command. It allows you to remove files, change email addresses, and restructure repositories with significantly better performance and safety.

git-filter-repo works by creating a new history based on your filter rules. Because it rewrites commit hashes, it is a destructive operation for the existing history.

git-filter-repo is Python-based. You can install it via pip:

On some Linux distributions, it is also available via the package manager.

Before making changes, it is useful to analyze the repository to see what creates large file sizes or to identify files to remove.

This command creates a .git/filter-repo/ directory containing reports about:

To remove a specific file or directory from the entire history of the repository, use the --path or --invert-paths options.

To keep only a specific directory and remove everything else:

To extract a subdirectory to be the new project root (similar to git filter-branch --subdirectory-filter):

To remove a specific file (e.g., a file with sensitive data) from history:

You can use a mailmap file to change author names and emails throughout the history. This is useful for unifying multiple email addresses for the same person or correcting typos.

Create a file named mailmap with the following format:

Then apply the mailmap:

For more complex rewriting needs, git-filter-repo supports extensive python-based callbacks. See the official documentation for details. == Working with patch files

A patch is a text file that contains changes to other text files in a standardized format. A patch created with the git format-patch command includes meta-information about the commit (committer, date, commit message, etc) and also contains the changes introduced in binary data in the commit.

This file can be sent to someone else and the receiver can use it to apply the changes to his local repository. The metadata is preserved.

Alternatively, you could create a diff file with the git diff command, but this diff file does not contain the metadata.

The following example creates a branch, changes several files and creates a commit recording these changes.

The next example creates a patch for these changes.

To apply this patch to your main branch in a different clone of the repository, switch to it and use the git apply command.

Afterwards, you can commit the changes introduced by the patches and delete the patch file.

You can specify the commit ID and the number of patches which should be created. For example, to create a patch for selected commits based on the HEAD pointer you can use the following commands.

Git provides commit hooks, e.g., programs that can be executed at a predefined point during the work with the repository. For example, you can ensure that the commit message has a certain format or trigger an action after a push to the server.

These programs are usually scripts and can be written in any language, e.g., as shell scripts or in Perl, Python etc. You can also implement a hook, for example, in C and use the resulting executables. Git calls the scripts based on a naming convention.

Git provides hooks for the client and for the server side. On the server side you can use the pre-receive and post-receive script to check the input or to trigger actions after the commit. The usage of a server commit hook requires that you have access to the server. Hosting providers like GitHub or Bitbucket do not offer this access.

If you create a new Git repository, Git creates example scripts in the .git/hooks directory. The example scripts end with .sample. To activate them make them executable and remove the .sample from the filename.

The hooks are documented under the following URL: Git hooks manual page.

Not all Git server implementations support server side commit hooks. Local hooks in the local repository can be removed by the developer.

Every time a developer presses return on the keyboard an invisible character called a line ending is inserted. Unfortunately, different operating systems handle line endings differently.

Linux and Mac use different line endings than Windows. Windows uses a carriage-return and a linefeed character (CRLF), while Linux and Mac only use a linefeed character (LF). This becomes a problem if developers use different operating systems to commit changes to a Git repository.

To avoid having commits with line ending differences in your Git repository you should configure all clients to write the same line ending to the Git repository.

On Windows systems you can tell Git to convert line endings during a checkout to CRLF and to convert them back to LF during commit. Use the following setting for this.

On Linux and Mac you can tell Git to convert CRLF to LF with the following setting.

You can also configure the line ending handling per repository by adding a special .gitattributes file to the root folder of your Git repository. If this file is committed to the repository, it overrides the core.autocrlf setting of the individual developer.

In this file you can configure Git to auto detect the line endings.

The usage of symlinks requires that the operating system used by the developers supports them.

Git as version control system can handle symlinks.

If the symlink points to a file, then Git stores the path information it is symlinking to, and the file type. This is similar to a symlink to a directory; Git does not store the contents under the symlinked directory.

Conceptually a commit object (short:commit) represents a version of all files tracked in the repository at the time the commit was created. Commits know their parent(s) and this way capture the version history of the repository.

This commit object is addressable via a hash ( SHA-1 checksum ). This hash is calculated based on the content of the files, the content of the directories, the complete history up to the new commit, the committer, the commit message, and several other factors.

This means that Git is safe, you cannot manipulate a file or the commit message in the Git repository without Git noticing that corresponding hash does not fit anymore to the content.

The commit object points to the individual files in this commit via a tree object. The files are stored in the Git repository as blob objects and might be packed by Git for better performance and more compact storage. Blobs are addressed via their SHA-1 hash.

Packing involves storing changes as deltas, compression and storage of many objects in a single pack file. Pack files are accompanied by one or multiple index files which speedup access to individual objects stored in these packs.

A commit object is depicted in the following picture.

The above picture is simplified. Tree objects point to other tree objects and file blobs. Objects which did not change between commits are reused by multiple commits.

A Git commit object is identified by its hash (SHA-1 checksum). SHA-1 produces a 160-bit (20-byte) hash value. A SHA-1 hash value is typically rendered as a hexadecimal number, 40 digits long.

In a typical Git repository you need fewer characters to uniquely identify a commit object. This short form is called the abbreviated commit hash or abbreviated hash. Sometimes it is also called the shortened SHA-1 or abbreviated SHA-1.

Several commands, e.g., the git log command can be instructed to use the shortened SHA-1 for their output.

Each commit has zero or more direct predecessor commits. The first commit has zero parents, merge commits have two or more parents, most commits have one parent.

In Git you frequently want to refer to certain commits. For example, you want to tell Git to show you all changes which were done in the last three commits. Or you want to see the differences introduced between two different branches.

Git allows you to address commits via commit reference for this purpose.

A commit reference can be a simple reference (simple ref), in this case it points directly to a commit. This is the case for a commit hash or a tag. A commit reference can also be symbolic reference (symbolic ref, symref). In this case it points to another reference (either simple or symbolic). For example, HEAD is a symbolic ref for a branch, if it points to a branch. HEAD points to the branch pointer and the branch pointer points to a commit.

A branch points to a specific commit. You can use the branch name as reference to the corresponding commit. You can also use HEAD to reference the corresponding commit.

You can use ^ (caret) and ~ (tilde) to reference predecessor commit objects from other references. You can also combine the ^ and ~ operators. See Using caret and tilde for commit references for their usage.

The Git terminology is parent for ^ and ancestor for ~.

[reference]~1 describes the first predecessor of the commit object accessed via [reference]. [reference]~2 is the first predecessor of the first predecessor of the [reference] commit. [reference]~3 is the first predecessor of the first predecessor of the first predecessor of the [reference] commit, etc.

[reference]~ is an abbreviation for [reference]~1.

For example, you can use the HEAD~1 or HEAD~ reference to access the first parent of the commit to which the HEAD pointer currently points.

[reference]^1 also describes the first predecessor of the commit object accessed via [reference].

For example, the following references point to the same commit:

The difference is that [reference]^2 describes the second parent of a commit. A merge commit typically has two predecessors. HEAD^3 means ‘the third parent of a merge’ and in most cases this won’t exist (merges are generally between two commits, though more is possible).

[reference]^ is an abbreviation for [reference]^1.

You can also specify ranges of commits. This is useful for certain Git commands, for example, for seeing the changes between a series of commits.

The double dot operator allows you to select all commits that are reachable from a commit c2 but not from commit c1. The syntax for this is c1..c2. A commit A is reachable from another commit B if A is a direct or indirect parent of B.

For example, you can ask Git to show all commits which happened between HEAD and HEAD~4.

This also works for branches. To list all commits that are in the master branch but not in the testing branch, use the following command.

You can also list all commits that are in the testing but not in the master branch.

The triple dot operator allows you to select all commits that are reachable either from commit c1 or commit c2 but not from both of them.

This is useful to show all commits in two branches that have not yet been combined.

If you need more assistance we offer Online Training and Onsite training as well as consulting

See License for license information.