![]() In short, if you rollback, undo, or rewrite the history of a commit chain that others are working with, your colleagues may have a lot more work when they try to merge in changes based on the original chain they pulled. But avoid making changes that rewrite history if the commits have already been pushed to the remote repository and others may be working with them. This brings us to one of the fundamental rules when working with Git in this manner: Making these kinds of changes in your local repository to code you haven't pushed yet is fine. This is because the Git workflow works well for picking up additional commits at the end of a branch, but it can be challenging if a set of commits is no longer seen in the chain when someone resets the branch pointer back. Why would you choose to do a revert over a reset operation? If you have already pushed your chain of commits to the remote repository (where others may have pulled your code and started working with it), a revert is a nicer way to cancel out changes for them. Here are the current contents of the file in the working directory: $ cat If we do a git log now, we'll see a new commit that reflects the contents before the previous commit. # with '#' will be ignored, and an empty message aborts the commit.įigure 3 (below) shows the result after the revert operation is completed. # Please enter the commit message for your changes. ![]() This can be done with a git revert command, such as: $ git revert HEADīecause this adds a new commit, Git will prompt for the commit message: Revert "File with three lines" If we add a line to a file in each commit in the chain, one way to get back to the version with only two lines is to reset to that commit, i.e., git reset HEAD~1.Īnother way to end up with the two-line version is to add a new commit that has the third line removed-effectively canceling out that change. The effect is most easily seen by looking at Figure 1 again. Where the reset command moves the branch pointer back in the chain (typically) to "undo" changes, the revert command adds a new commit at the end of the chain to "cancel" changes. The net effect of the git revert command is similar to reset, but its approach is different. Before you use the hard option, be sure that's what you really want to do, since the command overwrites any uncommitted changes. ![]() In effect, it resets (clears out) the staging area and overwrites content in the working directory with the content from the commit you reset to. This overwrites any local changes you haven't committed. Using these options can be useful in targeted circumstances such as git reset -hard . These options include: hard to reset the commit being pointed to in the repository, populate the working directory with the contents of the commit, and reset the staging area soft to only reset the pointer in the repository and mixed (the default) to reset the pointer and the staging area. To do so it is necessary to undo three commits, so for that a suitable command is the following:Īgora vamos supor que eu quero voltar ao estado do commit d815be que é o commit inicial que adicionou o arquivo README.md.The git reset command also includes options to update the other parts of your local environment with the contents of the commit where you end up. ![]() Now let’s suppose I want to go back to the state of commit d815be which is the initial commit that added the README.md file. Let’s take another look at our history, which now contains only four commits (since I already undid one): To do so, just add the number of commits you want to undo after ~. Now that you know how to undo a commit, you can use the first command you’ve just seen and adapt it to undo more commits. You can now discard the changes or keep up with them and make a new commit. And if you check the history again you will see that the commit 48ccb8 no longer appears. Suppose you have a history like the one in the following image, in which the last commit ( 48ccb8) adds the file called arquivo-4.txt:Īnd if you run any of the commands above, followed by a git status, you will see a result like this:Īnd you can see that arquivo-4.txt has returned to its previous state, which was waiting to be committed. Note that when executing these commands, you will not see a message stating that the commit was undone, but if you run the command git status after executing any of these three commands you will see that files added and/or changes made went back to being marked as changes to be committed (added to a commit). Go back to the state before the last commit.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |