I merged a PR on Github and had to revert it, so I used the revert button on the Github interface to do it. A new PR was made from the same branch the reverted one was made, but with a few additions. When I merge the new PR, some changes part of the old PR are missing.
Note that some commits were added after the reversion
I'm thinking of using the Github UI to again revert the previous reversion, but I'm not sure what this will do, can't find any documentation relating to that.
I'm curious to know why the code is getting lost and how I could avoid this. Also what's the best way to resolve this, use the revert option again?
ed3240aa (HEAD -> version/2, origin/version/2) Merge branch 'version/2' of github.com:umbrella/app into version/2
8d7b6a8f Bump version of app
8b268172 Fix error in condition for disavowing excluded alerts
a12eca40 Point app to staging
5c83c0bb Merge pull request #1090 from umbrella/revert-1088-add-sentiment // Merge PR with reversion
3ab766fc Revert "Add sentiment insight" // Revert happened here
132a9e64 Merge pull request #1089 from umbrella/nana_sources
acaec5e0 Merge branch 'version/2' into nana_sources
881925d7 - finished showing the dimension sources
df0b0ead Merge pull request #1088 from umbrella/add-sentiment
5bc3165d Merge pull request #1087 from umbrella/sync-exclude
c6936a2e (origin/sync-exclude, sync-exclude) Remove spurious logs
When you revert, git creates a new commit that contains the "opposite" of the reverted commit. For example, let's say you do a git revert 39f5, then you have this:
* 8998 (HEAD -> master) Revert "Do stuff that is needed"
* 39f5 Do stuff that is needed
* 8573 First commit
The 8998 commit is the revert, but it's still a normal commit. It just contains the 'opposite' as the 39f5. It's the same as if you un-did all the changes manually.
So if you continue working, all the work in 39f7 is no longer there! If you make a pull request, that's not included. If you want it to be included you have two options:
You can revert the revert. git revert 8998 will get rid of the revert, and you'll get your original changes back (which have bugs in them). Then, fix the bugs in another commit and do your pull request.
You can reset the revert. git reset 39f5 will go back to the commit 39f5, and 'erase' the revert. It will no longer be in your history, and so all the changes in 39f5 will be there. Again, fix the bugs in another commit and do the pull request.
If you are new to git, I recommend option 1, because it's more forgiving - the changes remain in your history and you can go back to them if you screw up. When you have more experience with git, you will know what is more appropriate between option 1 and option 2, and can play with it a bit more.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With