Lab: Version Control with Git

Steven J Zeil

Last modified: Dec 21, 2019

This is a self-assessment activity to give you practice in working with the git version control system. Feel free to share your problems, experiences, and choices in the Forum.

1 Gitting Started

  1. Current versions of Eclipse have the Eclipse plugin for Git already installed. Take a moment and browse the EGit User Guide.

  2. Open an ssh session on one of the CS Linux servers. Give the command


    You will be given the URI of a git repository.

  3. Fire up your installation of Eclipse. Go to Window Open perspective... and open the Git perspective. Move your mouse across the controls at the top of the Git repositories view and select “Clone a git repository…”. Enter the URI that you were given. Fill in your user name, but leave the password blank.

    Click through Next and Finish to complete the clone. As you do, take note of the directory in which your repository is being stored. (You can change this to something more convenient if you like.)

    Look in your git repository folder. You should see that a new directory has been added. Look in that directory (use -a on Linux). You will see that it contains a .git directory, which is where the version control info is kept, and a directory for the real project.

  4. In Eclipse, return to the Java perspective. (You can do this from Window Open perspective... or by using the shortcut perspective button in the upper right corner of the Eclipse window.)

    Follow the usual procedure for creating a new Java project, but instead of the default project location, select that project directory (the one containing the pastry directory).

  5. Look around in the project. try compiling and running it. Don’t make any changes yet.

1.1 Fetching changes

  1. Back in your ssh session, give the command


    This is simulating someone else on your team working on the same project.

  2. In Eclipse, right-click on your project and select Compare with... HEAD revision. This compares against the most recent check-in to your local copy of the repository. Since you have not made any changes yet, you should not see much of anything, maybe a few new files created when you compiled.

  3. Now try Compare with... branch, tag, … Select “Remote tracking” and then “master”. This compares against the remote repository, and you should be able to see that your mysterious teammate has checked in some changes.

    In the synchronization view, find the file that has changed and double-click on it to open up the comparison editor.

  4. Most of the version control commands are accessed by right-clicking on the project and looking under the Team menu item. Return to the Java perspective and use that to pull the changes from the remote repository.

1.2 Committing changes

  1. Try making some simple changes, such as editing some of the comments in the source code.

  2. From the Team menu item, commit your changes. As you examine the “commit” dialog, you will see that you have the option of doing a simple local commit or of doing a commit followed by an immediate push to the remote repository. Go ahead and push.

2 Coping with Conflict

  1. Back in your ssh session, give the command

  2. In your Eclipse session, refactor the Pie.getBaseColor and Pie.setBaseColor functions, renaming them to getBackgroundColor and setBackgroundColor.

    (By using the “refactor” menu, you get all calls to that function to be changed at the same time, even calls in other .java files.)

  3. Now try to commit and push your changes. The commit should work, but the push fails because your mysterious teammate has already checked in some more changes to the project.

  4. See if you can resolve this conflict and eventually commit and push a combination of your changes and those of your teammate. You will need to

    • fetch the changes from the remote repository,
    • force a merge between your local HEAD revision and the remote’s “master” head, if that doesn’t happen when you fetch the changes
      • Although Eclipse and git will be able to handle the merge in some files automatically, they will not be able to handle all of them, because there are some lines in one file that have been changed by both you and your simulated teammate.
    • Use the Eclipse conflict editor to combine the changes between the opposing versions of the conflicted file.
    • “Add” the resolved file back into the index as a signal that you are satisfied that the conflict has been resolved.
    • Commit and push the change again.

3 Finishing Up

The remote repository for this lab was stored in your Linux account as ~/.cs350gitlab.

To clean up after the lab (or to reset to the beginning if you want to start it over from the beginning), do

rm -rf ~/.cs350gitlab

While you still have those keys handy, now would be a good time to go to the course forge, log in to GitLab. Go to your Profile settings, select “SSH Keys”, and add your public key. This is how GitLab will know that your Eclipse IDE is allowed to work with your project. (Remember, you have already told Eclipse about the location of your private key. So, between the two of them, they have enough information to validate your credentials.)