Working on Github in cs4414
For this course you are required to use separate private repository for each problem set. Typically, you need to fetch the code skeleton from the respective public repository of the course every time before you start coding on each Problem Set.
The general process of working on problem sets is to (we'll go through each step in detail below):
Create a private repository on github for each problem set, and share that repository with the
clone the repository, so you have a local working copy.
Get the code skeleton from the public repo of CS4414 course, merge it into your working copy, and push to the main repository.
Edit code and text files in your local copy.
push the local changes to the main repository.
As you do the assignment, you should commit and push your changes regularly.
Setting up the Repository
Let's take PS1 as an example. For the first assignment in cs4414 here's what you should do.
1. Create a new repository named
- Visit https://github.com/repositories/new
- Select "Private" for the type of repository. (If you got a student discount correctly, this should be available for free. If it asks you for a credit card, go back to step 1 of setting up github.)
- Keep the "Initialize this repository with a README" unchecked, since you will fetch it later from a public repository.
2. Share this repository with the
cs4414uva github account: (be aware that this will allow the course staff to see everything you put
in the repository!)
- Visit the repository's page.
- Click the "Settings" button on the right side.
- Click the "Collaborators" tab.
- Select the user from the dropdown.
- Click "Add".
3. Clone the empty private repository to your working environment. Instead of mygithubname below, use your github username.
git clone https://github.com/mygithubname/cs4414-ps1.git
If you haven't set up SSH keys for github, you'll need to enter your github username and password.
4. Fetch the code skeleton from the public repository of CS4414 to
your private repository. Enter the working directory of your empty
repository and add a remote repository named
course, merge the code,
and push it to your private repository by executing:
git remote add course [email protected]:cs4414uva/cs4414-ps1.git git pull course master git push --tags origin master
Working with Files
Now you can write your own code in editor and save it to files. You can see what files have changed by running:
git status. You should see something like this:
# On branch master # Untracked files: # (use "git add <file>..." to include in what will be committed) # # hello.rs
In this example, nothing has been added to commit but untracked files are present.
To add the files to the main repository:
git add hello.rs
You should try running
git status again to see the files that will be
committed. Note that add stages the file in its current state! If you
modify the file after the add, the version of the file when you did the
add is the version that will be committed.
commits the staged files to the main repository. This will launch and
editor for you to enter a commit message. You can use
-m to provide a
message at the command line instead:
git commit -m 'I am no longer afraid of commitment!'
Your actual commit messages you use should be clear and useful. It is tempting to use lazy commit message, but you will regret this as your projects get more complex and code breaks in mysterious ways.
If you want to skip the two-stage commit, you can do:
git commit -a
to automatically add all new and changed files to the commit.
At this point, the changes are stored in your local repository, but not yet in the main repository. Once you have changes you want to push to the main repository:
After this, all the changes are now pushed to the main repository at github. Visit your repository in github to see the result.
This seems like a lot of steps, but by providing a full local repository and making the steps of staging and pushing to the remote repository explicit, git provides developers with a lot of control over repositories that becomes very useful when several (or many) developers are working on the same project and trying to combine each others changes (or recover from mistakes).
There are many resources for learning more about git. The free book, Pro Git by Scott Chacon is recommended.