Chapters
Chapters

Chapters

Hide chapters

Git Apprentice

Third Edition · git 2.39 · Console

Before You Begin

Section 0: 6 chapters
Show chapters Hide chapters

Section I: Beginning Git

Section 1: 11 chapters
Show chapters Hide chapters

Section II: Appendices

Section 2: 1 chapter
Show chapters Hide chapters

4. The Staging Area
Written by Bhagat Singh

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

Heads up... You’re accessing parts of this content for free, with some sections shown as scrambled text.

Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now

In previous chapters, you’ve gained some knowledge of the staging area of Git: You’ve learned how to stage modifications to your files, stage the addition of new files to the repository, view diffs between your working tree and the staging area, and you even got a little taste of how git log works.

But there’s more to the staging area than just those few operations. At this point, you may be wondering why the staging area is necessary. “Why can’t you just push all of your current updates to the repository directly?”, you may ask. It’s a good question, but there are issues with that linear approach; Git was actually designed to solve some of the common issues with direct-commit history that exist under other version control systems.

In this chapter, you’ll learn a bit more about how the staging area of Git works, why it’s necessary, how to undo changes you’ve made to the staging area, how to move and delete files in your repository, and more.

Why staging exists

Development is a messy process. What, in theory, should be a linear, cumulative construction of functionality in code, is more often than not a series of intertwining, non-linear threads of dead-end code, partly finished features, stubbed-out tests, collections of // TODO: comments in the code, and other things that are inherent to a human-driven and largely hand-crafted process.

It’s noble to think that that you’ll work on just one feature or bug at a time; that your working tree will only ever be populated with clean, fully documented code; that you’ll never have unnecessary files cluttering up your working tree; that the configuration of your development environment will always be in perfect sync with the rest of your team; and that you won’t follow any rabbit trails (or create a few of your own) while you’re investigating a bug.

Git was built to compensate for this messy, non-linear approach to development. It’s possible to work on lots of things at once, and selectively choose what you want to stage and commit to the repository. The general philosophy is that a commit should be a logical collection of changes that make sense as a unit — not just “the latest collection of things I updated that may or may not be related.”

A simple staging example

In the example below, I’m working on a website, and I want my design guru to review my CSS changes. I’ve changed the following files in the course of my work:

Undoing staged changes

It’s quite common that you’ll change your mind about a particular set of staged changes, or you might even use something like git add . and then realize that there was something in there you didn’t quite want to stage.

git reset

Execute the following command to remove the change to books/management_book_ideas.md from the staging area:

Moving files in Git

Create the folder for the website ideas with the following command:

Deleting files in Git

The impulse to just delete/move/rename files as you’d normally do on your filesystem is usually what puts Git into a tizzy, and it causes people to say they don’t “get” Git. But if you take the time to instruct Git on what to do, it usually takes care of things quite nicely for you.

Restoring deleted files

First, you need to get back to where you were. Unstage the change to the live streaming ideas file with your best new friend, git reset:

Challenge

Challenge: Move, delete and restore a file

This challenge takes you through the paces of what you just learned. You’ll need to do the following:

Key points

  • The staging area lets you construct your next commit in a logical, structure fashion.
  • git reset HEAD <filename> lets you restore your staging environment to the last commit state.
  • Moving files around and deleting them from the filesystem, without notifying Git, will cause you grief.
  • git mv moves files around and stages the change, all in one action.
  • git rm removes files from your repository and stages the change, again, in one action.
  • Restore deleted and staged files with git reset HEAD <filename> followed by git checkout HEAD <filename>

Where to go from here?

That was quite a ride! You’ve gotten deeper into understanding how Git sees the world; building up a parallel mental model will help you out immensely as you use Git more in your daily workflow.

3. Committing Your Changes
5. Ignoring Files in Git
Have a technical question? Want to report a bug? You can ask questions and report bugs to the book authors in our official book forum here.
© 2026 Kodeco Inc.

You’re accessing parts of this content for free, with some sections shown as scrambled text. Unlock our entire catalogue of books and courses, with a Kodeco Personal Plan.

Unlock now