问题
I have a GIT repository that I manage for my office. Because of company policy, we can't use external hosting providers such as GitHub and the like. So, i'm left to do what I can with our local network.
Everyone manages their own local repositories, but we also have a remote repository that our users push to (and are accessible to applications like Hudson and Fisheye) similar to how a central repo would work in subversion. Each user has public keys setup so they can perform passwordless-authentication to the box hosting our remote repository as well.
For our remote repository, I have them configured to be shared in "group" mode:
git config core.sharedRepository group
All of our users are also members of the git group, but that is not the primary group for many of the users. It seems when git creates or updates any objects on "push," it uses the user's primary group. Instead, I need it to use the common "git" group that each user is a member. I've seen documentation on the web previously discussing setting the sticky bit, but it seemed to differ based on the source and didn't really address the issue of creating a common group (if i'm just making files arbitrarily write-able, I might as well make them 777).
Update:
Using Matthew Flaschen's answer below
chgrp -R git repo.git
find repo.git -type d -exec chmod g+rws {} +
I was able to create a repository that everyone could push and pull from together. I'll also look into gitolite, but my needs are pretty basic, and our environment allows for user and keys to be configured automatically, so it's use isn't as key. However, I want to make sure that i'm dealing with this correct.
My repository structure includes a top-level directory (remote-repos), and subdirectories for each of my repositories (app-1.git, app-2.git, library-1.git, etc). I should be able to apply the chmod g+rws {} + to the top level directory (remote-repos) instead of each individual repo, correct? The find command
find /opt/remote-repos -type d -exec ...
Finds all directories under the /opt/remote-repos location, and executes a command on them. The command (chmod g+rws) ensures that the group can read and write these files, as well as sets the sticky bet so the specified group is always used when executing. (I have no clue as to the use of the {} + portion, I'm assuming that's related to the find exec option).
Anyway, just want to confirm that my understanding of this solution is correct.
More References:
- chmod from Wikipedia
- SetGID (or SetUID) from Wikipedia
- Git SharedRepository option discussion
回答1:
git now has a core.sharedRepository option for exactly this purpose.
I recommend:
git config core.sharedRepository group
Then, to set the initial group ownership, do:
sudo chgrp -R somegroup .
sudo find -type d -exec chmod g+s {} +
sudo chmod -R g+rw .git/objects/
in the root of the repo.
For a new repo, you can do:
git init --shared=group
Only if the above doesn't work:
chgrp git -R repo.git
find repo.git -type d -exec chmod g+rws {} +
s is the setgid flag. On directories, this means files and directories created within that directory have the same group (git in this case). Newly created subdirectories also inherit setgid.
This is similar to how the git repo is set up at my work. However, I agree you should consider an actual git server process.
回答2:
User should not use any git command with sudo permissions.
If it doesn't work without sudo permissions, make sure to check the permission of all the folder with 755 and files with 644,
Using the following commands you can reset the permissions as expected.
find /path/to/repo_folder -type d -exec chmod 755 {} \;
find /path/to/repo_folder -type f -exec chmod 644 {} \;
Above command may need to use sudo permissions.
After this activity you should commit + push all the changes to repo
It will re-create permissions for all code files in repo.
回答3:
The easiest way is to use Gitolite. I've had great success with that.
来源：https://stackoverflow.com/questions/5306768/file-permission-issues-with-sharing-a-git-remote-repository