What if I push a wrong commit?

Sometimes after pushing a new commit, we realise that there seems to be something wrong.

Don’t panic. In this case we could use git revert to cancel the commit.

Now let me illustrate it as follows:

Build a simulating remote folder locally

  • Due to the inaccessibility of internet of some people, we are going to create a simulating remote folder locally
  • Go to the folder where normally you put your projects
    • mkdir git_demonstration git_demonstration_central
    • cd git_demonstration_central
    • git init --bare
  • git_demonstration_central will be the remote repository in this article.

Build testing environment locally

  • Go to testing folder
    • cd ../git_demonstration
  • Intialize git
    • git init
  • Create a file called test
    • touch test
  • Add number 1 into the file test
    • cat 1 > test
  • Add test file into git tracking list
    • git add test
  • Make a commit towards current file and content
    • git commit -m'1'
  • Add number 2 into file test, and make a commit named 2
    • cat 2 >> test;git commit -am'2'
  • Add number 3 into file test, and make a commit named 3
    • cat 3 >> test;git commit -am'3'

Build remote branch

  • Add the simulating remote repository as the remote of our testing folder.
    • git remote add origin /user/yourUserName/yourDirectory/git_demonstration_central
  • put current master branch to remote, and set the newly created remote branch as the local one’s upstream branch
    • git push -u origin master
  • Check the history of remote repository
    • cd ../git_demonstration_central;git log

Revert existing commit

  • For example, we would like to remove the content recorded in commit 3
    • git revert f06550f7
  • Update the change to remote

    • git push
  • Check if the content of file test has changed

    • cat test
  • Got value 1 2, and the number 3 existed in commit 3 was already removed

  • Check the history of remote repository

    • cd ../git_demonstration_central;git log

Conclusion

Some git novices might have the same confusion as mine when I learnt this part. Why don’t we just eliminate the commit? instead, we would we add one more?

Here I would like to make a further explanation.
Normally, after pushing our commit to mutual repository, I strongly urge you not to revise the existing history. Because once you revise the existing history and push it to mutual repository, it could cause a huge impact to the history on everyone’s repository. After revising, every collaborator’s history will be different from yours, which would cause a lot of confusion and conflict.

What we want to take out is a code existing in the file, so realistically, we want to cancel the code, not history. In multi-collaboration, you could add new history, and not recommended revising old one. You could add a new commit specifying what you’ve done, but not to revise the history on your side, because only you know what you’ve done, and other people know nothing on your side.

In other words, before you push your part to mutual repository, you could do whatever you want (only to what you haven’t pushed. Don’t revise anything you’ve pushed), however, after pushing, don’t revise the history. If you want to do some revising on the file, just make a new commit explaining what you’ve done and push it, and then you could avoid possible confusion and conflict.

It’s my sharing today. See you guys.

Create a persistent disk in GCP Implement CI with Jenkins on AWS

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×