Suppose, then, that we let Git undo all the changes in F: But we showed at the top how ridiculously easy it is to get any file from any commit. This will, of course, back out the changes to the other files, that you didn't want backed-out. The other relatively easy way to deal with this is to let git revert do all of its work. There are additional git apply flags, including -3 / -3way that will let it do fancier things, much like git revert does.) The "do too much, then back some of it out" approach (Side note: you can do this all in one pass using:Īnd, git apply has its own -R or -reverse flag as well, so you can spell this: Once the instructions are successfully applied, we can look over the file, make sure it looks right, and use git add and git commit as usual. This is where git revert is smarter, because it can do that whole "merge" thing.) (Note, though, that this will fail if the instructions say to change lines in b that were subsequently changed by commits G or H.
#Git undo commit after push to github how to
The Git command that applies a patch-a set of instructions on how to change some set of files-is git apply, so: git apply < /tmp/instructions Now we just need to have Git apply these instructions, except that instead of the file from commit F, we'll use the file from the current commit H, which is already sitting in our work-tree ready to be patched. If you check the instructions file, it should now describe how to take what's in F and un-change b to make it look like what's in E instead. Git show -R hash-of-F - b > /tmp/instructions There's an even easier way, though, which is to tell Git: only bother showing instructions for particular files.
you'd get a new commit, which we can call I. Since most commits have a single parent, which lets Git hop backwards from the newer commits to the older ones, let's arrange them in a line with these backwards arrows. This hash ID never changes using it always gets you that commit, as long as that commit exists.) But they're big ugly strings of letters and numbers, so instead of guessing, say, 8858448bb49332d353febc078ce4a3abcc962efe, I'll just call your "commit 1" D, your "commit 2" E, and so on. The hash ID-the big ugly string of letters and numbers-is the "true name" of the commit. I now have to guess at the actual hash IDs for each of your five commits. You edited your question, though, to ask for something rather different. That's what you seemed to be asking, and hence what the linked question and current answer (as of when I am typing this) provide. You just tell Git: Get me file b.ext from commit a123456, for instance, and now you have the version of file b.ext from commit a123456. Since each commit is a complete snapshot, it's easy to revert to a particular version of a particular file in a particular commit. Whatever is different in a123456, that's what Git will tell you. If you ask Git, e.g., what happened in commit a123456?, what Git does is find the parent of a123456, extract that snapshot, then extract a123456 itself, and then compare the two. However, every commit-well, almost every commit-also has a parent (previous) commit.
In Git, each commit saves a snapshot-that is, the state of every file-rather than a set of changes.
0 kommentar(er)
