Git has a feature to save you, though, called the reflog: $ git log -g You would appear to be out of luck: that commit has been discarded, and unless you happen to have its object ID, you have no way to refer to it, even though itâs still in the object database. Suppose youâre having an off day and, having committed and then amended that commit, you suddenly realize that you just lost some information from the first commit that you didnât mean to. So you simply modify the index as desired, and commit again.Īlthough we described it in terms of a linear history, git commit -amend works with merge commits as well then there are multiple parents and branches involved instead of just one, but it operates analogously. Having dropped the previous commit, the repository state you want to change and re-commit would appear to be lostâ¦but no: thereâs another copy of it in the index, since that commit was made from the current index. Eventually, if the discarded commit remains disconnected from the commit graph, Git will delete it from the object database as part of periodic garbage collection. Thus, discarding the tip commit consists only of moving the branch pointer backward to the previous one nothing else need be done. In particular, no commits point to this one, so no other commits are affected (recall that commits point to their parents, but not to their children). The tip commit on the current branch has a pointer to the previous commit, its parent that is all that links it to the rest of the branch. The -amend feature is a good example of how Gitâs internal organization makes many operations very easy, both to implement and to understand. You can add -C HEAD if you want to reuse the previous commit message as-is. Git will present you with the previous commit message to edit if you like then, it simply discards the previous commit and puts a new one in its place, with your corrections. Then use this command : $ git commit -amend Thereâs no preparatory step just make whatever corrections you need, adding these to the index as usual. This common situation is also the easiest one to address. The most common correction to make is to the previous commit: you run git commit, and then realize you made a mistakeâperhaps you forgot to include a new file, or left out some comments. We will discuss techniques for editing a branched history in Chapter 10. Note that most of the techniques discussed in this chapter only make sense when the portion of history involved is linear that is, contains no merge commits. The extra step afforded by Git is crucial, though: by separating committing and publishing, it allows you to use version control freely for your own purposes as you work, then clean up your commits for public consumption before publishing them. You are free to delete or change your local commits as you please, and Git gives you the tools to do that publishing those commits is a separate action, via pushing to shared repository or asking others to pull from yours.Ĭhanging already published commits is awkward, of course, since it would cause others to lose history they already have Git will warn people pulling from you of that, and you might not even be allowed to push such changes to a shared repository. With Git, however, this is not a problem, since you are committing to your own private repository. This makes undoing a commit problematic how do you retract a commit others have already checked out or merged? With centralized version control, committing and publishing a change are the same thing: as soon as you commit to the shared repository, others can see and start using your changes. This chapter is about undoing or correcting changes once youâve committed them. In Chapter 3, we discussed staging changes in the index for inclusion in the next commit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |