Maybe drop one file but leave the other 99 there. You use -soft when you want to tweak something. It was wrong, and it would be best if no-one sees it again (don't look in the reflog!). You use -hard when you just want to get rid of that embarrassing commit. Of what's left, soft will change nothing, hard will change all, and mixed will change the index but not the worktree. Soft | Mixed | HardĪs previously said, git reset will always change the repo. In this visualisation, commit B is where are before running git reset -flag A. What happens to the index and worktree is determined by the -soft/-mixed(default)/-hard flags. It moves the branch pointer from one commit to another. The last is the worktree which is what changes when you edit files. One is the index which is what would be committed if git commit were run. One is the repo itself, that is what has been committed. It's a bit confusing, I know, but hopefully this explanation will help someone.įor each checked-out repository, you have three trees. Personally I only use hard and mixed (omitting the switch) and add the files myself if needed. This will effectively make your files "staged" with the content they had in the previous HEAD, ready to be committed. Soft will leave the staging area intact (which will likely be in the same state as your working tree), which will now differ from the new HEAD. Since your working tree will now differ from the staging area, and the staging area equals the new HEAD, your files will effectively be "unstaged" (eg. Mixed (the default) will copy the files from the destination commit to the "staging area" (aka. The difference between soft and mixed is whether your current files will appear as "staged" (aka. The staging area will be overwritten too, so there will be no new chages to commit afterwards. All files in your working tree will be overwritten with what's in the commit you're moving to. You can think of -hard being like moving your HEAD to a new commit, followed by a checkout. The switches determine what will happen with the working tree (your actual files) and staging area. It can be easier than amending or interactively rebasing.Reset simply moves your current branch (HEAD) to a specified commit. If I realize I committed a file I shouldn't have, I do a soft reset and then redo the commit properly. More generally, git reset -soft HEAD^ is great for undoing non-pushed commits. Just remember not to share the branch with a WiP commit or someone else may build upon it and object when you rewrite history. This will leave the working tree in the WiP state, but roll back the current HEAD one commit, as though you never made that commit. When I get back to a branch, find that the last commit is "WiP" and want to restore my previous state, I do git reset -soft HEAD^ (Idea: make the shell prompt indicate stash.) Instead, when I have work in progress, I just commit it as usual, with something like "WiP" as the message: git commit -a -m "WiP" However, I dislike having to remember I have something stashed. With Git, if you have some work in progress and find you need to switch to another incompatible branch, you can git stash the changes and later restore them with git stash pop.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |