And, If you change the Git history then you would make it a problem with merging their changes and with updating the code for them.In general, one should not rewrite/change the Git history because if you are working in a team then somebody else might have work on some feature based on your commit.
Also must have faced a problem where wanted to revert multiple Git commits at a time so let’s see how to do that. You must have reverted a single git commit at one point in time during programming. You can use this to even split commit in smaller ones or merge commit in fewer ones.In this article, we will see how Git Revert multiple commits at a time without affecting/changing the Git history. Then force push the changes as described above. Commit the change and continue the rebase ( use git rebase -continue if necessary to continue the process - git will tell you how to keep the commit message and author if you want ). rebase will stop at that commit, put the changes in the index and let you change it as you need. Here we do a rebase just like in Case 2 but instead of deleting the line, we change pick for edit. Then force push the changes back to the remote repo git push projectX -f This will open an editor and you can simply delete the offending commit and save the changes to the disk. If we want to delete an older commit but keep it’s children, then the easiest is to achieve this is to do an interactive rebase down to the parent of the bad (offending) commit.
The remote branch needs to be not protected to accept these forced commits. If you have the master branch locally checked out you can simply reset the current commit to it’s parent and force push it to the remote repo git reset HEAD^ -hard Where git interprets x^ as the parent of x and + as a forced non-fastforward push. We need to tell git to force projectX of branch master to the parent commit of acfcaf7b git push projectX +acfcaf7b^:master So in those cases, a revert without affecting history is the best choice. Meaning that deleting a commit will affect the ability of other to pull back the changes, especially if they have already worked on other parts of the code. If your push is a few days old or not the immediate last one, this can become tricky because rewriting history affects every other people or cloned repo out there.
It’s best to remove a bad commit from history right away after a push. Best to do on private repo or when other people haven’t pull yet or are not working on the project at the moment of your commit. Reverting and removing history should be done with care. I say erase because the history will still show all commits, but the bad ones won’t affect the code anymore.
This is useful if the commit is let’s say 5 commits behind and you wish to erase those changes. If your mistakes is only a small part of a big commit, scenario 1 should be the best bet. This will achieve more or less the same as fixing and committing again, but it’s done automatically and erases all the changes from the bad commit. Simply fix and push again in a new commit. History remains Alternative 1: Fix and commit again When we make a mistake and already pushed to the remote repo, we can either fix our mistake and push it again or revert and delete the history.