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

Directory Setup

If you have not already done so, create a cs40/labs subdirectory for your CS40 lab repos. All of your CS40 lab repos should be cloned in your cs40/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 cs40/labs   # if you don't already have one
cd cs40/labs
pwd                   # should list /home/you/cs40/labs

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 cs40/labs subdirectory (follow the steps in Directory Setup to create it):

cd             # move to your home directory
cd cs40       # move into your cs40 subdirectory
cd labs        # move into your labs subdirectory
pwd            # should list /home/you/cs40

Next, clone your lab1 repo from CS40 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 git@github.swarthmore.edu:CS40-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 clone command from above in your cs40 subdirectory.

At this point you can cd into your local lab1 repo and start writing, compiling, and testing your lab1 solution code:
```
cd lab1-you     # or using absolute path name: cd ~/cs40/labs/lab1-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 cs40/labs subdirectory using these commands:

cd
ls
lab1-you cs40     #  oops, lab1-you is in your home directory

mv lab1-you cs40/labs ./

cd cs40/labs
ls                 # yay! it's now in your cs40/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 cs40/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 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 pull and 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 pull to 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 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.

What not to add to git

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 .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 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 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 addition, the partner who didn’t push can try a git pull to verify the the push was successful.

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.

Technical problems at deadline

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