Commits

Commits are incremantal snapshots of your code base.

Every time you reach a point in your project where you want to capture the exact state of your files—whether you’ve added a new feature, fixed a typo, or reorganized folders—you create a commit. Think of a commit as a labeled snapshot in time: it records exactly which files have changed, when they changed, and why. Behind the scenes, Git stores these snapshots in a way that makes it easy to revisit any moment in your project’s history, compare different versions, or even roll back to a previous state if you discover a mistake later on.

Before you can make a commit, you need to tell Git which changes you want to include. This is done in two steps. First, you stage your changes by using the git add command. Staging is like assembling the ingredients for a recipe—you decide exactly which modified or new files should go into your next snapshot. You might stage everything in one go with git add . (the dot means “everything”), or you can stage files one by one, for instance git add index.html to include only that file. Once you’ve reviewed what’s staged and feel confident it represents a coherent set of updates, you’re ready to commit.

The second step is creating the commit itself with git commit. When you run git commit -m "Your message here", Git takes the staged changes, bundles them into a snapshot, and stores them in your repository’s history. The message you include in quotes should briefly describe what you’ve done, so that later on—when you or someone else looks at the project’s history—it’s clear why that snapshot was made. A good commit message might say “Add user login form” or “Fix typo in README,” whereas a vague message like “stuff” can cause confusion down the road.

By repeating this cycle of staging and committing each time you reach a meaningful checkpoint, you build up a clear, navigable timeline of your project. You’ll be able to see exactly when a particular feature was introduced, what changes accompanied a bug fix, and how the project evolved over time. Commits turn your work into a living history that you can explore, share, and revert to at any moment—transforming the way you organize and collaborate on projects forever.

Pushing Your Commits

After you’ve captured your work in commits on your own computer, the next step is to share those changes with the remote repository on GitHub. This process is called “pushing.” When you push, Git takes all the commits that exist only in your local repository and sends them up to the server, so anyone else (or you, from another computer) can see and build on your progress.

To push for the very first time, you typically use a command like git push -u origin main. Here, origin is the nickname Git gives to the remote repository you set up earlier, and main is the name of the branch you’re working on (older tutorials might call this branch master, but main is the current convention). The -u flag tells Git to remember that in the future, whenever you run git push without any arguments, it should push the main branch to origin by default. After that initial push, you can simply type git push and Git will know exactly where to send your commits.

When you push again, Git looks at your local branch and the matching remote branch to see which commits you already have on the server and which ones you don’t. It then transfers only the new commits, keeping your online repository up to date without duplicating work that’s already there. If someone else has pushed changes to the remote in the meantime, Git may refuse to push until you’ve brought those updates into your local branch. In that case, you use git pull to fetch and merge (or rebase) the remote commits, resolve any conflicts if they arise, and then try pushing once more. This simple cycle of commit, push, pull, and resolve is what keeps everyone’s work synchronized and prevents accidental overwrites.

By regularly pushing your commits, you ensure that your work is safely backed up on GitHub and visible to collaborators. It also makes it easy to switch between different computers—simply clone or pull the repository on a second machine, and you’ll instantly have your latest commits ready to continue. Over time, pushing becomes second nature, and it forms the backbone of a smooth, collaborative workflow.

Pulling Updates from Remote

Imagine one of your classmates has added a new chapter or fixed a typo and then pushed those changes to GitHub. To get those updates onto your own computer, you use the git pull command. When you run git pull origin main, Git reaches out to the remote repository you named “origin,” looks at the branch called “main,” and fetches any commits there that you don’t yet have. It then automatically merges those commits into your local copy of the main branch, so your files and history stay in sync with everyone else’s work.

Under the hood, git pull actually performs two steps in one: it first does a git fetch, which downloads new commits from the remote repository into your local “remote-tracking” branches (for example, origin/main). Then it runs a git merge to incorporate those fetched commits into your current branch. In most cases this merge happens cleanly and you’ll see a short message confirming which commits were added. If two people modified different parts of the same file, Git can merge them smoothly without you needing to do anything extra.

Sometimes you may prefer to see what’s coming in before merging, especially if you’re juggling many updates or want to review changes first. In that case, you can run git fetch origin by itself. This will download the new commits and store them in origin/main, but it won’t touch your local files or branch. You can then look at those incoming changes, for example with git log origin/main or by comparing files, and decide when and how to merge them. When you’re ready, you merge manually with git merge origin/main. This two-step process gives you more control, but for most day-to-day work, a simple git pull keeps things quick and synchronized.

By regularly pulling in changes from others, you make sure that your work always builds on the most recent state of the project. This habit greatly reduces the chance of running into unexpected conflicts later, since you’re integrating small batches of updates frequently rather than a large backlog all at once. With git pull as part of your routine—just like committing and pushing—you’ll enjoy a smooth, up-to-date view of your team’s collaborative progress.

Cloning an Existing Repository

Sometimes you’ll want to start working on a project that already lives on GitHub or another hosting service—perhaps a class assignment template, an open-source library, or even a teammate’s repository. Instead of creating a new folder and manually copying files, Git provides a single command to download the entire project history and set up everything you need. This command is git clone.

When you run git clone followed by the repository’s URL—something like https://github.com/your-organization/project-template.git—Git creates a new folder (by default, named after the repository) and populates it with all the files, folders, and hidden Git metadata the project contains. That hidden .git folder includes every commit and branch in the project’s history, so once the clone finishes, you don’t just have the latest version of the files—you have the full timeline of how the project has evolved. Git also automatically sets up a remote called origin that points back to the repository you cloned from, and it establishes your local main branch to track the remote’s main branch. This means you can immediately run git pull to grab new changes or git push to publish your own work (assuming you have permission).

Under the hood, cloning is equivalent to doing a fresh git init, adding the remote, fetching all the data, and then checking out the default branch in one seamless step. Once you’ve cloned, you simply cd into the new folder, and you’re ready to explore, edit, and extend the project. Because you have every past commit, you can even jump back in time to inspect earlier versions or create branches of your own. Cloning is the fastest, cleanest way to get a full local copy of any Git repository—making it the gateway to collaborating on existing work and building on the efforts of others.