If your Git has 51ebf55b9309824346a6589c9f3b130c6f371b8f and their Git doesn't, then you have a commit they don't, and they can get it from you. The uniqueness of these hash IDs means that every Git that has a clone of some repository can talk to any other Git that has a clone of the same repository, and just exchange hash IDs with the other Git. That's why commit hash IDs are so big and ugly, like 51ebf55b9309824346a6589c9f3b130c6f371b8f (and even these aren't big enough any more-they only count to about 10 48-and Git is moving to bigger ones). Because the ID has to be unique-and reserved for all time for that commit-it has to be a truly enormous number. In a way, that hash ID was reserved for that commit before you made the commit, and is still reserved for that commit even after you manage to remove it. That hash ID is reserved for that commit, and only that commit can ever use it. The hash ID of a commit is the commit, in a sense.
We'll ignore these usable files here and just concentrate on the commits themselves.Įvery commit has a unique hash ID. That's part of why a -hard reset is relatively dangerous (but not the whole story). These files aren't in Git at all, but they let you get your work done. The compressed, dehydrated, and frozen-for-all-time files come out and get defrosted and rehydrated and turned back into ordinary files. This is why Git normally extracts one commit for you to work on. and quite useless for getting any new work done. The unchangeable-ness of every part of a commit is what makes commits great for archival. Nobody and nothing can change it: not you, and not even Git itself. Like the snapshot, this metadata is frozen forever once you make the commit. This metadata ties each new commit to some existing commit. Meanwhile, the rest of the commit consists of metadata, or information about the commit: who made it, when, and so on. Only Git can actually use these files, but the up-side of this is that making hundreds or thousands of snapshots doesn't take lots of space. That's the main bulk of a typical commit, and because it is, the files that are stored in a commit like this are stored in a special, read-only, Git-only, frozen form. This isn't a set of changes since a previous commit! It's just the entire set of files, as a snapshot.
Remove commit from master git full#
1 What a commit contains comes in two parts.įirst, each commit holds a full snapshot of all of your files. The commit is your fundamental unit of storage in Git. Git is not really about branches, nor is it about files.
Remove commit from master git how to#
To get there, and see how to reset your GitHub repository too, let's do a quick recap of some Git basics. what this kind of git reset is going to do.
You'll need more than that, though-and before you blindly any of these commands, it is crucially important that you understand two things: Be aware that git reset -hard destroys uncommitted work, so before you do that, make sure you do not have anything uncommitted that you do want to save.Īs Tarek Dakhran commented, you probably wanted git reset -hard HEAD^^. We'll use git reset -hard here for reasons we won't get into properly. Let's just look at how you convince one Git to discard some commit(s), using git reset. Even if/when you manage this, they won't go away immediately: in general, you get at least 30 days to change your mind and bring them back again. If you really do want to remove some commits, you must now convince every Git that has them to give them up. (You did eventually note this in a comment.) Your original question left off the fact that, having added two commits, you published them to GitHub.
0 kommentar(er)
