Version Control

You will already have noticed that it’s important to be able to share code. So far, you have probably shared code to ask for help and to collaborate with others. You’ll also need to share code to turn in your work and soon, to push your code to servers which will run it. You may also have saved versions of your code before starting a new feature, so you could go back just in case.

One common definition of computer science is the study of process, and computer scientists have always been interested in using their skills to study and improve their own processes. This has resulted in excellent tools for managing and sharing changes in code. These tools are called version control systems (VCS). We will be using a version control system called git.

Key git concepts

• All the code belonging to one project is stored in a repository, or repo for short. Every one of your lab and project folders (e.g. ~/Desktop/making_with_code/pedprog/unit00/lab01) is a repo.
• A repo contains a collection of commits; each commit is a group of changes to files in the repo. (A repo doesn’t save the full contents of each version of your code because each change only affects a small portion of the code, so it would be wasteful to save the unchanged content at each version. Instead, git just saves the changes required to go from one version to another.)
• Copies of a repo can exist on multiple computers, and they can be kept in sync by sharing all of the commits.
  • When you clone a repo, you create a new copy of it on your computer.
  • When you push your repo’s commits, you send them to another computer.
  • When you pull commits, you fetch any new commits from another computer.
• Git is distributed, which means there is no main, offical version of a repo. Any copy of a repo which has all the commits is just as official as any other. This structure has political implications. For example, there is a handy tool (written in Python) called youtube-dl which lets you download videos from YouTube, Vimeo, etc. Using youtube-dl violates YouTube’s terms of service, but the software isn’t illegal in the US. Still, these companies don’t love that youtube-dl exists and they have repeatedly tried to get it removed from the Internet. But because it’s contained within a git repo, there is no single location at which youtube-dl can be taken down. Anyone who has a copy can share it with everyone else.
• A git server is a program which hosts repos and which processes other computers’ push and pull requests. We will be using a git server called GitHub, but there are many others including BitBucket, GitLab, or Gitea, which is open-source and which you could easily run from cheap little computer like a Raspberry Pi, sitting on your desk. Maybe someday schools will have git servers instead of learning management systems.

Git and MWC

In Unit 00, mwc uses git to clone lab repos. Cloning worked fine for these labs because you didn’t commit your changes and push them back to the server. If all the students committed changes to the same repo and tried to push them, it would be a mess. Now that you’ve learned about git, mwc will instead create a new repo owned by you for each future lab and project. You’ll commit your changes and push your commits, which will let Chris see your work.

For this to work, you will need to give Chris temporary access to your GitHub account. This access will expire when the class ends. If you’re an internet activist in your spare time, don’t use the same GitHub account. But you already knew that.

GitHub Setup

You already created a GitHub account as part of the initial course setup. Now you will give Chris access to your repos.

💻 Create a personal access token. Go to https://github.com/settings/tokens.

0. Select Generate new token.
1. Type “Making With Code” in the Note field.
2. Set the Expiration field to any date after the course ends.
3. Under Select scopes, check repo.
4. Click Generate token at the bottom of the page.

You will see the token, a long string of characters starting with ghp_. Anyone who has this token will have access to your account. Copy the personal access token and send it to Chris via email or a Discord DM.

Your First Commit

Workflow

Whenever you are working on a project, you will go through four steps:

• Edit files: Work on all the files in this project just like normal.
• Review changes: Look at your changes and make sure you are happy with them.
• Commit: Save your changes to the repository.
• Push: Push your copy of the repository up to github.

Edit files

💻 Go to ~/Desktop/making_with_code/pedprog/unit00/project_journal. Run ls -a1. -a is a flag which means “show me everything, even hidden files whose names start with a dot.” -1 is a flag which means “show one item per line.” You can stack flags together like -a1. You should see:

👾 💬 Do you see .gitmessage insead of .commit_template?
Oops, sorry! Run mv .gitmessage .commit_template.

💻 Open README.md in Atom: atom README.md. You are going to use this file to collect a list of the big ideas you learn in this course. You’ve already learned quite a few concepts in Unit 0’s labs; let’s add one to this document. Use your own words:

 7
 8
 9
10
11
12
13
14
15

## Cognitive (Concepts)

- **Code blocks**: A code block is just a bunch of lines of code. 
  Every Python program is a code block. Sometimes code blocks are 
  indented with a line introducing them. This affects how the 
  code block runs. For example:
  - `if x < 10:` The code block will only run when the condition is True.
  - `for x in range(10)` The code block will run ten times. Each time, the 
    variable `x` will have a different value.

👾 💬
The README is written in a language called Markdown. When you have a .md file open in Atom, you can preview the rendered version with the following menu option: Packages > Markdown Preview > Toggle Preview.

When you finish, save README.md and close it.

Review changes

git status

You will see the following message:

On branch master
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)

    modified:   README.md

no changes added to commit (use "git add" and/or "git commit -a")

👀 Read the whole message. It is telling you that only file that you have changed is README.md. That’s correct, but what changes did you make?

git diff

Now you will see a description of what you have added and what you have removed from README.md. You should always run at a minimum run git status before you add changes to your repository. To make sure you’re adding the changes you meant to add, run git diff.

If you noticed any typos, or want to add something, edit README.md in Atom again, and then run git status and git diff again.

Commit

Now it’s time to add these changes to your repository. A commit is a collection of one or more changes that belong together. For example, if you wanted to add a photo to your README document, you would need to

0. edit README.md, telling it to include the photo
1. add the image file itself to the repo.

These two changes belong together, so they should be part of the same commit. You will prepare a commit by adding all the files that have changes.

💻 Let's add your README.md to a new commit:

git add README.md

💻 Run git status again. You will see that README.md has gone from red to green because it has been added to a new commit.

On branch master
Your branch is up to date with 'origin/master'.

Changes to be committed:
(use "git reset HEAD <file>..." to unstage)

    modified:   README.md

Now we are ready to finalize the commit.

💻 Type git commit. You will see an Atom file open. If Atom does not open, check with Chris.

It’s time to describe what you did, using a commit message.

Every time you commit code, you need to write a message explaining what you have done. Anybody reading your code (teachers, peers, a future version of you) will read the log of your changes to understand what has been happening on the project.

💻 Follow the template and write your commit message. Once you finish, save and close it.

💻 Run git log to see the history of your project. You should see your commit right at the top.

Push

Now it’s time to sync the copy of your repo with the copy on github.

💻 Type git push.

You should see something below in Terminal. If you do not, check with Chris.

Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 302 bytes | 302.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
To https://github.com/the-isf-academy/cs9-donows-YOUR-GITHUB-USERNAME
   67838f1..4742ecf  main -> main

💻 Go to your repository page on Github.com. You should see your updated version of your README.md at the bottom of the page.

🎉 Congratulations! You have successfully made your fist push to Github! 🎉

This probably felt like a lot of work just to save your work. That’s true. But it will get easier as you get used to it, and you will start to see the value of using git when you start working on bigger projects.

If you’re not glad you learned git five years from now, come see us and we’ll give you some extra credit or something :)

Summary: Github Commands