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 into Android Studio.

Your regular workflow:

1. Edit: Make changes to your code using Claude Code in the Android Studio terminal
2. Commit: Save snapshots of your work to Git (do this often!)
3. Push: Upload your commits to GitHub—this saves your Claude Code session logs along with your code

Your Claude Code session transcripts are automatically saved to your repository with each commit. These logs are how we track your progress, 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. Regardless of whether you save your files in Android Studio or any other way, 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 save your session logs, 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 two powerful interfaces: Android Studio and Claude Code. Let’s walk through the workflow.

Cloning Your Project Repository

Cloning Your Project Repository

To begin the independent project you will clone your Git repository from GitHub. That repository contains your PLAN.md, a CLAUDE.md configuration file, and session tracking hooks. You and Claude will set up your Android project from there. Cloning a Git repository on GitHub makes a copy of it on your local machine.

It is straightforward to open an existing GitHub repository in Android Studio. Simply choose “Get from VCS” (or “Clone Git Repository”) from the Android Studio welcome screen or File menu.

Paste the repository URL that you obtain when you click the “Code” button on the GitHub page for your project. If you have not yet added your GitHub credentials to Android Studio, it will ask you to do that. At that point Android Studio will download the repository from GitHub to your local machine and you can begin working.

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.

You can ask Claude Code to commit for you (try “please commit my work”), or use the Git integration in Android Studio.

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. Your Claude Code session transcripts are included automatically with each push.

You should push regularly—at minimum, at the end of every work session. You can ask Claude to do this for you (try “please commit and push my work”), or use the Git integration in Android Studio by selecting “Push” under the “Git” menu.

Working on Multiple Machines

Working on Multiple Machines

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.

When switching to a different machine:

1. On your first machine: Make sure you’ve committed and pushed all your changes to GitHub
2. On your second machine: Clone your repository from GitHub (one-time setup) or pull the latest changes if you’ve already cloned it
3. Work on your second machine: Edit, commit, and push as usual
4. Back on your first machine: Pull the latest changes from GitHub 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.

To pull changes in Android Studio, select “Pull” from the “Git” menu. This will download any commits from GitHub that you don’t have locally.

Troubleshooting

Troubleshooting

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

1. Your changes aren’t on GitHub. This is a common mistake. You committed your work, but didn’t push it to GitHub. Try pushing again by selecting “Push” under the “Git” menu in Android Studio, or ask Claude to push for you.
2. 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.
3. 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.