You can see what’s in there in many ways, for instance through the plumbing command git ls-files -stage, which displays it as a tree (it is a tree, Git-wise): $ git ls-files -stageġ00644 48b9bcc9bd336a09a18c06cb1d4f10d6758e0116 0. The index name is most apparent in the name of the technical file that holds its current list of known files and trees. This area is known by many names: index (mostly in technical docs of Git), stage, staging area, staged files, cache (hence the legacy -cached options to commands such as git diff and git rm)… We favor stage. You add stuff to the stage through the git add command. This truly is the staging area for your next commit: this is where you put snapshots of whatever parts of your ongoing work you’re greenlighting for the next commit. git directory, as a result of having called git init there. It is the complete set of directories, subdirectories and files you’re working with for a particular project, at the root of which you normally have your. There are two other areas (the stash, and the remote) but they’re largely irrelevant to the current discussion. Git manages your work through 3 major local areas: This article focuses on that “local work.” As a complement to what we’re explaining here, we recommend this great interactive cheat sheet. This is great for performance, but not just for that. You probably already know that one of Git’s leading benefits is that your work is mostly local: a Git repo has its own local lifecycle, independent of its remote counterpart. Be careful with this option though, because if you have indexed work that you want to keep, Git will scrap that work without asking for confirmation. However, if you encounter an error with the -keep option, usually when there are conflicting files, you can try to use the -merge option instead. This way, should things go awry, Git will be able to come back to the position before that by doing a git reset -keep ORIG_HEAD. ORIG_HEAD backs up the position of HEAD before a potentially dangerous operation ( merge, rebase, etc.). It’s related to HEAD, but always contains a raw SHA-1 instead of a named reference. git directory, you might have seen a file named ORIG_HEAD. Actually, whenever we have an active branch (which is by far the most common use case), the branch itself is repositioned, and HEAD just follows along. Using git reset we move HEAD around as we see fit. Such a file then contains the commit’s metadata and tree information, which we can introspect using the plumbing command git cat-file: $ git cat-file -p HEAD git/refs/heads/master contains its tip commit’s SHA-1. Technically it’s just a text file stored in. But we can move it around to any reference or raw SHA-1. It’s a bit like our shadow: it follows us everywhere we go!īy default, HEAD references the current branch, e.g. It states which commit we’re working on top of. HEAD is a pointer, a reference to our current position in terms of history. If you’re curious, Pro Git has a great section on this. This is really just a checksum of the commit’s tree and other metadata. In reset’s context, we mostly care about commits. In Git’s context, a SHA-1 is a technical reference for an object in the Git database. what the mechanisms are to browse / traverse our branches and versions.how that works gets archived in our history.Resetting lets us tweak our version history and ongoing work. If you think you’re solid there, just scroll down to the “So what about Git reset?” heading. So this piece will start by revising a number of Git fundamentals. In order to best use git reset, you must understand its context. This is too bad, as it opens up a wide range of solutions and tips to optimize our work and workflows. The git reset command is a formidable tool unfortunately far too often misunderstood or poorly used. Last updated on November 3, 2022, 10:03am
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |