2010-07-08 7 views
6

Comment configurer git et gitolite pour permettre à un utilisateur spécifique de modifier uniquement les fichiers qui se trouvent dans un répertoire spécifique?gitolite: permet de modifier uniquement les fichiers sélectionnés

par exemple. fichiers dans la branche master d'origine:

/dir1/ 
/dir2/file1 
/dir2/file2 
/dir3/file1 

utilisateur kathrine, permettent de changer seulement /dir2/file1 et /dir2/file2

$kathrine: git clone [email protected]:test.git 

résultats dans:

/dir2/file1 
/dir2/file2 

Y a-t-il des directives par-dir dans gitolite.conf ou dois-je configurer git avec une nouvelle branche pour cet utilisateur? Je ne veux pas que le concepteur graphique ait accès aux fichiers de code source.

Répondre

4

2010: Pour gitolite 2 (peut-être changé pour gitolite 3)

Non (ce qui signifie une branche dédiée avec le bon contenu doit être créé).

Comme le author of gitolite himself put it:

Je suis l'auteur d'un projet appelé gitolite qui fait un excellent travail de contrôle d'accès au niveau de la branche pour plusieurs référentiels git sur un serveur central. Mon "marché" cible est précisément les utilisateurs professionnels de git.

Jusqu'ici, je n'ai pas vu une situation où l'accès en lecture doit être restreint aux ortions d'un repo (git ne peut pas le faire de toute façon).

[bien sparse checkout pourrait aider, mais il est difficile de toute façon)

accès en écriture ne doivent souvent être restreint, et gitolite peut vous permettre de limiter:

  • à la fois par nom de la branche (par exemple, seul le responsable QA peut insérer une série de commit dans la branche "QA-done")
  • ou par nom de fichier (par exemple, seul le chef d'équipe peut apporter des modifications au Makefile et aux fichiers src/very-important-and-critical-module).

Voir la section "security, access control, and auditing", et voici un exemple de écriture accès:

Le conf/example.conf file a toute la syntaxe détaillée:

repo foo 
     RW+ = lead_dev # rule 1 
     RW = dev1 dev2 dev3 dev4 # rule 2 

     RW NAME/ = lead_dev # rule 3 
     RW NAME/doc/ = dev1 dev2 # rule 4 
     RW NAME/src/ = dev1 dev2 dev3 dev4 # rule 5 

chaque file tou ched par les commits étant poussé est vérifié par rapport à ces règles.

  • lead_dev peut pousser des modifications à tous les fichiers,
  • dev1/2 peuvent pousser les modifications aux fichiers "doc/" et "src/" (mais pas au niveau supérieur README),
  • et dev3/4 peut seulement pousser les modifications aux fichiers dans "src/".

Cela étant dit, la question difficile reste, comme l'OP met:

comment puis-je créer une nouvelle sorcière branche certains fichiers sélectionnés, et supprimer les commits précédents, donc le graphiste ne pouvait pas y accéder, et ne voir que les sélectionnés après le clone?

Principe général:

créer branche « graph_designer » à un moment de l'histoire où ces fichiers ne sont pas présents.

À partir de là, deux choix:

  • soit réorganisent vos commits actuels (git rebase --interactive) afin d'avoir d'abord celui avec seulement dir2 fichiers (et archivages alors un impact tout autre répertoire)
  • ou, si le premier choix représente trop de travail (ou n'est pas possible parce que ces commits ont déjà été poussés et retirés dans d'autres repos), il suffit de copier et d'ajouter les fichiers pertinents dans cette nouvelle branche.
    Cela signifie, pas d'historique pour ces fichiers, mais ils n'ont pas besoin de cette histoire depuis le début.

Cette 'graph_designer' sera la seule branche autorisée à être clonée et ne contiendra aucun historique avec des fichiers non autorisés.

+0

Merci pour cette réponse détaillée. Alors, comment créer une nouvelle branche avec certains fichiers sélectionnés, et supprimer les commits précédents, afin que le graphiste ne puisse pas y accéder et ne voir que ceux qui sont sélectionnés après le clone? – takeshin

+0

@takeshin: crée une branche '' graph_designer' 'à un point de l'histoire où ces fichiers n'étaient pas présents, alors, par exemple, vous pourriez directement copier les bons fichiers et les valider (ce qui signifie: pas d'historique pour ces fichiers , mais ils pourraient ne pas avoir besoin de cette histoire dès le début). Ce «graph_designer» sera la seule branche autorisée à être clonée et ne contiendra aucun historique avec des fichiers non autorisés. – VonC

+0

Notez que ceci n'est plus valide pour gitolite v3 – jan

Questions connexes