gitolite: consente di modificare solo i file selezionati

Question

Come configurare git e gitolite per consentire all'utente specifico di modificare solo i file che si trovano all'interno della directory specifica?

ad es. i file di origine maestro ramo:

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

utente kathrine, permettono di modificare solo /dir2/file1 e /dir2/file2

$kathrine: git clone git@example.com:test.git 

risultati in:

/dir2/file1 
/dir2/file2 

esistono direttive per-dir a gitolite.conf o devo configurare git con un nuovo ramo per questo utente?

Semplicemente non voglio che il designer grafico abbia accesso ai file del codice sorgente.

Answer 1

2010: Per Gitolite 2 (potrebbero essere cambiate per gitolite 3)

No (che significa un ramo dedicato con il giusto contenuto deve essere creato).

Come il author of gitolite himself put it:

Io sono l'autore di un progetto chiamato gitolite che fa un ottimo lavoro di controllo di accesso a livello di filiale per molteplici repository Git su un server centrale. Il mio "mercato" di destinazione è precisamente gli utenti aziendali di git.

Finora, non ho visto una situazione in cui l'accesso in lettura deve essere limitato a ortions di un repo (git non può farlo comunque).

[ben sparse checkout potrebbe aiutare, ma non è facile in ogni caso)

accesso in scrittura non hanno spesso bisogno di essere limitato, e gitolite può consentono di limitare:

• sia da parte nome del ramo (ad esempio, solo il lead QA può inviare una serie di commit al ramo "QA-done")
• o tramite nome file (ad esempio, solo il lead del team può apportare modifiche al Makefile e ai file in src/very-important-and-critical-module).

---

Vedere la sezione "security, access control, and auditing", e qui è un esempio di scrittura accesso:

Il conf/example.conf file dispone di ogni sintassi:

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 

ogni tou file ched per i commit che vengono spinti viene controllato contro quelle regole.

• lead_dev può spingere modifiche a qualsiasi file,
• dev1/2 può spingere le modifiche ai file in "doc/" e "src/" (ma non al livello superiore README),
• e dev3/4 può solo spingere le modifiche ai file in "src/".

---

Detto questo, la domanda difficile rimane, come il PO lo mette:

Come si crea nuova strega ramo solo alcuni file selezionati, ed eliminare il commit precedenti, quindi il grafico non ha potuto accedervi e vedere solo quelli selezionati dopo il clone?

Principio generale:

creare ramo 'graph_designer' in un punto della storia in cui tali file non erano presenti.

Da lì, due scelte:

• o riorganizzare il commit correnti (git rebase --interactive) in modo da avere prima quella con solo dir2 file (e quindi commit impatto qualsiasi altra directory)
• o, se la prima scelta rappresenta troppo lavoro (o non è possibile perché quei commit sono già stati inseriti e inseriti in altri repository), semplicemente copia e aggiungi i file rilevanti in quel nuovo ramo.
  Ciò significa che non esiste una cronologia passata per quei file, ma potrebbe non aver bisogno di quella cronologia fin dall'inizio.

Questo 'graph_designer' sarà l'unico ramo autorizzato a essere clonato e non conterrà alcuna cronologia con file non autorizzati.