Git Pull - How to

The Git Pull command downloads the contents of a remote re­pos­it­ory and then auto­mat­ic­ally performs a merge. You can specify the command through various arguments.

Git allows you and your team members to work on a project syn­chron­ously. This is made possible by different re­pos­it­or­ies which de­velopers can work on autonom­ously before useful and important changes are then in­teg­rated 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 re­pos­it­ory is identical. It is only if the starting point is the same that any changes can then be in­teg­rated. 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 re­pos­it­ory and then update your local re­pos­it­ory. This ensures that you’re working from the current state. After working on your local re­pos­it­ory, you can then upload the changes and additions to the remote re­pos­it­ory using the Git Push command. Working with Git Pull and Push is es­pe­cially 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 in­form­a­tion about which remote re­pos­it­ory to take over. It looks like this:

The func­tion­al­ity 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 re­pos­it­ory is specified and its current state, including all contents, is down­loaded. 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 re­pos­it­ory>” 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 al­tern­at­ives of the useful command, as presented in the following:

You can extend the classic Git Pull so that the contents of the remote re­pos­it­ory are also down­loaded, 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 re­pos­it­ory, but instead of a merge, the in­teg­ra­tion 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 re­pos­it­ory. However, Git Fetch does not modify the local re­pos­it­ory. This command makes the required files available, but retains the current state. Git Pull, on the other hand, adjusts the local re­pos­it­ory im­me­di­ately.

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 re­pos­it­ory. Then, in the second step, we run Git Pull. The command causes the contents of our remote re­pos­it­ory to be down­loaded and Git to perform Git Merge im­me­di­ately af­ter­wards. Our local re­pos­it­ory is then im­me­di­ately up to date. Here’s how it works:

To ensure as linear a history as possible, many de­velopers 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: