These are steps to take for getting CS31 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 the first time you check out a lab repo, and others are general per-lab steps.
1. Setting up directory structure for CS31 lab assignments
This step only needs to be done one time.
Create a cs31 subdirectory in your home directory, and a labs
subdirectory under that. All of your lab repos should be cloned in your
cs31/labs subdirectory, and you will do your lab work from within
cd mkdir cs31 ls cd cs31 pwd mkdir labs cd labs pwd # should list /home/you/cs31/labs
2. Getting Lab Starting Point Code
You will do this once for each lab assignment. We use Lab1 as the example lab here.
cd into your
cs31/labssubdirectory (follow the steps in Section 1 to create it):
cd # from your home directory cd cs31 # move into your cs31 subdirectory cd labs # move into your labs subdirectory pwd # should list /home/you/cs31/labs/
git clone [your-ssh-URL]
If you have not already completed the one-time set-up stesps from Lab0, follow those steps first for setting up ssh-keys for git, then try running the
git clonecommand from above in your
At this point you can cd into your local Lab1 repo and start writing, compiling, and testing your lab 1 solution code:
cd Lab1-you # or using absolute path name: cd ~you/cs31/labs/Lab1-you ls # list the starting point files in your Lab1-you directory Makefile README.md QUESTIONNAIRE.md lab1.c part1.txt
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
I cloned into my home directory, I can cd into my home directory and
move it into my
cs31/labs subdirectory using this command:
cd ls Lab1-me cs31/ # oops, Lab1-me is in my home directory mv Lab1-me cs31/labs/. cd cs31/labs ls # yay! its now in my cs31/labs/ directory Lab1-me
3. 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
You sill 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 commited changes so
that you can recover past changes or code that is accidentially
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 push your 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.
3.1. 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 share and update the master repo).
It is good practice as you and your partner work on your lab to add,
commit, and 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, add,
commit and push your changes to your repo.
3.2. 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 built by
gcc (e.g., executable files). 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 gcc generated
binaries 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 addtion, the partner who didn’t push can
git pull to verify the the push was successful.
3.3. Some Troubleshooting
If 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,
add and 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.
3.4. 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 data is
approching, 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 soln.c in vim and
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.