So this one's pretty basic. For reasons unknown, Git allows you to delete history. I've searched and searched and searched for a way to turn this off, and it seems there isn't one. Indeed, not only does Git allow you to delete history, but every tutorial I could find recommends that you regularly delete history, "to keep the graph clean". Deleting stuff isn't just possible, it's literally the recommended workflow! [insert horrified face here]

Given the above, it is 100% guaranteed that at some point somebody on my team (possibly even me) will accidentally delete something they didn't mean to, and then everything is ruined forever. Of course, if you realise you messed up, just don't push that to the central repo. You can just clone a new repo and delete the broken one. Problem solved. But what if you don't realise you did something wrong, and you end up pushing it? Now the central repo is broken, and nobody can fix it.

As far as I can tell, there are real, commercial companies doing real, mission-critical work using Git. So how do they "deal with" the abject lack of a safety net here? Surely they must have found a workaround for this. I can't imagine them going "oopsy, we just accidentally deleted 15 years worth of dev work. Oh well, never mind, eh?"

For context: I'm used to working with Mercurial. In that system, you can uncommit something after you committed it, but once it's been pushed to the central repo it's basically impossible to ever delete it. You can create a new commit that undoes whatever it did, but you cannot remove the original commit from history. In this model, no matter how badly you screw up the repo, you can always just revert to a time before you messed everything up. Heck, even if the central repo burns down somehow, just create a new, empty repo and have everyone push to it, and you're back in business again. Because every single repo is like a backup copy of your entire project history, and that history can never be damaged. Unfortunately, Git doesn't work anything like that. Everything can be deleted, and there's no undo.

CodePudding user response：

I've never seen anybody recommend deleting Git history. Standard best practices agree that you should "never re-write history", which would include deleting commits.

That said, this is a situation that you could theoretically create, but there are multiple safety nets that would prevent you from doing so in practice:

1. To push a history that conflicts with the server's view of a branch, you have to add extra flags, e.g. --force or --force-with-lease. You can't do this by accident.
2. If someone does force-push a totally broken history, everyone on the team will notice because they will get merge conflicts as soon as they try to pull. (This is an operation that can be --aborted safely - local repos will not become unintentionally broken.)
3. Even if it somehow goes unnoticed, you still have an extremely good chance of being able to recover. Since the Git repo is distributed and not centralized, every developer has their own copy of the repo. All it takes is one person with a "good" copy, and you can recover from that state. (This includes any branch that was forked from main/master - that branch will still have the full history even if main/master is broken.)

CodePudding user response：

Git offers possibilities to edit or manipulate the history. These features provide flexibility and comfortness and they address specific drawbacks in git. Good examples for those kind of features are rebasing, worktrees and things like 'commit --ammend'. Using them the right way (take care and follow best practices) makes git (and therefore your workflow) more powerful.

Important to say, these operations DO NOT delete things from the history. You can always revert to a previous state, even if you published them.

Git indeed has abilities to delete things in the history. Doing that is dangerous and you should really know what you are doing. Because of this, people rarely do it and actually I have never seen anyone doing it. It is quite hard to completely(!) delete a commit or content anyway. Even if you revert your branch to a previous commit, your 'deleted' commits are still present (but detached). You can access them using 'git reflog' and honestly, I have no idea how to absolutely delete them.

CodePudding user response：

The question seems to be based on a misunderstanding. Actually, deleting something is not possible in Git. You cannot mutate (edit) or remove (delete) a commit in Git. Git's job is to preserve history, and commits are the stuff of history in Git.

There is a rule that if a commit is not reachable (by way of some commit's name, such as a branch or tag, plus that commit's parent chain) it may be removed as part of garbage collection. But even that does not happen immediately when the commit becomes unreachable. If you make a commit unreachable by mistake, you literally have weeks to correct that mistake.

That said: sure, you can commit any idiocy you want. The repository (containing the commits) is in a .git folder. Nothing stops you from deleting it, any more than anything stops you from erasing your hard disk.