Vraag Hoe deel ik een Git-repository met meerdere gebruikers op een computer?


Ik heb een Git-repository op een staging-server waaraan meerdere ontwikkelaars moeten kunnen werken. git-init lijkt een vlag te hebben die erg lijkt op wat ik zoek: --shared, behalve dat ik ook graag meerdere mensen naar die repository zou willen trekken. De git-clone's --shared vlag doet iets heel anders.

Wat is de gemakkelijkste manier om de machtigingen van een bestaande repository te wijzigen?


201
2018-06-17 01:04


oorsprong


Ik gebruik "Github voor Windows" en schakel tussen twee Github-accounts: stackoverflow.com/questions/18565876/... - Alisa


antwoorden:


Toestemmingen zijn een plaag.

Kortom, je moet ervoor zorgen dat al die ontwikkelaars alles kunnen schrijven in de git repo.

Ga naar de New Wave-oplossing voor de superieure methode om een ​​groep schrijfmogelijkheden voor ontwikkelaars te verlenen.

De standaardoplossing

Als u alle ontwikkelaars in een speciaal gemaakte groep plaatst, kunt u in principe gewoon doen:

chgrp -R <whatever group> gitrepo
chmod -R g+swX gitrepo

Wijzig vervolgens de umask voor de gebruikers om 002, zodat nieuwe bestanden worden gemaakt met groepschrijfbare rechten.

De problemen hiermee zijn legio; als je op een distro bent die uitgaat van een umask van 022 (zoals het hebben van een gemeenschappelijk users groep die standaard iedereen bevat), dit kan beveiligingsproblemen elders openen. En vroeg of laat zal iets je zorgvuldig ontworpen toestemmingsschema verknoeien, waardoor de repo buiten werking wordt gesteld root toegang en repareer het (d.w.z. de bovenstaande commando's opnieuw uitvoeren).

De nieuwe-golfoplossing

Een superieure oplossing - hoewel minder goed begrepen, en waarvoor een beetje meer OS / hulpmiddelondersteuning nodig is - is het gebruik van uitgebreide POSIX-kenmerken. Ik ben pas vrij recent naar dit gebied gekomen, dus mijn kennis hier is niet zo heet als het zou kunnen zijn. Maar eigenlijk is een uitgebreide ACL de mogelijkheid om machtigingen in te stellen op meer dan alleen de 3 standaardslots (gebruiker / groep / ander).

Maak dus opnieuw je groep aan en voer vervolgens uit:

setfacl -R -m g:<whatever group>:rwX gitrepo
find gitrepo -type d | xargs setfacl -R -m d:g:<whatever group>:rwX

Hiermee wordt de uitgebreide ACL voor de groep ingesteld, zodat de groepsleden kunnen lezen / schrijven / openen naar welke bestanden dan ook al zijn (de eerste regel); vertel vervolgens ook aan alle bestaande mappen dat nieuwe bestanden dezelfde ACL moeten hebben (de tweede regel).

Ik hoop dat je op weg gaat.


171
2018-06-17 06:00



git init heeft een parameter genaamd --gedeeld die de core.sharedRepository-variabele instelt voor groepswerk. U kunt de variabele ook instellen op een bestaande repository. Dat maakt het niet nodig om de umask handmatig in te stellen, want git zal het op een gezonde waarde zetten voordat bestanden worden gemanipuleerd. - ptman
+1 voor uitgebreide POSIX-kenmerken - nieuws voor mij! - RobM
Toen ik dat deed chmod -R g+swX, het maakte Git erg ongelukkig en het besloot dat het geen git repository meer was ("repo lijkt geen git repository te zijn"). Ik moest chmod g-s alle van de bestanden. Om de setgid-bit in te stellen op de directories, proberen find /path/to/repo -type d -print0 | xargs -0 chmod g+s. Doe nog steeds het chgrp -R thegroup /path/to/repo. - rescdsk
chmod -R g+swX gitrepo past het setguid-bit op bestanden toe, wat een beveiligingsrisico is. In plaats daarvan kunt u gebruiken find . -type d -exec chmod g+s {} + om het alleen toe te passen op mappen. - Ian Dunn
ACL (setfacl) heeft geen instelling voor setgid om nieuwe bestanden en submappen toe te passen die in een map zijn gemaakt om de groeps-id te erven. Daarom moet je setgid apart instellen via chmod. Git's --gedeelde optie (git-scm.com/docs/git-init), kunt u echter instellen dat u de umask van de gebruiker overschrijft en overschrijft. - Chase T.


als je de repository hebt gemaakt (of een nieuwe kale repo van een bestaande kopie hebt gekloond) met

$ git init --shared=group 

of

$ git init --shared=0NNN

Git wordt geacht om te gaan met toestemmingen die verder gaan dan wat je standaard umask biedt. Eindelijk is dit waar in mijn versie van Git (1.6.3). Natuurlijk gaat dit ervan uit dat uw gebruikers zich in dezelfde groep bevinden.

Als ik het beheer van gebruikers in meerdere groepen met verschillende mate van lezen / schrijven echter nodig had, zou ik meegaan met gitosis. Ik heb ook vernomen dat gitoliet (http://github.com/sitaramc/gitolite), een gitosisvork die wordt suppossed om machtigingen op branch niveau te bieden, kan niet zeggen dat ik het allemaal persoonlijk heb gebruikt.


113
2018-02-17 05:40



Dit is absoluut het juiste antwoord. - ELLIOTTCABLE
Ik had dit probleem en dit is verreweg het beste antwoord. Het enige probleem is dat de --shared argument neemt een octaal, niet hexadecimaal. Ik heb dit bevestigd in de bron van Git 1.7.8 en het tweede voorbeeld zou moeten zijn git init --shared=0NNN. - qpingu
Wat is NNN-Permissies masker of een groepsnummer of iets anders? - Craig McQueen
BTW, "groep" hierboven is een sleutelwoord, geen plaatsaanduiding voor uw groepsnaam. U wijst de groep toe met behulp van de opdracht chgrp. Voor een nieuwe repo is dat zo git init --bare --shared=group myproj waar myproj je repo-naam is, gevolgd door chgrp -R mygroup myproj waar mijn groep uw groepsnaam is - labradort
Begrijpt dat als uw gebruikers een commit doen wanneer hun standaardgroep anders is dan wat het zou moeten zijn, het dingen kan verpesten. Om dit probleem op te lossen, moet elke gebruiker elk bestand dat hij bezit in de repo in de juiste groep verwerken. Dit zal zich herhalen, tenzij je bedenkt hoe iedereen iedereen moet maken / schakelen tussen nieuwe / onder de juiste groep voordat hij zich commit en pusht. - ragerdl


Dit is niet gezegd, dus ik wil het snel toevoegen.

Om ervoor te zorgen dat machtigingsproblemen hun lelijke kop niet bijsnijden, moet je het volgende instellen in het configuratiebestand van je git shared repository:

[core]
    sharedRepository = true

Dit zorgt ervoor dat de "umask" -instellingen van uw systeem worden gerespecteerd.


50
2018-03-09 05:52



Volgens git-config (1) (kernel.org/pub/software/scm/git/docs/git-config.html) core.sharedRepository, u moet dit instellen op "umask" of "false" om het umask van de gebruiker te respecteren. - David Schmitt
Het antwoord van deze en user35117 is correct. Merk op dat "waar" hetzelfde is als "groep", en dit kan worden ingesteld met de opdracht git config core.sharedRepository true. - ColinM
Verandert het nog steeds het eigendom van een bestand wanneer het naar de afstandsbediening wordt gepusht? - Duc Tran
Als je dit wilt instellen bij het klonen in plaats van na het feit, het equivalent van git init --shared is git clone --config core.sharedRepository=true. Vreemd genoeg om te gebruiken --shared voor dergelijke verschillende betekenissen in dergelijke gelijkaardige bevelen. - stevek_mcc


De Git-gebruikershandleiding beschrijft hoe te deel een repository op verschillende manieren.

Meer gecompliceerde, hoewel functie-volledige manieren om repositories te delen zijn:

We gebruiken GitHub voor een team van 6 ontwikkelaars.


21
2018-06-17 07:35



Ik hou van Gitosis. Het is een behoorlijk effectieve manier om toegang te controleren op basis van openbare sleutels. - Mike Mazur
Hoe lossen deze oplossingen het probleem op van "Ik zou graag zien dat meerdere mensen naar die repository trekken"? - womble♦
kijk eens naar gitosis. die lost je probleem op. - pilif
Wanneer u de repository deelt, kunnen mensen er uit trekken. Ze zullen het waarschijnlijk moeten klonen, of een remote branch toevoegen. De documentatie die ik heb gekoppeld zal je heel duidelijk begeleiden bij het oplossen van je probleem; Ik heb alle beschreven methoden gebruikt om ontwikkelaars te helpen bij het samenwerken met Git. Voor zover ik weet, is ServerFault niet voor handhaving. - jtimberman
Ik ben het ermee eens dat ik Gitosis gebruik. Het probleem wordt opgelost door het gebruik van een enkele account die is geverifieerd door meerdere SSH-sleutels. Het wordt ook volledig zelf beheerd via git commits. - Jeremy Bouse


Kijk ook naar gitolite voor het hosten van je git repository. Gitosis wordt blijkbaar niet meer ontwikkeld.


9
2018-01-19 08:55





Een manier om machtigingen in de gedeelde repository te herstellen, zodat gebruikers geen machtigingsproblemen hebben bij het pushen, is om een ​​hook-script na update te maken dat precies dat doet. Dit zou in elke git-versie moeten werken.

Stel dat je een gedeelde repository hebt in /myrepo.git. Alle bestanden in die repository horen bij zeggen mysharedgroup. Alle gebruikers die naar die repository pushen, behoren toe mysharedgroup ook. Maak nu het volgende bestand (wijzigen mysharedgroup naar uw voorkeuren):

/myrepo.git/hooks/post-update

#!/bin/sh
chmod -R g+w . 2>/dev/null
chgrp -R mysharedgroup . 2>/dev/null

4
2017-09-27 14:35



het juiste antwoord voor wanneer gebruikers verschillende standaardgroepen hebben - Pat
Als u de setgid-bit in een map instelt, zullen bestanden die gebruikers maken dezelfde groepseigendom als de directory overnemen (als de gebruikers bij die groep horen). Zelfs als dit niet de standaardgroep van de gebruiker is. Dan is deze haak niet nodig. Dit is wat @ womble's antwoord (en mijn commentaar daarop) doen. - rescdsk
Op mijn centos7-machine, na het uitproberen van elke oplossing die op deze pagina wordt vermeld, was een variant van de bovenstaande oplossing van @ bkmks de enige optie die echt werkte (instelling van de haken post-merge en post-checkout in plaats van post-update zoals hierboven). - Mike Godin


Om de stukjes en beetjes goed advies samen te vatten uit de verschillende andere antwoorden en opmerkingen over het opzetten van een nieuwe repo:

Als je een geheel nieuwe repo opzet myrepo in /srv/git voor de groep mygroup, dit is wat je wilt:

mkdir /srv/git/myrepo.git
chgrp mygroup /srv/git/myrepo.git
git init --bare --shared /srv/git/myrepo.git
  1. de eerste regel maakt het repertorium
  2. de tweede regel stelt zijn groep in mygroup
  3. de derde regel initialiseert een lege repo met de volgende configuratie:
    1. core.bare = true: maak er een kale repo van
    2. core.sharedrepository = 1 (hetzelfde als core.sharedrepository = group): de repomap en alle later aangemaakte mappen worden beheerd door git om toe te staan mygroup lees, schrijf en voer permissies uit (met de sgid bit-set ook) om te werken met gebruikers voor wie mygroup is niet hun primaire groep)
    3. receive.denyNonFastforwards = 1: ontken niet-snel vooruit pushen naar de repo

Als u de gebruikers-, groeps- of andere gebruikersrechten wilt aanpassen, gebruik dan --shared=0NNN, waar NNN zijn de standaard gebruikers-, groeps- en andere bits voor bestanden (de execute en sgid bits aan directories zal op gepaste wijze beheerd worden door git). Dit staat bijvoorbeeld lees- en schrijftoegang voor de gebruiker toe, en alleen-lezentoegang tot de groep (en geen toegang tot andere):

git init --bare --shared=0640 /srv/git/myrepo.git

Dit biedt lees- en schrijftoegang tot de gebruiker en groep (en geen toegang tot andere):

git init --bare --shared=0660 /srv/git/myrepo.git

Dit biedt lees- en schrijftoegang tot de gebruiker en groep en alleen-lezen toegang tot andere:

git init --bare --shared=0664 /srv/git/myrepo.git

Merk op dat als u geen schrijftoegang tot de groep toestaat, het eerst moet gebruiken chown om de eigenaar van de repo in te stellen en vervolgens de git init commando als die gebruiker (om ervoor te zorgen dat de repo wordt geïnitialiseerd met de juiste eigenaar voor alle initiële bestanden en submappen).


3
2018-05-26 01:24



Meer correct dan de antwoorden met een hogere stem. - XO01