CS 70

Getting Down to Work

  • LHS Cow speaking

    Now that you have your various remote accounts set up and working, it's time to see how to actually work on assignments!

Now that the server is set up, it's time to get your own copy of your repository onto it and change something.

  • Horse speaking

    Hay, wait! It's not local! It's on the remote server!

  • LHS Cow speaking

    Yes, the terminology is confusing. “Local” here is in contrast to the “remote” copy which is stored on the GitHub servers.

  • RHS Cow speaking

    So the copy of the repository you will work on is local to the CS 70 server.

  • LHS Cow speaking

    (Which is, admittedly, “remote” from the perspective of your computer.)

Getting a Copy on the Server

Getting your own copy of a Git repository is called cloning. Log in to the CS 70 server, and start by moving into the cs70 directory that is already waiting in your home directory:

cd ~/cs70

Everything you do for this course can live in there, which keeps your home directory from filling up with course files. Then run:

git clone https://github.com/hmc-cs70-fall2026/repo.git

That makes a directory with the same name as the repository, containing the starter files for the assignment. Change into it with cd and have a look around with ls.

  • Hedgehog speaking

    I already cloned it somewhere else!

  • LHS Cow speaking

    No harm done—it is your home directory and it still works exactly the same.

  • RHS Cow speaking

    If you would like it tidied up, mv <repository-name> ~/cs70 will move it, and then cd ~/cs70/<repository-name> to carry on.

  • Duck speaking

    It asked me for a username and password!

  • LHS Cow speaking

    Then the server hasn't been connected to GitHub yet—go back to Connecting to the CS 70 Server and run gh auth login. GitHub stopped accepting passwords for this years ago, so typing yours will not work however carefully you do it.

Editing a File

Open written-answers.md in the editor:

hx written-answers.md

Add a new line at the end of the file:

I followed the instructions in Episode 2!

then save and quit.

  • Hedgehog speaking

    I have no idea how to do any of that.

  • LHS Cow speaking

    That's expected—Helix works differently from editors you've used before, and nobody is born knowing it.

  • RHS Cow speaking

    Everything you need for this is in Surviving Helix: how to type text, how to save, and how to get out again.

  • Duck speaking

    How do I get out?! I'm stuck!

  • LHS Cow speaking

    Esc gets you out of almost anything, and then :wq saves and quits. That pair will carry you a long way.

Committing Your Change

Git does not automatically care about every change you make. You tell it what to pay attention to by staging a change, and then you record it in your repository's history by committing it.

git add written-answers.md
git commit -m "I followed the instructions in Episode 2\!"

The text after -m is the commit message: a short note to your future self and your partner about what you changed and why.

  • RHS Cow speaking

    If you don't get an error message, everything worked.

  • Rabbit speaking

    How do I check?

  • LHS Cow speaking

    git status will tell you where things stand. Straight after a commit it should say there is nothing to commit and your working tree is clean.

Your Change Is Not on GitHub Yet

Here is the part that surprises almost everybody, so it's worth doing rather than just reading.

Go and look at your repository on GitHub in a browser, and open written-answers.md. Refresh the page if you like.

Your new line is not there.

That is not a bug, and you have not done anything wrong. Committing records the change in your copy on the server. Nothing has been sent anywhere. Your repository on GitHub has no idea you did anything.

  • Duck speaking

    So what was the point of committing?

  • LHS Cow speaking

    Committing is how you build up a history: a series of small, described steps you can look back through and undo. It is for you.

  • RHS Cow speaking

    Sharing that history with GitHub—and with your partner—is a separate act, on purpose. You get to commit ten times and share once.

Pushing: Sending Your Commits to GitHub

Sending your commits to the remote repository is called pushing:

git push

Now refresh that GitHub page again. This time your line is there.

Pulling: Getting Your Partner's Work

Imagine that you and your partner have been working on your project using your server account. Then, in your next work session, your partner is the one who logs in. Their copy is out of date, so they need to collect the changes you pushed.

Getting changes from the remote repository is called pulling:

git pull

Best practice is to always pull before you start working on changes of your own. Because you and your partner are pair programming you should both know what has changed, but making sure your copy is up to date before you start is a good habit.

  • LHS Cow speaking

    For more details about Git, along with a glossary of Git and GitHub terminology, see the GitHub Help page

To Complete This Part of the Assignment…

You'll know you're done with this part of the assignment when you've done all of the following:

(When logged in, completion status appears here.)