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 to synchronize in the other direction—you will pull changes down from Bitbucket to your local repository.
Suppose you’re home for the weekend, and you get the craving to work on a CS 1 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, which is back home. You do not have them on machine A, which is in your room. 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, described below, all changes will be brought down from Bitbucket and integrated into your local repository. Bitbucket and Git make working on a project on multiple machines a reasonably pleasant experience.
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 then 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 homework in this course:
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.
Do not wait until the homework is completely done before committing and pushing. Surround each of your coding sessions with the Git Sandwich!
Sometimes changes come from another remote repository that is not your own. Perhaps your instructor fixes a broken SpecChecker. He pushes these changes into his 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 will see one remote listed named origin, which is your remote repository on Bitbucket. Right-click on Remotes and select Create Remote. Name the remote template, select Configure fetch, and hit OK. In the dialog that appears, click Change next to the URI field, paste in
https://bitbucket.org/twodee/cs1_2017c_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.
When your instructor pushes a change, he will announce that you need to pull down some changes from the template 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 template remote in the Remote dropdown menu. Click Finish.
Assuming you haven’t made any changes to the
speccheckers directory and you’ve been following the Git Sandwich faithfully, 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.