Using Git and GitHub

Git is a source code version control system (VCS), also known as version control. GitHub is a website providing Git repository hosting and an attractive and powerful Git web interface. It’s important to understand the difference: Git is the version control system that runs on your computer, while GitHub is a website that provides a nice user interface to Git and hosts your repositories online. Think of Git as the engine and GitHub as the dashboard you use to view and manage your code online. There is only one Git, but there are other GitHub-like Git hosting services: GitLab, Gitea, and so on.

Workflow Summary

Workflow Summary

One-time setup: Clone your project repository from GitHub using Claude in the Code tab of the Claude desktop app, then start your project sessions in the cloned folder.

Your regular workflow:

1. Edit: Make changes to your code by working with Claude in a session started in your project folder
2. Commit: Save snapshots of your work to Git (do this often!)
3. Push: Upload your commits to GitHub—this saves your code and a backup copy of your Claude Code session transcripts

Your Claude Code activity itself is reported live as you work, so pushing is not what makes your time count. But pushing is what saves your code, and it keeps a backup transcript of each session in .claude-sessions/, so commit and push regularly.

Why Use Source Version Control?

Why Use Source Version Control?

A source code repository might seem a bit like the shared folders that are provided by services like Dropbox, Box, or Google Drive. You can save files and folders and share them with other users in various ways. Some of these tools even allow you to track, undo and redo changes, and see how files have changed over time. These are useful tools, and a great way to collaborate with others in a variety of different scenarios. So it’s normal to wonder: what’s different about source version control?

Compared to tools like Dropbox, source version control provides programmers with several important advantages.

Versioning Entire Projects

Versioning Entire Projects

First, version control systems track the version of all the files in each repository, rather than individual files separately. Programming frequently involves making a set of changes to a group of files that together accomplish something—like fixing a bug or adding a new feature. So when you commit your work using Git, it remembers the state of all the files in your repository at that time. This allows you to compare what your project looked like at different times, and undo an entire set of changes that might have caused a problem.

Note that this also means that Git does not track all the changes you save to a file. Unless you commit your changes, they are not saved to your repository. This may seem like an annoyance—after all, systems like Dropbox will sync your files every time you save them.

But when programming this turns out to be a huge advantage. Let’s say you save a version of Foo.java to test—but it contains errors. Now if you are using Dropbox, everyone has that broken version of the file. But if you are using Git, you can test your code, notice the errors, and fix them before committing.

A Git commit is really the equivalent of the save operation. However you save your files, you have to commit them to your repository before Git will save and remember them.

Commit Message

Commit Message

Version control systems also allow you to add your own notes to each commit. This is called a commit message. Commit messages should summarize what changes are included in the new version of the project. Good commit messages are extremely helpful to other developers that are trying to understand how the code is evolving. All version control systems have ways to view the list of versions with their commit messages. This can be useful when you want to see how things have changed, or back up and use an older version of a project where some feature was working that isn’t any more.

Merging Changes

Merging Changes

Second, version control systems help you merge changes made concurrently by different developers—even to the same file. Say that Foo.java has 1000 lines. Alice makes a change at the top of the file. Concurrently, Bob makes a change to the bottom of the file. Systems like Dropbox will typically force you to address this conflict by choosing either Alice’s version of the file or Bob’s. But version control systems can frequently automatically merge non-overlapping changes to source code files—allowing you to choose to combine the changes from Alice with the changes from Bob. When you are working in large teams on large software projects, this capability is extremely handy.

Introduction to Git and GitHub

Introduction to Git and GitHub

Basic Principles

Basic Principles

Git organizes your files into a repository. A repository can contain any number of files organized any way you like. A single repository usually contains all of the code used by a single project. For CS 124, you will use a single repository for the independent project.

Git stores a copy of your repository on your local machine. But to back up your work and keep a backup copy of your session transcripts, you are going to push your changes to the GitHub Git hosting service.

Workflow Details

Workflow Details

Almost all of your interaction with Git this semester will be through Claude. You ask, and Claude runs the Git commands for you. Let’s walk through the workflow.

Cloning Your Project Repository

Cloning Your Project Repository

To begin the independent project you will clone your project repository from GitHub, which makes a copy of it on your laptop. Your repository starts with a CLAUDE.md file that tells Claude about your project, and the hooks that report your Claude Code activity and save session transcripts. You and Claude will set up the rest of your app from there.

First create your repository on the MP page, and accept the GitHub invitation it sends you. Then, in the Claude desktop app:

1. Make a folder for CS 124, for example a folder called CS 124 in your Documents folder.
2. Start a session in it. In the Code tab, click + New session, choose Local, then Select folder, and pick the folder you just made.
3. Ask Claude to clone your repository. Copy your repository’s address from the MP page and paste it into a prompt such as: “Please clone this repository into this folder. If Git isn’t installed, install it first.”
4. Sign in to GitHub when asked. See below.

There is no button for cloning a repository by its address: the clone happens in that conversation. When it finishes, you have a new folder named after your repository inside your CS 124 folder.

Signing In to GitHub

Signing In to GitHub

Your repository is private, so the first time Git talks to GitHub it needs to know who you are.

• On Windows, Git opens a browser window the first time and asks you to sign in to GitHub. Sign in and approve the request.
• On macOS and Linux, Git asks in the conversation or the terminal for a username and a password. The username is your GitHub username. The password is not your GitHub password: it is a classic personal access token with the repo scope, which you create on GitHub’s token page. Ask Claude to walk you through creating one if you get stuck.

Set the token’s expiration to the end of the semester; a token that expires in 30 days will do so at the worst possible time.

Start Project Sessions in the Cloned Folder

Start Project Sessions in the Cloned Folder

The session you cloned from was started in the CS 124 folder, which is the parent of your project. That session is not reported, and that is expected.

For all of your project work, start a new session in the cloned folder: the one containing CLAUDE.md, not the folder above it. Click + New session, choose Local, then Select folder, and pick your repository’s folder. If Claude asks whether you trust the files in this folder, answer yes. Your project’s hooks only run in sessions started in that folder, and they are what make your hours count; see Effort Logging.

Committing (Saving) Your Work

Committing (Saving) Your Work

Version control systems only save the change you have made when you tell them to. This is called a commit, and the process called committing.

Once you commit a version of a file, Git will remember its committed contents forever—even if you change or delete the file. So you should get into the habit of committing early and often. Here are some good times to commit your code:

• You just started a project—make sure to record it in its initial state!
• You just finished writing a function—that way you can always get back to that version if you make changes later.
• You just got a feature working—make sure that Git remembers what worked forever!
• You are about to take a break or go to bed.
• You are done with a work session.

Get in the habit now of committing your code regularly. Version control systems are very efficient at storing commits, and so the overhead of performing them is small. Better to have things saved than to want desperately to get back to a previous version or remember how you did something and not have it committed.

The easiest way to commit is to ask Claude (try “please commit my work”). You can also run Git yourself in the terminal pane of the Code tab, which you open with Ctrl+`.

Pushing Your Work

Pushing Your Work

You save your work to GitHub by pushing your commits. Pushing uploads your committed changes to GitHub, where they are safely backed up. A backup copy of your Claude Code session transcripts is included automatically with each push. Your Claude Code activity itself is reported live as you work, whether or not you push.

You should push regularly—at minimum, at the end of every work session. Ask Claude to do this for you (try “please commit and push my work”), or run git push in the terminal pane.

Working on a Second Machine

Working on a Second Machine

If you want to work on your project on different computers (like a laptop and a desktop), Git makes this easy. The key is to use push and pull to keep your work synchronized through GitHub.

1. On your first machine: Make sure you’ve committed and pushed all your changes to GitHub
2. On your second machine: Install the Claude desktop app and clone your repository the same way (one-time setup), or ask Claude to pull the latest changes if you’ve already cloned it
3. Work on your second machine: Start your sessions in the cloned folder, and commit and push as usual
4. Back on your first machine: Ask Claude to pull the latest changes before continuing work

The golden rule: Always pull before you start working, and always push when you’re done. This ensures you’re working with the latest version of your code and that your changes are backed up on GitHub.

Troubleshooting

Troubleshooting

If something seems wrong with your repository, here are common problems:

1. You opened the wrong folder. If your session is in the CS 124 folder, or anywhere other than the folder containing CLAUDE.md, it is not reported. Start a new session and select your repository’s folder; see above.
2. Your changes aren’t on GitHub. This is a common mistake. You committed your work, but didn’t push it to GitHub. Ask Claude to push for you, or run git push in the terminal pane.
3. Git keeps asking for a password, or rejects it. On macOS and Linux the password is a personal access token, not your GitHub password, and it may have expired. Ask Claude to help you create a new one; see above.
4. You’re pushing to the wrong repository. You should be pushing to a repository in the cs124-illinois-students organization. If you’ve somehow created another repository on GitHub, remove it immediately once you’ve pushed to the correct repository. It can put you at serious risk for committing an academic integrity violation.
5. You have merge conflicts. This can happen if you worked on two different machines without pulling first. Ask Claude to help you resolve the conflicts, or ask for help on the forum.

Git Resources

Git Resources

Want to learn more about Git? Here are some excellent resources:

• Pro Git Book: The comprehensive, free Git reference book
• GitHub Git Guides: Official GitHub guides covering Git basics
• Atlassian Git Tutorials: Clear, practical Git tutorials

And feel free to ask questions on the forum.