Git Pull - How to

The Git Pull command downloads the contents of a remote repository and then automatically performs a merge. You can specify the command through various arguments.

Git allows you and your team members to work on a project synchronously. This is made possible by different repositories which developers can work on autonomously before useful and important changes are then integrated back into the overall project. However, for this principle to lead to the best results, it is important that the starting point in each local repository is identical. It is only if the starting point is the same that any changes can then be integrated. This makes Git-Command Git Pull an important tool for working with the version control system.

With Git Pull, you download content from a remote repository and then update your local repository. This ensures that you’re working from the current state. After working on your local repository, you can then upload the changes and additions to the remote repository using the Git Push command. Working with Git Pull and Push is especially important when several users are working on a project at the same time and the latest status is needed at any time. Git Pull acts as a kind of update.

The usual syntax of Git Pull can also be found on our handy Git Cheat Sheet with a PDF download. It contains the actual command and then some information about which remote repository to take over. It looks like this:

The functionality of Git Pull is best explained with two other Git commands, which are basically executed one after the other here. First, as with Git Fetch, a remote repository is specified and its current state, including all contents, is downloaded. Then a Git Merge is performed, merging the remote copy and the local copy. While normally you would have to run the two commands “git fetch <remote repository>” and “git merge origin/ <current-branch>” one after the other, Git Pull merges them, saving you a step.

Besides the standard version of Git Pull described above, there are a few alternatives of the useful command, as presented in the following:

You can extend the classic Git Pull so that the contents of the remote repository are also downloaded, but Git does not create a new merge commit. The command then looks like this:

In this version, Git Pull also downloads all the contents of a remote repository, but instead of a merge, the integration is done with Git Rebase. This is how the command is written out:

With this version, Git Pull is performed normally, but you receive an exact listing of the new files. This way you know which contents you can continue working with.

The Git Pull and Git Fetch commands can be confused at first. After all, the basic operation is similar in that both commands download content from a remote repository. However, Git Fetch does not modify the local repository. This command makes the required files available, but retains the current state. Git Pull, on the other hand, adjusts the local repository immediately.

In the following example, we’ll show you how Git Pull works. Seeing as the command executes two steps in a row, the code becomes shorter and you need fewer lines in total. In our example, we’ll use the command Git Checkout to switch to our local repository. Then, in the second step, we run Git Pull. The command causes the contents of our remote repository to be downloaded and Git to perform Git Merge immediately afterwards. Our local repository is then immediately up to date. Here’s how it works:

To ensure as linear a history as possible, many developers prefer Git Rebase and do without Git Merge. In this case, their own changes are placed before the changes of other team members. Since Git Pull actually also performs a merge, the command must be extended by the above-mentioned addition “--rebase”. Here’s how it looks in practice: