Şu ana kadar sadece benim tarafımdan yazılabilir olan mevcut bir git repom (çıplak) var. Onu bir UNIX kullanıcı grubuna açmak istiyorum, foo, böylece foo'nun tüm üyeleri ona itebilir. Aşağıdakilerle kolayca yeni bir git deposu kurabileceğimin farkındayım :
git init --bare --shared=group repodir
chgrp -R foo repodir
Ancak mevcut bir repo dizini için eşdeğer işleme ihtiyacım var .
Yanıtlar:
repodirGruptaki kullanıcılar için çalışmak üzere mevcut bir arşiv yapmak için bunu deneyin foo:
chgrp -R foo repodir # set the group
chmod -R g+rw repodir # allow the group to read/write
chmod g+s `find repodir -type d` # new files get group id of directory
git init --bare --shared=all repodir # sets some important variables in repodir/config ("core.sharedRepository=2" and "receive.denyNonFastforwards=true")
git init --sharedYapılandırma değerini ayarlamak için mevcut bir depodaki komutu kullanabilirsiniz . chmodDosyaların izinlerini doğru bir şekilde almak için komutu da yapmanız gerekir .
git pullolarak www-dataveya her ne ise ve bunun sonucunda elde ettiğinizden ziyade kök olarak vb error: insufficient permission for adding an object to repository database .git/objects. Yanlış olan tüm dosyaların / dizinlerin sahipliğini findve -type d/ kullanarak düzelteceğimi düşündüm type -f, ancak yalnızca bu yöntem hatayı giderdi (olasılık çünkü bazı alt dizindeki bir dosya grup yazılabilir değil miydi?)
core.sharedRepositorybundan bahsedeceğini düşünüyorum - kullanıcılar tüm dosya gruplarını yazılabilir hale getirmeden işe yaramaz görünüyor.
Repo dizininde aşağıdaki komutları yürütün:
git config core.sharedRepository group
chgrp -R foo repodir
chmod -R g+w repodir
Düzenleme: Sık sık kafa karışıklığını gidermek için, groupgerçek bir anahtar kelimedir, bunu grubun adıyla değiştirmemeniz gerekir.
groupGrubun adı nerede DEĞİLDİR :)
git config core.sharedRepository devsonra yazmaya git configElde fatal: bad config value for 'core.sharedrepository' in .git/configiçinde git version 1.7.0.4(ve muhtemelen versiyonları sonra)
git config core.sharedRepository group groupgrubun adı değil, gerçek değerdir!
@David Underhill ve @kixorz cevaplarını birleştirerek , kendi (kesin) çözümümü yaptım.
Bu içindir çıplak repo ve olmayan çıplak repo. Aralarında çok az fark var ama bu şekilde daha net.
Çıplak DEPO
cd <repo.git>/ # Enter inside the git repo
git config core.sharedRepository group # Update the git's config
chgrp -R <group-name> . # Change files and directories' group
chmod -R g+w . # Change permissions
chmod g-w objects/pack/* # Git pack files should be immutable
find -type d -exec chmod g+s {} + # New files get directory's group id
nerede:
<repo.git>tipik olarak sunucudaki (örneğin my_project.git/) çıplak depo dizinidir .<group-name>git kullanıcıları için grup adıdır (örneğin kullanıcılar ).Çıplak Olmayan Depo
cd <project_dir>/ # Enter inside the project directory
git config core.sharedRepository group # Update the git's config
chgrp -R <group-name> . # Change files and directories' group
chmod -R g+w . # Change permissions
chmod g-w .git/objects/pack/* # Git pack files should be immutable
find -type d -exec chmod g+s {} + # New files get directory's group id
nerede:
<project_dir>.gitklasörü içeren proje dizinidir .<group-name>git kullanıcıları için grup adıdır (örneğin kullanıcılar ).chmod g-w objects/pack/*(çıplak depo değilse, başa ekleyin .git/)
find . -type d' hatayı artırıyorunable to execute /bin/chmod: Argument list too long
chmod g+s `find . -type d`ölçeklenmiyor. Kullanımfind -type d -exec chmod g+s {} +
chmod g-w objects/*/*. Bu depo için boş olduğu için bilgi alt dizininden emin değilim.
Bu muhtemelen gerekli değildir, ancak bunun git init --bare --sharedaynı zamanda denyNonFastForwards seçeneğini belirlediğini belirtmek gerekir .
git config receive.denyNonFastForwards true
Bu seçeneğin anlamı aşağıdaki gibidir:
receive.denyNonFastForwardsZaten ittiğiniz taahhütleri yeniden temellerseniz ve ardından tekrar itmeyi denerseniz veya başka bir şekilde uzak şubenin şu anda işaret ettiği taahhüdü içermeyen bir uzak şubeye bir taahhüt göndermeye çalışırsanız reddedilirsiniz. Bu genellikle iyi bir politikadır; ancak yeniden temelde, ne yaptığınızı bildiğinizi belirleyebilir ve uzak dalı push komutunuza bir -f bayrağıyla zorla güncelleyebilirsiniz.
( http://git-scm.com/book/en/v2/Customizing-Git-Git-Configuration adresinden )
Bir grubun okumasına / yazmasına izin vermenin yukarıdaki cevaplarına ek olarak, kullanıcıyı gruba eklemeniz de gerekir ("foo" deyin).
sudo usermod -a -G [groupname] [username]
Not: yoksa önce kullanıcı oluşturmanız gerekecektir.