Lab setup with Swarthmore Github Enterprise
Using git and the Swarthmore’s GitHub Enterprise for CS lab work.
These are detailed steps to take for getting CS 44 starting point lab repos for each lab assignment, and some details about sharing code with your partner, and submitting your lab work via git. Some of these steps only need to be done once per semester, and others are general per-lab steps.
If you have not already done so, create a
for your CS 44 lab repos. All of your CS 44 lab repos
should be cloned in your
cs44/labs subdirectory, and you will do
your lab work from within that directory. This step only needs to
be done once per class.
cd ls mkdir -p cs44/labs # if you don't already have one cd cs44/labs pwd # should list /home/you/cs44/labs
Getting Lab Starting Point Code
You will do this once for each lab assignment. We use
lab1 as the example
cs44/labssubdirectory (follow the steps in Directory Setup to create it):
cd # move to your home directory cd cs44 # move into your cs44 subdirectory cd labs # move into your labs subdirectory pwd # should list /home/you/cs44
git clone email@example.com:cs44-f20/lab1-you
If you have not already completed the one-time set-up steps for using GitHub, follow those steps first for setting up ssh-keys for git, then try running the
git clonecommand from above in your cs44 subdirectory.
At this point you can
cdinto your local
lab1repo and start writing, compiling, and testing your
cd lab1-you # or using absolute path name: cd ~/cs44/labslab1-you ls # list the starting point files in your Lab1-you directory README.md ...
If you accidentally clone your
lab1 repo into the wrong part of your
file system, you can move it using the
mv command. For example, if
you cloned into your home directory, you can
cd into your home directory and
move it into your cs44/labs subdirectory using these commands:
cd ls lab1-you cs44 # oops, lab1-you is in your home directory mv lab1-you cs44/labs ./ cd cs44/labs ls # yay! its now in your cs44/labs directory lab1-you
Sharing Code with your Lab Partner
On partnered labs, you and your lab partner will each clone
a copy of your shared repo into your private cs44/labs subdirectories.
You still use
git add, commit, push and
pull commands to share changes
to your code with your partner. It is also helpful to periodically
run these git commands to save partial changes as you work on a lab — git is revision control software that saves all committed changes so
that you can recover past changes or code that is accidentally
deleted from a committed change.
When you first share a lab repo with your partner, it is useful to try out some of these commands to ensure that you and your partner have set things up correctly to share your git repo.
For example, try this out after cloning:
One of you add some minor change to a program file, like adding your name to the top comment.
Compile and run to make sure your change did not break your program.
add, commit, and
pushyour change to the repo:
$ git status # list modified files $ git add main.c # if main.c is the file you modified $ git status # should show main.c added to next commit $ git commit -m "test" # -m "..." is the message logged with the commit $ git status # should show no outstanding changes to commit $ git push # push changes to repo master
The other partner should then run
git pulland see the changes pushed by the first partner.
The other partner should follow the steps above to modify the file and run
git add, git commit, git push. And the first partner should do a
git pullto pull those changes into their local copy of the repo.
add and commit (and push) as you work
Git is revision control software, which means that it keeps track of
different version of your repo contents — all versions that you
git commit and
git push to GitHub.
It is good practice as you and your partner work on your lab to
push often. This will both allow you to have the latest
version of your joint solution, and also allow you to recover a version
of your code from git if you accidentally break something that was once
working or delete a file.
git checkout can be used to recover a
$ rm mysoln. c # oops $ git checkout mysoln.c # grabs the last committed version of mysoln.c
There are other ways to recover deleted files on our system, so don’t go
git commit nuts here, but as you get some partial functionality implemented,
and at the end of a session working together on your joint solution,
push your changes to your repo.
Before doing git add, commit, push
It is good practice to do a
make clean before doing a
git add and
commit: you do not want to add to the repo any files that are automatically built by the system, e.g., executable files compiled and linked by
gcc. Included in your lab git repos is a
file telling git to ignore these files, so you likely won’t add these
types of files by accident. However, if you have other automatically generated
files in your repo, please be careful about this.
If you accidentally add a binary executable to your repo you can remove
it using the
git rm command and then
git commit and
git push this
$ git rm a.out $ ls # a.out should no longer show up $ git commit -m "removed a.out from repo" $ git push
You should also make sure that code you are trying to push is up to date with
the latest changes pushed by your partner. Do a
git pull, and if changes
are merged into your code, you should re-test your code and make sure it
still works as expected, and if not fix.
git push look on the github repo to verify that your changes were
successfully pushed. In addition, the partner who didn’t push can
git pull to verify the the push was successful.
git push fails, then either there are local changes you haven’t committed,
or you have not pulled changes pushed by your partner into your local repo.
git status to determine if you have local changes, and if so,
commit those too. Otherwise, do a
git pull, and then make
sure your code works with the changes you pulled into your repo before
adding, committing and pushing.
git pull causes merge conflicts to files that you need to
fix by hand.
See the "Troubleshooting" and "resolving merge conflicts" information off the Git resources page for how to resolve merging and other git problems.
What to do if
git push fails and your lab is due?
If after trying to fix problems with git pushing, you are still unable
to push your lab solution to the master repo, and the lab due date is
approaching, don’t panic. If you are submitting early, attend
the ninja session or ask an instructor for help. If your are trying to
submit right before the due date, then just email your instructors letting
them know your difficulty with
git push, and Do not modify any lab
files after the due date (this means don’t open up
continue to edit and save changes to the file after the due date). Your
instructor will use the modification date of the files to determine when
you submitted your solution.