5 min episode 22 of 24
Today, we’ll see how to download new changes from a remote repository.
First, it’s important to know that there are two different commands for downloading changes: Fetch and Pull. Before we talk about the differences between Fetch and Pull, you need to understand one thing: in order to see NEW remote data, you need to explicitly update.
I’ll make an example. Let’s say you’re working on a project - together with a teammate. Your teammate then pushes his changes to the common remote. And here’s the important thing: you will NOT know about this new data on the remote - until you explicitly request it.
When you do so, for example by performing a “Fetch”, Git makes a snapshot of the data on the remote. And it downloads it to your local repository. This means that, when you’re looking at branches or commits, you only look at that snapshot in your local repository. And this is only as fresh as your last update.
So, if you should ever wonder why you don’t see your teammates’ new commits, it’s probably because you’re looking at an old state and haven’t updated, yet.
As said, Fetch downloads all the data from the remote repository. It saves it in your local repository, and this allows you to see what happened on the remote.
The other command is “pull”. Pull also downloads new data, but it also integrates it directly into your working copy. It merges new commits into your current HEAD branch.
And this is the difference between the two: Fetch only downloads new data from a remote; but it leaves your working copy untouched. Fetch is great to stay up-to-date on what’s new on the remote. You can then decide what you want to integrate and what not.
Pull also downloads, but it also directly integrates new commits into your current HEAD branch. You could describe it as a Fetch and a Merge operation.
Let’s do all of this in practice.
First, we need to get an overview of where we are. At the moment, we can see two branches: our local master branch, and a master branch on the remote. Remember that this information is only as fresh as our last update.
I have good news. Because, by default, Tower fetches remote data automatically in the background for you. You can configure how often this should happen - or even switch it off. But to illustrate the workflow, let’s do this manually and perform a “Fetch” operation.
And there are indeed new commits on the remote that we haven’t integrated, yet. We see this both in the sidebar and in the history of our local branch. Tower marks unpushed or unpulled commits with a little arrow icon.
Git tells us all this because we established a “tracking connection” between our local master branch and its remote counterpart.
Let’s integrate these commits into our local version of the master branch. First, we make sure we are on master, currently. The “HEAD” badge here confirms this.
Then, we click the pull button on the toolbar. Thanks to our tracking connection, Tower already suggests that we pull from the origin/remote branch. After executing this, our local master branch contains all the new commits from the remote master.
Because earlier, we made that Fetch, we also see that there’s a new “feature/signup” branch on the remote. Let’s say we want to start working on this topic.
To do that, we need to create a local copy of that branch. You cannot work on a remote branch because working involves files in your working copy. And your working copy always contains the files of your local HEAD branch.
So, let’s create a local copy of that remote “feature/signup” branch. Right-click that remote branch and select the “Track” option. Alternatively, you can also just drag and drop it onto the “Branches” section header.
This created a new local branch that is based on the remote one. Additionally, it has a tracking connection that makes pulling, pushing, and staying up-to-date much easier.
With this local version of the “feature/signup” branch in place, we can now can work on this feature.
That’s it for now - thanks for watching and see you soon!