![]() ![]() This results in a simple backwards-looking chain. That is, most commits list one previous commit hash ID. Crucially for Git's internal workings, Git adds, to this metadata, a list of previous commit hash IDs, which Git calls the parents of this commit. Your log message goes in here too, when you make a commit. Holds some metadata, such as the name and email address of the person who made the commit. ![]() That's why they are safe to share across multiple commits. But they're not ordinary files: they're special Git-only compressed-and-de-duplicated things, that only Git can read, and nothing-not even Git itself-can overwrite. These snapshots are like tar or WinZip archives, in a way, in that you can just have Git extract all the files from them any time you like. ![]() That is, when you make a new commit, if you have a million files but have only changed three of them, the new commit doesn't duplicate all 1 million files: it re-uses all but the new three. Holds a full snapshot of every file, in a compressed and (important for Git's internal operation and for your disk space needs) de-duplicated fashion. So the big all-objects-database you find in a Git repository is completely read-only all you ever do is add to it. The numbering system requires that nothing ever be changed once it gets stored. We use branch names instead, as we'll see in a moment. The need for these numbers to be totally unique to each commit is what makes them so big it also makes them unusable by humans, but the computer is good at them, so the computer uses them. So if you have this commit (the one that starts with f01e51a7cf, that I linked to the GitHub copy of it), it's literally this commit, and you must have a clone of the Git repository for Git. The commit hash IDs are always totally unique. All the objects, including the commits, are numbered, but their numbers are big ugly random-looking things, such as f01e51a7cfd75131b7266131b1f7540ce0a8e5c1. Ignoring the supporting here, we'll just talk about the commit objects, since those are the ones you interact with. It's the commits-and-other-objects database that really matters: you can use a repository in which the names database is completely empty (it's just extremely awkward and unpleasant to do that), but you can't use a repository in which the objects database is empty. One database hold commits and other supporting objects, and a separate database holds names-branch names, tag names, and other names that help Git find the commits. Ī Git repository is, at its heart, just two databases. As such, you need to know what a Git commit is and does for you, and how git commit makes a new commit. Git is not about files, although Git commits hold files, and Git is not about branches, although Git branch names help you (and Git) find the commits. But adding everything, then un-adding ( git rm -cached -rf) the unwanted files, also works. This tends to be easier to get right, which is why it's the recommended method. ) to add everything except the current untracked-and-ignored files. gitignore file first, then use a standard "add everything" ( git add. Had you used -mixed (or the default which is -mixed), you might have had to add some other files besides the. You should git add the file after updating it (or creating it with appropriate initial contents). ![]() gitignore so that you can't accidentally add the. You will still want to create or update your. angular/cache (be sure to use the -cached to avoid removing the working tree copies). However, as j6t added, you can recover from this error by using git rm -cached -rf. As chepner suggested in a comment, you probably really wanted a -mixed reset, not a -soft reset. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |