If you don't trust him don't give him direct access to the repo. Instead you should accept changes that he send to you in the form of patches or changes in a fork (a fork of the repo) through merge or pull requests[1], the last depends on how you share your repo. This will allow you to do a code review and deny any bad changes. Please read 1 for more explanation.
[1] - https://git-scm.com/book/en/v2/Distributed-Git-Contributing-to-a-Project El jue., 20 de jul. de 2017 a la(s) 14:14, Igor Djordjevic < igor.d.djordje...@gmail.com> escribió: > Hi Lucky Limey, > > On Thursday, July 20, 2017 at 4:46:20 PM UTC+2, Lucky Limey wrote: >> >> I have a private repository set up for a project. I may be heading for a >> dispute with one of the coders.... How do I protect the repository from >> vandalism? I would hate for him to delete all our work etc. etc. >> > > By removing his write access to the repository? Or just making a clone, or > a simple copy of it...? > > Otherwise, what are you exactly concerned with? > > One of the beauties of a distributed version control system, which Git is, > makes for each repository clone being a full/original/authentic repository > copy. So as long as at least one person has the repository (locally, or > wherever), the code and its history can`t get lost/damaged, no matter if > some repository you`ve declared "central" gets corrupted/deleted/lost - you > would just clone it again from any other still existing repository. > > For example, if I have a GitHub repository, I`ll most probably have a > local clone of it, the one which I`m working on, so even if my GitHub > repository gets deleted/detroyed it won`t really matter as I still have > everything in my local clone, and I can easily recreate GitHub repository > as if the issue never happened. > > Only in case if I`m the only one having the GitHub clone, and I haven`t > synchronized my local clone lately (through fetch/pull) and there were some > changes on GitHub side which gets destroyed, I would lose those latest > commits since my last synchronization, but that`s really the worst case > scenario - usually more than one person would work on GitHub repo, and any > of them might have a more recent clone (or s fully up to date one). > > Anyway, nothing beats regular/planned backups, just that Git might even > save you when you (think you) don`t have one :) > > Regards, > Buga > > -- > You received this message because you are subscribed to the Google Groups > "Git for human beings" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to git-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
