![]() ![]() Git updates your branch name to point to new commit I. H still points back to G, but so does new commit I: H ? it has a different hash ID, so let's call it I andĬommit H is still there in your repository.The new commit is exactly like H except in two ways: Now, if you have a tiny typo in commit H and run git commit -amend, what Git does is to make a new commit. That's a commit so it's numbered and has the same kind of stuff and points backwards yet again, and so on. (Commit H also contains a full snapshot of every file, though we won't look at this at all here.)Ĭommit G, being a commit, is numbered by some big ugly random-looking hash ID, and has a snapshot and metadata and hence points backwards to still-earlier commit F. Commit H itself contains the hash ID of earlier commit G. ![]() Your branch name "points to" (contains the hash ID of) commit H. Here's how Git sees-and finds-these commits. ![]() Imagine a simple chain of commits, ending with your most recent commit whose hash is some big ugly random-looking hash ID that we'll just call H. You just need to know that each commit is numbered-every commit has a unique number, which is its hash ID-and that Git finds commits in a sort of backwards (perhaps even backassward) fashion, by having a branch name or other name locate the most recent commit for you, and then working backwards from there. What it really did was make a new and improved replacement commit. The (tiny) lie with git commit -amend is that it didn't change a commit at all. The reason this is important to know-the reason you need to know that git commit -amend is a lie-is that what git commit -amend does locally, can be done here when pushing a commit to another Git repository. Resetting Merges" to become aware of how it works, and how to undo the revert later.It's impossible to change any commit. Please read my answer on "Reverting Merges vs. There are issues to be aware of when reverting merge commits. That commit "undoes" the changes that the merge introduced. git revert EĪfter reverting that merge commit, you will have the following history. It moves you forward in history rather than modifying history. Using git revert creates a new commit that negates the content of the merge commit instead of rewinding it. It is generally a bad idea to modify history that has already been pushed. Other wise they will just end up pushing up the same commit you just reset. Other developers will then need to know to use git-fetch followed by git reset -hard origin/master, and they may even need to perform a complicated git rebase -onto if they have new commits after the merge commit you removed. To push this up you will need to perform a forced push. If you reset, you are effectively rewinding history. Using git-reset after having pushed the commit means you've changed history that other people already have, This is bad. In that case someone had already reverted, but had some funky behavior after wanting to undo the revert - so take a look after reading this answer so you can get a full understanding of how it works. This will explain how revert works and how reset work with respect to merge commits. You should take a look at an answer I provided for a slightly different question, which involved reverting merge commits. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |