Stratégie de prévention ou de récupération de la réécriture de l'historique git

Question

Bien que j'adore l'historique de git réécrire fonctionnalité, comment fait-on pour s'assurer de l'histoire n'est pas réécrite.

Nous n'avons pas l'esprit de ce qu'un programmeur ne sur leur propre machine, mais nous devons veiller à ce qu'une version n'est pas poussé vers le serveur qui change l'histoire.

ie Nous avons besoin de garantir qu'une version particulière du passé était vraiment que de la version. Donc, ce serait d'empêcher quelqu'un va à travers et permet de supprimer définitivement un fichier à partir de l'histoire, de façon permanente ou modifie un fichier tout au long de toute l'histoire.

Answer 1

Si vous pouvez l'exécuter:

 git config --system receive.denyNonFastforwards true

sur le serveur, qui devrait prendre soin de réécrire l'histoire de cas d'être poussé vers ledit serveur.
Cependant, cela est pour toutes les pensions, pas pour certaine un fichier ou groupe de fichiers.

git config:

receive.denyNonFastForwards

Si vous rebase s'engage à ce que vous avez déjà poussé et puis essayer de pousser de nouveau, ou essayer de le pousser à une validation à une branche distante qui ne contient pas de s'engager à ce que la distance direction générale des points à l', vous serez refusé. C'est généralement une bonne politique; mais dans le cas de cela, vous pouvez déterminer que vous savez ce que vous faites et peuvent forcer la mise à jour de la branche à distance avec un -f drapeau de votre commande push.

L'autre façon dont vous pouvez le faire via le serveur-côté recevoir les crochets, j'aborderai dans un peu. Cette approche vous permet de faire des choses plus complexes comme nier non-rapide-vers l'avant pour un certain sous-ensemble d'utilisateurs.

---

Comme ebneter (qui sait l'importance d'une politique cohérente de référentiel -- voir la réponse au sujet de SVN à Git migrations) commentaires:

Vous pouvez aussi ajouter receive.denyDeletes true parce que sinon, quelqu'un peut il suffit de supprimer la branche, puis pousser leurs réécrit l'un en tant que nouvelle branche, effectivement réécriture de l'histoire.

git config:

L'une des solutions de contournement pour le denyNonFastForwards politique est pour l'utilisateur de supprimer la branche, puis remettez-la en place avec la nouvelle référence. Dans les plus récentes versions de Git (à partir de la version 1.6.1), vous pouvez configurer receive.denyDeletes true:

$ git config --system receive.denyDeletes true

Ce nie direction de la balise et la suppression de plus de pousser à travers le conseil d'administration - aucun utilisateur ne peut le faire. Pour supprimer les branches distantes, vous devez supprimer les ref des fichiers à partir du serveur manuellement. Il y a aussi plus intéressant de façons de le faire sur une base par utilisateur via les Acl, que vous découvrirez à la fin de ce chapitre.

Answer 2

Si vous n'utilisez pas un assez nouveau git receive.denyNonFastForwards, vous pouvez appliquer la politique par le biais {pre,post}-receive (entre autres) les crochets sur le serveur, ce qui permet un peu plus de précision pour des succursales et ainsi de suite.

Quelques bons exemples (y compris l'un interdisant l'histoire réécrit) sont utilisés par le projet GNOME pour la gestion de tous les dépôts, il y a:

https://git.gnome.org/browse/sysadmin-bin/tree/git

Je regarde en particulier à la pré-réception check-politique.

Answer 3

Si vous ne pouvez pas / ne voulez pas désactiver complètement la réécriture de l'historique Git, mais souhaitez être averti de tout changement de cette nature et pouvoir le récupérer des années plus tard, il existe des extensions de serveurs Git d'entreprise comme Gerrit qui détecteront les réécritures d'historique et les suppressions de branches. , les sauvegardera sous une référence spéciale afin qu’ils puissent être restaurés si nécessaire et ne soient pas élagués par le ramassage des ordures. Les administrateurs de Gerrit peuvent toujours supprimer des commits sélectionnés si nécessaire pour des raisons juridiques.