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 this directory.

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

  1. cd into your cs31/labs subdirectory (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/

  2. Next, clone your Lab1 repo from CS31 github org into your labs subdirectory. Follow the directions off the git help page and copy the ssh-URL from your repo to clone (not the http one):

    $ 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 clone command from above in your cs31/labs subdirectory.

    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 cs31/labs subdirectories. 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:

  1. One of you add some minor change to a program file, like adding your name to the top comment

  2. Compile and run to make sure your change did not break your program.

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

  1. The other partner should then run git pull and see the changes pushed by the first partner.

  2. 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 pull to 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 add and 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 deleted file:

$ 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 .gitignore 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 change:

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

After a git push look on the github repo to verify that your changes were successfully pushed. In addtion, the partner who didn’t push can try a 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. Run 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.

Sometimes a 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.

4. Handy References