This command reverses the changes that previous commits introduced, and records them in new commits. To undo the faulty commit, use git revert. By introducing a commit in which we remove a line, reversing it means adding the line again to undo the faulty commit. So in this case, add a new line to erase it. Next, take the changes introduced in the last commit, which you can see by using git diff. Obviously in this case, you can also just change the content of 2.txt, but we want to clarify that we are undoing the last commit as it was a mistake. If you are not sure if someone has pulled the relevant commits, I recommend creating another commit that will simply undo the last commit.

Just to clarify, I recommend not using git reset to rewrite commits that have already been pushed to the remote unless you are completely sure that no one else has pulled the relevant commits. This means that someone might have already pulled this commit, and we don’t want to rewrite history so that it is inconsistent between our copy of the repository and someone else’s copy of the repository. The problem is that it has already been pushed to the remote. Remember you can use git reset of some sort to undo this last commit.

Next, add some content to the newly created file, and then stage and commit the change:Īnd now, let’s say I push this to the remote repository.Īnd… Oh, oops, I actually had a typo there:I wrote tezt instead of text. Now our reachable git history looks like this: Let’s create another file 2.txt, stage and commit it: Then we can undo the last commit on this branch using git reset.Īwesome! So we’ve successfully achieved the desired state with the power of the well-known git reset command together with the new command we introduced, git cherry-pick.Ĭontinuing with another example… Pushing a faulty commit For that, we can simply switch to main branch again using git checkout main. What’s left for us to do is to change main to point to “Commit 1”. So now, our newly created commit points to “Commit 2” and feature_branch points to this new commit.

At this point, let’s call it “Commit 3.1”. In other words, the new commit introduced the same changes as “Commit 3”, and it also has the same commit message – that is “Commit 3.” But this is a different commit object introduced with a different timestamp and thus it has a different SHA-1 value. This is exactly what we wanted: we applied the same changes that we had seen earlier, and this time, we applied them on feature_branch. You can now see the new commit, and the changes it introduced using git diff. Now the feature_branch points to the new commit. In this case, the changes to the file 1.txt generate a new commit including these specific changes, and then changes the pointer of the active branch. This basically takes the changes in “Commit 3” (with the SHA-1 value of c067afe7a50a54b1137aef0ed3b63f611b4ee8c7). If you want to apply these changes to the last commit on feature_branch, we need to be on feature_branch so we can use git checkout again. Note the changes this commit introduced using git diff. Start by adding the changes introduced in “Commit 3” to feature_branch. The commit which feature_branch is pointing to.The commit which “Commit 3” is pointing to.There are technically a few changes between the current “gitsaster” state and the desired state: Similar to that instance, we now want the change introduced in this commit on an already existing branch.Ī reminder, it’s useful to draw the current state versus the desired state. Oh, wait! What if you actually wanted this change to be introduced in the feature_branch, and not in main? We dealt with a similar case where we accidentally committed to the main branch, but actually wanted the commit to be recorded on a new branch. Now, switch back to the main branch using git checkout, make changes to the file 1.txt, and record these changes on main branch: Next, create a new file, and commit this addition to this feature branch. Committing to the wrong branchĪs I explained in the post about creating a repository from scratch, this creates the branch feature_branch, and also changes HEAD to point to that branch. This commit was added to the main branch, as we can verify using git log. I then added it to the index, and created a commit. To get started, let’s start by creating a small repository to play with.Īs you can see, I’ve created a repository and created a file called 1.txt, with the content hello. In this post, you’ll acquire additional tools to rewrite history and deal with “gitsasters.” Be sure to read Part 1 first, so you have the relevant background for overcoming git disasters. We then applied our knowledge to a few “gitsasters,” and saw that by understanding git and how it works, we can feel confident fixing cases when we need to rewrite history. In the previous post in this series, we learned about the command git reset, together with its three modes – -soft, -mixed, and -hard.

Discard changes git command line