by 
On the seventh day of Christmas, my true love gave to me… seven sets of changes.
Yesterday, we learned about making a copy of a Git repository by cloning it directly, and by forking it on GitHub. Today, we’re going to learn about keeping Your Git repository up-to-date with others’ changes.
If you are following our song, “The Twelve Days of Git,” here are the verses so far:
- The 12 Days of Git: Learn Git over the Holidays
- The 12 Days of Git, Day 2: Tracking Files with Git
- The 12 Days of Git, Day 3: Viewing Git History
- The 12 Days of Git, Day 4: Double-checking Changes with Git
- The 12 Days of Git, Day 5: Sharing Changes Remotely with Git
- The 12 Days of Git, Day 6: Making a Copy of a Git Repository
In this verse, we will build on the fork of the Twitter Bootstrap repo that I suggested you make at the end of yesterday’s lesson. (Make sure you create a fork before continuing.)
In a terminal, while you are NOT in another Git repo, clone your fork down to your local machine. You can use the URL from your fork’s GitHub page, or you can copy the command below and replace with your actual GitHub user name.
git clone https://github.com//bootstrap.git
Bootstrap is a large, mature project; so, it may take awhile for the clone operation to finish. As it is clonging, you will see output like this:
Cloning into 'bootstrap'... remote: Counting objects: 89384, done. remote: Compressing objects: 100% (11/11), done. remote: Total 89384 (delta 10), reused 5 (delta 5), pack-reused 89368 Receiving objects: 100% (89384/89384), 87.40 MiB | 4.33 MiB/s, done. Resolving deltas: 100% (57265/57265), done. Checking connectivity... done.
Pulling Updates from the Original Repo
As I mentioned in the previous lesson, you are free to make changes to your local copy as you see fit, commit those changes, and push them up to your fork of the repo. What’s more, you can also keep your fork up-to-date with any changes the maintainers of the original project make.
In order to do this, you have to add a second remote to your local copy of your fork. Change your working directory to your local copy of the fork, and use the “add” version of the git remote command.
cd bootstrap git remote add upstream https://github.com/twbs/bootstrap.git
This will tell Git to remember a second remote repo, which you can refer to by the name upstream, at the address of the original Bootstrap repo in Twitter’s GitHub account. I found that Git URL the same way we have found all those type of URLs so far, by going to the repo’s page on GitHub and copying it from the text box labelled HTTPS.
If you view your local copy’s remote now, you will see both your fork and the original Twitter repo.
git remote -v
This shows the following output (with your username for your origin, of course).
origin https://github.com/vjwilson/bootstrap.git (fetch) origin https://github.com/vjwilson/bootstrap.git (push) upstream https://github.com/twbs/bootstrap.git (fetch) upstream https://github.com/twbs/bootstrap.git (push)
This sets up your remote to receive updates from the original repo, but it does not automatically pull any updates. You have to check for updates, and if you decide you don’t want any changes to a repo from the original authors, you don’t ever have to pull those changes down.
The command to pull any remote’s updates into your local repo is git pull. If you’re not pulling from your origin repo, you have to give the remote name explicitly. You can also name which branch of a project you want to synchronize. (We’ll delve into branches in detail tomorrow.)
Enter this command to check for any changes in original repo, and pull those down to your local copy.
git pull upstream master
When I ran this command a few hours after having forked Bootstrap, I saw this output which show that Git checked but did not find any new changes.
From https://github.com/twbs/bootstrap * branch master -> FETCH_HEAD * [new branch] master -> upstream/master Already up-to-date.
Depending on how much time passed between the time you forked Bootstrap and the time you pulled from upstream, you may see some new changesets added to your local copy. These changesets are now in your local copy, but to get them into your fork on GitHub, you need to push them just as you would your own changesets.
git push origin master
In this case, the name of the remote (origin> and the name of the branch (master) are optional, because those are the defaults.
You may be wondering how often you will use this feature of Git. You may not be interested in working with other people’s open-source projects, but the commands that we’ve used and the workflow we’ve learned are the same as you would do if you collaborate with friends or co-workers on a shared project. Collaborating with push and pull is very common with Git.
Be sure to come back for tomorrow’s verse, when we’ll learn about Using Git to Experiment Safely.
To see all the options available for the commands we’ve discussed today, check them out in the online Git reference: