This guide provides instructions for using git for CS lab and project work with partners. It includes setup instructions for CS31 and CS35 students using git repos hosted on Swarthmore's GitHub server, and also setup instructions for students in upper-level classes who want to create their own git repos on the CS system. It also covers git commands and tools, troubleshooting errors, some advanced features, and links to other git resources.
Note: if you haven't already done so, make sure you complete the one time config steps for using the Swarthmore GitHub before proceeding: one-time Swarthmore github configuration steps
The web address is https://github.swarthmore.edu. You should be able to log in with your typical Swarthmore credentials (the same username / password you use for email). Upon logging in, you should see a welcome page that lists the repositories you currently own.
For repositories created by your professor for CS labs, we'll be using a feature of GitHub called "organizations", which allows us to control everything for the course. The organization to use will have a name something like CSnum-semester, for example use the one named CS31-f15 for the Fall'15 semester of CS31. From the main GitHub page, select the organization you want to use. (or you can jump directly to the organization link, whose url looks something like https://github.swarthmore.edu/CS31-f15)
On the organization page, you see a list of repositories that you can access. The repositories will be named according to what they contain and which users can access them. For example, suppose two teammates (Grace Hopper, ghopper1, and Alan Turing, aturnin1) are working together. When Grace accesses the organization, she would expect to see:
Initially it contains a copy of the starter code, and it will be updated as Grace and Allen push changes from their local repo to this remote master. Also, the professor will pull Grace and Allans's lab2 solution from this remote master repo at the due date of the lab assignment to collect their solution (they need to be sure to push their finished solution to this repo before the lab due date).
cd cd cs31/labsthen run git clone [URL] to locally clone the repository, where [URL] is the SSH URL given to you by GitHub. For example, Grace might run the following command to clone her and Alan's lab2 repo:
git clone email@example.com:CS31-f15/Lab2-ghopper1-aturing1.git
cd Lab2-ghopper1-aturing1 ls Makefile README.md lab2.c
If you get authentication errors, make sure you've uploaded an SSH key to your GitHub account. (See: one-time configuration steps)
You now have a private local copy of a git repo.
All changes, additions, deletions, to this project can be done with git
commands that will push and pull changes from the remote master.
Commands for using a git repo
In setting up a repo on our stystem, the first step is for one
of you to create a bare master repo for your shared project, setting
ACLs so that you both can read and write to it. You and your
partner(s) can then clone local copies into your private subdirectories.
Follow the detailed directions for doing this on this page:
Creating and cloning a remote master repo on the CS system
An example of a sequence of common git commands:
# from within your local private git repo cd ~/private/cs31/labs/lab01-me-partner/ # check the status of your repo $ git status # see the changes to the file (compared to your last local commit): $ git diff blah.c # add a new file to the repo on the next commit: $ cp ~/private/foo.c . $ git add foo.c # or add new changes to an existing repo file to the next commit: $ vi blah.c # edit with your favorite editor $ git add blah.c # commit your changes (adds and deletes) to your local repository: $ git commit # push committed changes from your local to the remote master repository # note: the first time you push, you may need to do: # git push origin master $ git push # your partner can now pull your changes from the remote into their local: $ git pull
git add foo.c blah.c # add two specified files git add # add all files except those in .gitignore file git add *.c # add all files with .c suffix
*.o myprog *.swpYou add a .gitignore file to a git repo just like you add any other file:
git add .gitignore git commit git push
git help # list common git commands git help --all lists all commands git add # add changes or new files to the next commit git rm # remove a file at the next commit git commit # commit your changes to your local repository git push # push your committed changes to the remote master repository # (note: the first time you may have to do: push origin master git pull # pull changes pushed to remote master into your local copy # (git will try to merge changes into your copy) git mv # move a repo file git diff # see a diff between a file(s) and latest commit (local repo) git diff master origin/master # diff between your copy and master's git status # see what has changed between your copy and the master version git branch -a # see all the branches (likely only master)
git config --global user.email "firstname.lastname@example.org" git config --global user.name "Your Name"
git config --global core.editor "vim"
git push origin mastersubsequent calls to git push should work (i.e. you should not need to include origin master after this first time).
user:knerr:rwx user:newhall:rwxIf there is not an entry for you, then you set acls such that you do not have access to changes that your partner makes to your repository. You can try to fix the acls by re-running setfacl (you partner will have to do it on any subdirectories that s/he now owns), or you can create a new bare repository and fix make sure to include both your names when you set acls, copy your files into your new repository, and get rid of the old one.
<<<<<< my local version changes |||||| common ancestor version ====== remote version changes that I'm trying to pull into mine >>>>>>In your editor, search for these symbols and fix the code by hand. Then add and commit your fixed version and run git pull again.
See professor Danner's Git Merge Conflict Resolution page for more detailed examples of how to resolve different types of merge conflicts.
See the git user's manual and/or git man pages (man git-clone, e.g.) for more commands.
Here are some basics for useing branches, see professor Danner's git wiki with more detailed information and help
# create a new branch named mybranch and push it to the master repo: git checkout -b mybranch git push -u origin:mybranch # list the current branch of your copy of the repo: git branch # switch to different branch: git checkout branchname git checkout master git checkout mybranch # to merge changes from mybranch into the master branch git checkout master git merge mybranch # if merge conflicts git add any files that needed to be fixed up from the merge conflict git commit # if you want to push your new version of master that is merged # with mybranch to the remote: git push # if git push fails try git push origin master # if you want to undo a merge # (and best to undo before making local changes, commits, pushes, etc.) git reset --merge ORIG_HEADHere is a nice overview of git branches: git branches
Here are some tag commands:
# list all current tags associated with a repo git tag -l # create a new tag named v1.0 with a tag message (optional) # and share a tag: push the tag to the origin to share it: git tag -a v1.0 -m "initial version" git push origin v1.0 # checking out a specific tagged version of the code # (checkout v1.0 of code into a local repo named version1)" git checkout -b version1 v1.0 # to list other data along with the commit for a specific tag # (this will show the commit number, date and who created the tag): git show v1.0