GIT remove the bad commit and Push to the remote repository

Question

A repository is created, and a calculator project is cloned in Python.

The file newfile.py has the code. This code is written in various commits. In the previous commits, the calculator code worked well. However, after certain commits, the calculator code displays a divide by zero exception. This is due to the change in line 2 of 'newfile.py'.

Use cat newfile.py to read the contents of the file

Use git log to check the previous commits.

Use Git Bisect to find the commit in which line 2 is changed from 'b = 20' to 'b = 0.00000'.

Remove the bad commit by using Git Revert. Leave the commit message as is.

Push to the remote repository.

My approach :

I have identified the bad commit using :

git bisect start git bisect good git bisect bad

after few steps i have identified the bad commit Id which has caused the problem.

I have followed the below steps to remove the bad commit :

1. git revert <>
2. git bisect reset
3. Need help in last step of [Push to the remote repository] ????? How to do this last step Note : i have attached the repository shown in the attachement.

[Git console showing branch]

Answer 1

$ git bisect start

$ git log --oneline

display the gitlog history with prefix git commit id

$ git bisect good INITIAL COMMIT

$ git bisect bad

this will display bad commit

$git bisect reset

$git revert BAD COMMIT

It will display a simple text file with commit message along with details. leave as is. :wq

$git push

Answer 2

When you use git revert, you do not remove a commit.¹ Instead, you add a new commit, specifically one whose effect is to undo the effect of a previous commit.² The consequence of this is that there is no need to force your push at all. Your new commit can be sent with an ordinary, non-forcing git push.

Remember that git push works by having your Git call up some other Git. Your Git and their Git then have a sort of conversation, where your Git announces to their Git that your Git has a new commit for them. If they have never seen this commit before,³ they will ask your Git to send it.

Then, having sent them your new revert commit, your Git asks their Git to set one of their branch names—the one you use in your git push command—to record this new commit as the latest commit in their branch. In other words, their master, or develop, or whatever name you use here, is their name to control however they like. You're just having your Git ask them to set their name to remember your new commit, instead of whatever commit it remembers right now.

If they agree to set that name as you request, your git push succeeds. If they reject that request for some reason, then you have to examine why they rejected it, and figure out what they want instead.

---

¹In general, all commits are both read-only and permanent. It is possible to discard existing commits, but it is difficult and generally discouraged, with one particular set of exceptions: any commits that you have made, but not sent to anyone else—that is, you have not used git push to publish them for others to use—are yours and yours alone, so you can remove them without consequence. The problem with removing published commits is that commits are a bit like viruses: bring your Git in contact with another Git that has that commit, and you get it again. So if you've published some commit, then you remove it, then you connect to any Git that has seen the published commit anywhere, well, now you have it again.

(Note that all commits are completely read-only. The unique hash ID for some commit is actually a cryptographic checksum of the contents of that commit, so if you extract a commit from a Git repository and change its contents and put that back, what you get is a new commit with a new and different hash ID. The existing commit remains in the repository, with its existing hash ID.)

²Note that reverting a merge commit doesn't undo the fact that the merge actually happened. It only backs out code changes.

³Every commit has a unique number—a hash ID—that is reserved to that one particular commit, and every Git everywhere agrees that that hash ID goes with that commit. So your Git need only present its commit number to the other Git. The other Git checks its database-of-all-commits, and if it does not have that commit, says yes, send me that commit. If it already has that commit, it says no need, I already have that commit. That's how your Git and their Git can figure out which commits you have, that they don't (git push), or which commits they have, that you don't (git fetch).