Lab: Version Control with Git
Steven J Zeil
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
Current versions of Eclipse have the Eclipse plugin for Git already installed. Take a moment and browse the EGit User Guide.
sshsession on one of the CS Linux servers. Give the command
You will be given the URI of a
Fire up your installation of Eclipse. Go to
Open perspective...and open the
Gitperspective. Move your mouse across the controls at the top of the
Git repositoriesview and select “Clone a git repository…”. Enter the URI that you were given. Fill in your user name, but leave the password blank.
Finishto 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
.gitdirectory, which is where the version control info is kept, and a directory for the real project.
In Eclipse, return to the
Javaperspective. (You can do this from
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
Look around in the project. try compiling and running it. Don’t make any changes yet.
1.1 Fetching changes
Back in your
sshsession, give the command
This is simulating someone else on your team working on the same project.
In Eclipse, right-click on your project and select
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.
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.
Most of the version control commands are accessed by right-clicking on the project and looking under the
Teammenu item. Return to the Java perspective and use that to pull the changes from the remote repository.
1.2 Committing changes
Try making some simple changes, such as editing some of the comments in the source code.
Teammenu 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
Back in your
sshsession, give the command
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
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.
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
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.)