Keep in mind that nothing in git is deleted - even git rebase just detaches commits, but you can still reference them through commit-id (hash). This means that it is hard to hide anything publicly pushed.
git rebase should never be used on public branches as it changes history and it will ruin the workflow of others, as their history will not match with history of origin causing changes to be lost.
There are various way of undoing work in git and none of them are as invasive as rebase
Remove changes made in just certain commit use: git revert commit-id
Remove changes on one file to commit before last one and retain them in staged tree: git reset HEAD~2 somefile.txt
Remove committed changes one file to commit before last but reset to working directory: git checkout HEAD~2 somefile.txt. This command removes all subsequent changes and is similar to git reset --hard, but on one file!
Outline:
Before you commit
Store your progress (git stash) - use your progress later (git stash pop)
Trash your progress (git reset)
After commit but before you pushed to public
Alternatives to git rebase that keep history
Remove changes made by one commit
Remove changes on one file
Remove committed
Change history (git rebase)
After push to public
Do not use git rebase
Only valid use would be to write a better commit message, but still be aware that you need to alert your team about this
Use alternatives that keep history
No conflicts, everything is nicely explained why you did it, and also progress is displayed.
@Letme Thanks -- I actually started on another one instead 👿 So you can keep going with it if you'd like, but I'll circle back to it when I finish the other one.
@marcia yes, I am interested. I can just fork and put back a merge requeset right? Is the above summary what you would expect in the post or is there any more/less/different?
Well, I'm a basic Git user myself, so I'd like to ask Axil to review your outlines before you begin. @axil would you do that for us? If you don't have time, pls let me know! :)
I can just fork and put back a merge request right?
Yes, basically all you need to create an MR with your post; I'll review it from there. But mind that we have some standards and guidelines:
@axil not familiar with bfg, but will check it out. Will include the git filter-branch, although on the end of the day that is just a bit smarter wrapper for git rebase.