CS 352 Homework 0, Part 3
In part 2, you created your homework repository on Bitbucket, cloned it on your local machine, and pushed local changes back up to Bitbucket. In this installment, you will learn how to pull changes down from Bitbucket to your local mirror.
Pulling
Suppose your home on for the weekend, and you get the craving to work on a CS 352 homework. Alas, you left your laptop (machine A) in your room. Good news, you can install Linux and clone your remote repository on your home computer (machine B) just as you did in parts 1 and 2. Make sure you save your changes by adding, commiting, and pushing them back up to Bitbucket.
Once you get back to campus, however, you realize that those changes exist only on Bitbucket and machine B. You do not have them on machine A. How do you get them? You pull them down.
On machine A, run this command from within you repository:
git pull
Assuming you have followed the Git Sandwich (described soon), all changes will be brought down from Bitbucket and applied to your local mirror. Bitbucket and Git make working on a project on multiple machines a reasonably pleasant experience.
Avoiding Conflicts with the Git Sandwich
Trouble can happen if you try to pull down remote changes to a file that has also been changed locally. Imagine editing a paper as a team. You make changes to your copy of the introduction, and so does a teammate—to her copy. Someone—probably you—has to go in and combine your separate changes manually. In Git terminology, this situation is called a conflict.
Since only you are the one making changes to your code in this course, you can avoid conflicts completely by making sure you follow these procedures every time you sit down to work on CS 352 homework:
- Pull down remote commits from Bitbucket.
- Edit your source code.
- Stage any new or modified files.
- Commit the staged changes.
- Push the local commits to Bitbucket.
The intent is that after every coding session, you get your changes up on Bitbucket. Before every coding session, you grab any changes from Bitbucket. If you follow this procedure, there’s no way for changes to appear on both the local and remote sides and cause a conflict.
Add Template as a Second Remote
Sometimes changes come from another direction. Perhaps your instructor fixes a broken SpecChecker or a typo in a homework specification. He pushes these changes into the template repository. These changes do not automatically appear in your repository. You must actively pull them into your local mirror. This integration is called a merge.
When the template repository changes, the Bitbucket webpage will tell you that your repository is out of sync with the template. A Synchronize link will appear. Do not click it. You will use the git client to synchronize.
Within the repository, run this command to add a second source or remote from which commits can be pulled:
git remote add template https://bitbucket.org/twodee/cs352_2016c_template
Verify that this worked by running this command:
git remote -v
You should see the template remote, but also origin, which is your repository on Bitbucket. Most Git commands work with origin by default.
Pull from a Second Remote
When your instructor pushes a change, he will announce that you need to pull down some changes from the template remote. To do this, run this command:
git pull template master
Assuming you haven’t made any changes to the specs directory, you won’t experience any conflicts. You’ve now got the latest files.
We can tweak our Git Sandwich just a little bit with this new step.
- Pull down commits from template remote, as necessary.
- Pull down commits from origin remote.
- Edit your source code.
- Stage any new or modified files.
- Commit the staged changes.
- Push the local commits to Bitbucket.