If -source is not specified, the contents are restored from the staging area, otherwise, they’re restored from the specific tree. Git restore also makes it easier to understand where the contents you’re restoring come from with the optional -source option. Finally, if you pass both, the two are both changed to the same contents. If you pass -staged, they go into your index. If you pass -worktree (or don’t pass anything at all), the changes go into your working copy. Instead of remembering the tangled semantics of git checkout, git restore provides two options to specify where your restored changes will go. Git restore, on the other hand, makes it much easier to figure out exactly which files will change, what they’ll change to, and where they’ll change.
#GIT RESTORE HEAD HOW TO#
There are a handful of other examples in the documentation, including both more of the above as well as some examples about how to set up tracking branches, orphaned branches, and more. Or, to start from a designated commit (instead of branching off the currently checked-out commit): $ git switch -c my-new-feature 0810beaed7 Where -c is short for ( -create ) and can replace your muscle memory for git checkout -b. Switched to a new branch 'my-new-feature' If you want to replace git checkout -branch (or git checkout -b, for short), you can write: $ git switch -c my-new-feature In this mode, you can think of git switch as acting like the optionless invocation of git checkout. Your branch is up to date with 'origin/my-feature' The simplest invocation of git switch looks like this: $ git switch my-feature For our purposes, let’s take a look at each one in more detail. To that end, git switch takes care of the former, and git restore the latter. The new commands, by contrast, aim to clearly separate the responsibilities of git checkout into two narrower categories: operations which change branches and operations which change files. If you don’t want to take changes from the index, you can specify an alternative source with git checkout. If you write git checkout -, you will reset in your working copy to be equivalent with what’s in your index. If you don’t want to switch branches, don’t worry, because git checkout can change individual files, too. You can use it to change branches with git checkout or if you supply -branch, create a new branch (as in git checkout -branch ). It turns out git checkout can do quite a lot. Finally, when someone says the “checked out branch” they are referring to the branch that you tried to match the contents of in your working copy. On the other hand, when someone says “index” (or the less-frequent “staging area” or “cache”), they mean what you have git add -ed, or, what would be committed if you were to run git commit. When someone says “working copy”, they’re referring to the files in your repository as they appear on your hard drive.
Huh?īefore we specify what exactly git checkout can do, it’s worth being familiar with a few Git-specific bits of terminology-the working copy, the index, and the checked out branch. You might have seen the phrase, “switch branches or restore working tree files” and scratched your head. If you’ve tried to list out what’s possible with git checkout, you might have visited the documentation to figure it out. The new commands intend to each have a clear separation, neatly divvying up what the many responsibilities of git checkout, as we’ll show below. These two are meant to eventually provide a better interface for the well-known git checkout. Git 2.23 brings a new pair of experimental commands to the suite of existing ones: git switch and git restore. Experimental alternatives for git checkout Here’s our look at some of the most exciting features and changes introduced since Git 2.22. The open source Git project just released Git 2.23 with features and bug fixes from over 77 contributors, 26 of them new.
0 kommentar(er)
