2010-07-29 14 views
9

J'ai un référentiel central avec un sous-ensemble de fichiers que je veux protéger contre toute modification (en poussant) d'autres utilisateurs. Si j'ajoute ces fichiers à .gitignore, ils ne seront pas clonés.Protéger des fichiers dans le référentiel git

Est-il possible de donner la possibilité de cloner tous les fichiers, mais après le clonage, d'ajouter certains d'entre eux à .gitignore sur le côté client?

+0

Est-ce que .gitignore est engagé dans le référentiel? Pourquoi voulez-vous protéger ces fichiers? Est-ce que .gitignore ajoute n'importe quel type d'accès par utilisateur, ou est-ce que votre changement signifierait que * personne * ne pourrait changer ces fichiers? Qu'est-ce que vous essayez d'accomplir? –

+0

Serait-ce une option de rejeter simplement les poussées qui modifient ces fichiers? Vous pouvez également proposer un hook côté client pour rejeter les mauvais commits. – Cascabel

Répondre

0

Je pensais d'abord sur une filter driver (voir Pro Book), qui:

  • sur l'étape de maculage enregistrer votre contenu de fichiers
  • sur l'étape propre rétablirait le contenu des fichiers.

alt text

Mais ce n'est pas une bonne solution car ces scripts sont sur fichier sans étatde contenu transformation (voir this SO answer). Vous pouvez essayer d'appliquer un mécanisme de sauvegarde/restauration dans les hooks (voir la même réponse SO), mais notez qu'il sera local à votre repo (il protégera vos fichiers dans votre repo uniquement, les hooks ne sont pas poussés)

Vous pouvez également utiliser:

git update-index --assume-unchanged file 

Voir "With git, temporary exclude a changed tracked file from commit in command line", encore une fois une protection locale seulement. Cela les protégera contre la poussée externe à votre repo ("importation"), mais si vous les publiez ("export"), que peut être modifié du côté du client.

+0

Merci. Je connais git update-index --assume-unchanged, mais il est appliqué uniquement du côté client. Je connais aussi les hooks, mais ils ne sont pas clonés à partir du repo central. – andrexus

+0

@andrexus: Je sais: le pilote de filtre est la seule solution pouvant être utilisée, mais il faudra plier le script smudge pour le forcer à connaître le chemin des fichiers concernés (sauvegarder/restaurer), alors qu'il devrait seulement connaître le contenu des fichiers ... – VonC

1

Y a-t-il une raison spécifique pour laquelle Git doit être lui-même la réponse?

Que diriez-vous de rendre les fichiers en lecture seule, et en dictant comme la politique que ces fichiers ne devraient pas être poussés?

Parfois, une solution technologique n'est pas la plus simple.

Si quelqu'un fait apporter des modifications à ces fichiers, ces modifications peuvent toujours être annulées.

1

Vous pouvez avoir les fichiers dans le référentiel, les valider, puis les ajouter au .gitignore, puis les supprimer de la prochaine validation.

Vous pouvez toujours récupérer les fichiers directement avant la validation (peut-être l'étiqueter avec quelque chose de sorte qu'il peut être récupéré par nom un peu plus facile) et cela préservera l'état du fichier, sans le modifier facilement dans le référentiel par accident.

Pour accéder à ces fichiers après avoir tiré le clone, il suffit d'écrire une tâche rake qui les récupère pour l'utilisateur de votre référentiel.

1

Il me semble que le problème se situe ailleurs si vous avez besoin de ce niveau de restriction d'accès.

Néanmoins, si vous voulez vraiment implémenter cela, pensez à Gitolite. Il vous permet de définir des règles d'accès plutôt détaillées et devrait probablement suffire à vos besoins.

documentation gitolite: http://gitolite.com/gitolite/master-toc.html

Vous pouvez définir pour contrôler l'accès 'refs virtuels' au niveau du fichier. Plus sur cela: http://gitolite.com/gitolite/vref.html