That area is your working tree or work-tree. We copy the files out of the commit, into a work area. Git's answer is the same as the answer is other version control systems: sure, the commits are read-only forever, but you don't do work with the committed files. 2 But this leaves us with a dilemma: if no part of any commit can ever change, how can we get any new work done? That's how Git finds the previous commit, so that it can show you what changed.Īll of this stuff inside the commit is completely, totally, 100% read-only: no part of any commit can ever be changed once it's made. Most commits just store one such hash ID, which is the 'parent' of the commit. And, crucially for Git's internal operation-though we won't cover any of the details here-each commit stores a list of previous commit hash IDs. It includes a log message, which git log or git show will show before any diffs. This includes things like the name and email address of the author of the commit (from user.name and user.email). Commits don't store changes, so when Git shows you changes, it's really doing a git diff of two snapshots.Ī commit also stores some metadata, or information about the commit itself. These appear random, though in fact they're entirely non-random.Ī commit has a full snapshot of every file. Each commit has a big, ugly, incomprehensible hash ID number such as e9e5ba39a78c8f5057262d49e261b42a8660d5b9 (often abbreviated, e.g., e9e5ba3). What you do with this repository is add more commits. Read only if the above still doesn't make sense: If this stuff still doesn't come together, you're probably missing out on a key concept in Git: how the index / staging-area really works.Ī Git repository is, to a large extent, just a big database of commits. I kind of wish that these had not been left in the git switch command, but they were. So git checkout -m is always 'dangerous' in the git restore way: it will wipe out uncommitted work without asking. The first operation cheerfully destroys any merge work you started in the working tree copy of the file. When switching branches with -merge, staged changes may be lost.

This second operation is somewhat dangerous: as the documentation now notes,

does a merge operation during a checkout, as if you ran a rather complicated series of Git commands that ends up with you on the target branch, having then merged against the uncommitted code in your working tree.This option applies only to the 'restore files' mode of git checkout (where it is now documented, but it's not clear that it only applies to this mode!). The git restore command also documents the -overlay vs -no-overlay modes properly. This writes to both staging-area and working-tree (because both -S and -W are given).īy contrast, git checkout - file makes the source less obvious (it's the same as it is in git restore, but less obvious) and gives you no choice of target(s) (always -W, but -S gets added if the source is a commit or tree). Or, add -S and/or -W to write to the staging area (index) with -S, and/or working tree with -W: git restore -source 11cb5b6 -SW - hello.txt You specify the -source for the file, or let it default to using the index: git restore -source 11cb5b6 - hello.txt If you have Git 2.23 or later, use git restore to do this: its operation is less confusing and more direct. This is not possible with git checkout: git checkout always writes to the working tree, and also writes to the index/staging-area if you specify a commit or tree object as the source of the file to be written to the working tree. When using git restore instead of git checkout, you control which of the index/staging-area and working-tree files are updated, using the -S (staging area) and -W (working tree) options.

write to your index / staging-area (sometimes).write to your working tree (always) and.You're using the 'restore files' mode of git checkout and, as shrey deshwal noted, this operation will: This still doesn't mention several additional modes of operation ( git checkout -m for instance), 1 but at least separates out all the 'restore files' options, of which there are many. git restore, which does the 'update some files in index and/or working tree' operation.git switch, which does the 'select other branch or commit to have checked out' operation and.It's so complicated that someone finally, as of Git 2.23, split it into two separate commands: The git checkout command is very complicated.

Git checkout