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. Current versions of Eclipse have the Eclipse plugin for Git already installed. Take a moment and browse the Overview and Basic Tutorial of the EGit User Guide.

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

   ~zeil/Assignments/cs350/gitLab/step1
   

   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. Back in your ssh session, give the command

   ~zeil/Assignments/cs350/gitLab/step3
   

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.

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.)