-2

Is there any possibility to disable/prevent deletion of a git repo's branches - locally and on the servers?

jonrsharpe
  • 115,751
  • 26
  • 228
  • 437
schnedan
  • 234
  • 1
  • 9
  • Does this answer your question? [GIT: How to protect the branch from being removed by other developers?](https://stackoverflow.com/questions/11401155/git-how-to-protect-the-branch-from-being-removed-by-other-developers) – Cameron Skinner Mar 11 '21 at 23:52
  • See https://stackoverflow.com/questions/2471340/is-there-a-way-to-lock-a-branch-in-git and https://stackoverflow.com/questions/11401155/git-how-to-protect-the-branch-from-being-removed-by-other-developers for possible solutions – Cameron Skinner Mar 11 '21 at 23:52
  • thx... I just not searched for words like "remove". – schnedan Mar 12 '21 at 00:16
  • @CameronSkinner - partly. In facht we host git on our ALM System at work, so answers with github or so do not help. Also We have no ability to use hooks or stuff. If there is a solution, I need one which works with a local repository or can be applied with no effort in an automated manner to the server repository. – schnedan Mar 12 '21 at 00:26

1 Answers1

1

You literally can't prevent it locally—but that doesn't matter because a local branch name is totally irrelevant. Branch names don't mean anything in Git. This is very different from Mercurial: in Mercurial, the branch you use to make a commit, is the commit's branch. In Git, the commit is on zero, one, ten, or even millions of branches simultaneously, based on graph reachability. So if someone deleted a name, you just put the name back and you're done. Want commit a123456 to be on branch xyzzy? Just run git branch xyzzy a123456 and now commit a123456 is on branch xyzzy, plus all branches it was on before.

On a server, of course, they're more important, since other people are getting commits from that server and then using origin/name to find those commits. Git's update of origin/name depends on the server having the name. Most hosting providers give you a way to lock or protect a branch name. This is not built into Git, however, so the method is up to the hosting provider.

torek
  • 448,244
  • 59
  • 642
  • 775
  • Thx,... "but that doesn't matter because a local branch name is totally irrelevant" - In a way my question is how to make em relevant. In fact if I compare the philosophy of git with hg, I really like the hg one and really dislike the git concept. So for my daily work I want to preserve the sane mechanics of hg. I am totally ok with merging a branch or with closing a branch (so no further commit is possible on Top), but I can not think of any situation where I want to loose or alter any history information - even when you might be able to recover it from the reflog. – schnedan Mar 12 '21 at 00:23
  • The short answer is that you can't (make Git behave like Mercurial) and it's frustrating to try. Don't do it. (I had to help a company through the transition, it was not fun) – torek Mar 12 '21 at 01:46
  • Well I Understand this point, but gits prominent features (which many advertise as something good) like deleting branches, altering old commits - even on a server, is something a good dvcs should prevent. So I am now forced to use a tool which not as good as the tool we used the last years. Any further tip how to get around gits bad design decisions or malicious features is appreciated... as you seem to have expierience here. – schnedan Mar 12 '21 at 07:34
  • It's mostly just learning-curve stuff. The one that smacks people in the face repeatedly is Git's use of what it calls the index. Mercurial doesn't have an index (and doesn't need one, proving that it's not actually necessary) but Git insists on making you know about it. The other items are the weird way Git uses branch names, and the complete lack of anything like commit phases and the evolve extensions. Have people be careful with `git push --force` or similar `--force` options as they can do the same kinds of things that `hg strip` can do, even though `git reset` is ... – torek Mar 12 '21 at 08:01
  • ... is the Swiss-army-knife command that's *meant* for stripping commits. If you have Git 2.23 or later, you do get the new `git switch` and `git restore` that give you back the safety that `git checkout` promised but failed to deliver: `git switch` won't wipe out uncommitted work the way `git checkout` can. (Checkout wasn't supposed to, but it has two modes, one of which is now split out into the separate `git restore`, and that one is the "erase my files" equivalent of `hg revert`. Note that `git revert` is `hg backout`.) – torek Mar 12 '21 at 08:03
  • Hey, thats good hints... git switch and git restore sound good to me! That git revert is hg backout is something you learn rather quick :-) – schnedan Mar 12 '21 at 10:07