CS 145 Homework 0, Part 2
In part 1, 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 145 homework. Alas, you left your laptop (machine A) in your room. Good news, you can install Eclipse and clone your remote repository on your home computer (machine B) just as you did in part 1. 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, right-click on your project in Eclipse. Select Team / Pull. Assuming you have followed the Git Sandwich, 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 145 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 Eclipse to synchronize.
In the Eclipse toolbar, type Git Repositories in the Quick Access field. In the window that appears, expand your project and the Remotes node. You see one remote listed named origin, which is your remote repository on Bitbucket. Right-click on Remotes and select Create Remote. Name the remote twodee, select Configure fetch, and hit OK. In the dialog that appears, click Change next to the URI field, paste in https://bitbucket.org/twodee/cs145_2016c_template, click Finish, and click Save and Fetch.
Unless your instructor has pushed a change, nothing will be fetched. But now you are ready for when he does.
Close the Git Repositories window.
Pull from a Second Remote
When your instructor pushes a change, he will announce that you need to pull down some changes from the twodee remote. To do this, right-click on your project and select Team / Pull… Be sure to choose the pull option with the ellipsis. The one without the ellipsis will pull from origin. In the dialog that appears, select the twodee remote in the Remote dropdown menu. Click Finish.
Assuming you haven’t made any changes to the aptly named readonly 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 twodee 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.