Git Pull - How to

The Git Pull command downloads the contents of a remote repos­i­to­ry and then au­to­mat­i­cal­ly performs a merge. You can specify the command through various arguments.

Git allows you and your team members to work on a project syn­chro­nous­ly. This is made possible by different repos­i­to­ries which de­vel­op­ers can work on au­tonomous­ly before useful and important changes are then in­te­grat­ed 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 repos­i­to­ry is identical. It is only if the starting point is the same that any changes can then be in­te­grat­ed. 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 repos­i­to­ry and then update your local repos­i­to­ry. This ensures that you’re working from the current state. After working on your local repos­i­to­ry, you can then upload the changes and additions to the remote repos­i­to­ry using the Git Push command. Working with Git Pull and Push is es­pe­cial­ly 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­for­ma­tion about which remote repos­i­to­ry to take over. It looks like this:

The func­tion­al­i­ty 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 repos­i­to­ry 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 repos­i­to­ry>” 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­ter­na­tives of the useful command, as presented in the following:

You can extend the classic Git Pull so that the contents of the remote repos­i­to­ry 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 repos­i­to­ry, but instead of a merge, the in­te­gra­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 repos­i­to­ry. However, Git Fetch does not modify the local repos­i­to­ry. This command makes the required files available, but retains the current state. Git Pull, on the other hand, adjusts the local repos­i­to­ry im­me­di­ate­ly.

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

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