Getting back in synch after a pushed rebase is really not that complicated in most cases. git checkout foo git branch old-foo origin/foo # BEFORE fetching!! git fetch git rebase –onto origin/foo old-foo foo git branch -D old-foo Ie. first you set up a bookmark for where the remote branch originally was, then you use … Read more
Rebase or revert are the options. Rebase will actually remove the commit from the history so it will look like that second commit never existed. This will be a problem if you’ve pushed the master branch out to any other repos. If you try to push after a rebase in this case, git will give … Read more
git reset does know five “modes”: soft, mixed, hard, merge and keep. I will start with the first three, since these are the modes you’ll usually encounter. After that you’ll find a nice little a bonus, so stay tuned. Let’s assume you have a repository with a history akin to this: 7e05a95 (HEAD -> main) … Read more
You should be able to recover any files back that you added to the index (e.g, as in your situation, with git add .) although it might be a bit of work. In order to add a file to the index, git adds it to the object database, which means it can be recovered so … Read more
After a git reset, this one-liner can do it: git commit –reuse-message=HEAD@{1} or even shorter: git commit -C HEAD@{1} You can use the other options given by @user2718704.
With Git 2.23 (August 2019), you have the new command git restore (also presented here) git restore –source=HEAD –staged –worktree — aDirectory # or, shorter git restore -s@ -SW — aDirectory That would replace both the index and working tree with HEAD content, like an reset –hard would, but for a specific path. Original answer … Read more
There are three places where a file, say, can be – the (committed) tree, the index and the working copy. When you just add a file to a folder, you are adding it to the working copy. When you do something like git add file you add it to the index. And when you commit … Read more
Because there’s no point (other commands provide that functionality already), and it reduces the potential for doing the wrong thing by accident. A “hard reset” for a path is just done with git checkout HEAD — <path> (checking out the existing version of the file). A soft reset for a path doesn’t make sense. A … Read more
I have presented git restore (which is still marked as “experimental”) in “How to reset all files from working directory but not from staging area?”, with the recent Git 2.23 (August 2019). It helps separate git checkout into two commands: one for files (git restore), which can cover git reset cases. one for branches (git … Read more
To remove a directory and everything inside it from the index, git rm –cached -r dir The –cached switch makes git rm operate on the index only and not touch the working copy. The -r switch makes it recursive.