Git

• Git is a version control system.
  • Let’s you save “snapshots” of your code as you write it so you can go back and look at older versions when necessary (e.g., when you decide it’s a good idea to try writing code at 3:30 a.m. on a Sunday morning)
• Your local repository is typically backed by a remote repository.
• The remote repository (often GitHub.com):
  • provides a backup of your code in case your hard disk crashes
  • Gives others (i.e., me) easy access to your code
    • This is especially helpful in an online teaching environment: If you are having trouble, just push your code to the remote repository so I can see what you’re doing.
    • It is also a much easier way to submit code than trying to zip it up and email or use BB Assignment manager.
  • Makes it easy for teams to work on the same project.
    • This doesn’t really apply to 163; but, it will be essential in later courses.
  • Also makes it easy to move your code from one machine to another (e.g., laptop to desktop, or EOS to home)
    • Much better than trying to use a USB drive to move files. (Much less error prone)

GitHub and GitHub classroom

• GitHub.com is a web site that hosts remote git repositories.
• Many projects store their code on GitHub so users can access it
  • and even work on and improve it.
• Show a few git repositories (e.g., JUnit)
• Your assignments will be posted as GitHub repositories that you clone and work on — but with a twist:
• First, let’s look at a simple workflow that almost (but doesn’t quite work)
  1. I post an assignment as a GitHub repository containing starter code and instructions.
  2. You clone the repository (i.e., make a local copy)
  3. Complete the assignment by working on the local copy.
  4. Commit your changes and push them back to the remote repository.
  5. I look at the remote repository and grade your project.
• Problem: If you all clone the same repo, your commits will all get merged together.
  • We need a separate repository for each student.
• GitHub Classroom adds this extra step (making a separate copy for each student.)

Public/private keys

• A public/private key pair is a set of numbers that lets you encrypt and decrypt messages.
• This process works in both directions
  1. “Hello, World” -> public key -> “axquweouxw” -> private key -> “Hello World”
  2. “Coffee is gross -> private key -> “mbnjgurjda” -> public key -> “Coffee is gross”.
• The private key must be kept private.
  • Only you should have access to it.
  • If somebody else gets it, that’s bad.
  • Like if somebody suddenly knew all of your passwords.
• The public key is designed to share with everybody.
• Case 1 lets someone send you a message that only you can read.
  • For example, send email securely.
• Case 2 lets you send someone a message in a way that they know for sure it came from you.
• You can use case 2 to avoid having to type passwords all the time.
  • You give a server your public key.
  • You write a message “It’s Fred. Let me in” and encrypt it with your private key.
  • The server uses your public key to decrypt it.
  • If the message didn’t come from you, then attempts to decrypt it will result in gibberish.
  • Thus, some programs (including git) will automatically encrypt a message using your private key instead of asking you to type in a password.

Generating and using keypairs

• Go to the command line (Terminal in mac; Git Bash or WSL in Windows; or, just use EOS)
• run ssh-keygen -t rsa
• accept the defaults.
  • Except, you may want to add a passphrase. It’s up to you.
• Now, look in the directory named ~/.ssh (notice the .)
  • You should see files named id_rsa and id_rsa.pub
  • id_rsa is your private key. Make sure it stays private. Think of it as a password. If it gets out, it’s like an attacker having the passwords to all your accounts.
  • id_rsa.pub is your public key. It is meant to be shared.
  • Open id_rsa.pub: It is just a text file.
• Add your public key to your GitHub account.
  • Log into your GitHub account.
  • Click on your avatar in the upper right corner.
  • Select “Settings”
  • Select “SSH and GPG keys”
  • Cut-and-paste the text of id_rsa.pub into the form.
  • Submit and enter your password.

Setting up your first assignment

• Log into your GitHub account.
• Click on the assignment’s GitHub Classroom link.
  • For Summer 2020, its https://classroom.github.com/a/gw-Ues5y
• Following the link will create a new repository for you to use (separate from everybody elses)
• When the process is complete, you will see a link to your personal repository for the project. Follow that link.

Basic Git Usage

• Go to a github repository (e.g., the repository for one of your assignments)
• Click the “Clone or Download” button.
  • Notice that you can either “Clone with HTTPS” or “Clone with SSH”.
  • If you “clone with HTTPS”, you will need to enter your username and password every time you access the repository.
    • This is very annoying (and discourages good git practice)
  • If you “clone with SSH”, git will use your ssh key and you won’t have to put in your username/password
    • much nicer.

Clone

• Copy the SSH URL from the “Clone or Download” dialog box.
• Go to the terminal.
• Navigate to the directory you intend to use for your git projects for 163.
• run git clone *the_url_you_copied*
• This will create a new directory with the contents of the git repository.
• When getting code from GitHub, be sure to use the git clone command. Do not use the web interface to download the files. Doing so will cause problems later. (Git is not Dropbox.)

Review classes / Objects and instance vs. static. Then switch to testing.

Add / Commit / Push

• Every so often as you are working on your project, be sure to commit your changes.
• Committing your changes is what allows you to
  • Look back at old versions / revert to old versions
  • Save your code in the cloud
  • Move your code from one machine to another
  • Make your code available for me to look at.
• Pushing your changes to the cloud is actually a three-step process:
  1. From the root directory of your project, run git add . (notice the final .)
  2. Run git commit -m '*your_message_here*'.
     • The message is important so you can tell what was done at each step.
     • You can also use the message to tell me when your code is ready for grading.
  3. Run git push. This is the command that actually pushes the code back to the cloud.
     • The first time your run git push on a branch, you will be asked to set up a “remote” branch. Just follow the instructions.

Pull

• If changes are made to your repository outside of your local copy (e.g., if a teammate makes changes on his own machine) then you will need to run git pull
• Running git pull will bring any remote changes to your machine and merge them with your code.
• Most of the time, git can quietly merge the changes together.
• Occasionally, there may be a merge conflict.
  • Merge conflicts should only happen if two people are working on the same part of the code at the same time.
  • If one happens, you will have to open the file and resolve the conflict by hand.
  • You will see comments showing the “old” and “new” versions. Just pick the version you want.
  • I’m happy to help the first time this happens.
• You will need to commit your changes before you can run git pull.

Other actions

• Git is very powerful and provides a lot of actions and options. In 163, we will only use clone, add/commit/push, and pull.
• The other major git feature is using branches. But, since branches are most useful for team projects, I won’t discuss them now.
• Feel free to learn about and use other features.