如果能帮助到大家,请帮忙点赞评论,欢迎讨论!
0) gitolite原理
git clone git@xxxxx:oooo.git
->使用ssh从xxx上面拉代码.
-> xxxx上的ssh解析.ssh/authorized_keys
->authorized_keys内部指向~/bin/gitolite-shell 成功和gitolite关联
->gitolite-admin工程中提交的配置最终账户也是放到authorized_keys中
1) 安装的标准流程参考:http://gitolite.com/gitolite/install/#setup
基本的安装流程:添加git用户(作为库拥有者)
->使用将来的库管理员的sshkey安装
->添加工程和用户sshkey
2) 删除的时候应该干掉这些文件:
~/.gitolite
~/.ssh/authorized_keys
~/.gitolite.rc
~/repositories/
~/bin/
3)具体安装gitolite
->切换git用户下
->mkdir bin 创建bin目录用于安装gitolite
->从远端克隆gitolite git clone git://github.com/sitaramc/gitolite
->执行如下命令进行安装~/gitolite/install -to ~/bin
-> ~/bin/gitolite setup -pk ~/admin.pub
4)测试
还是在git用户下
ssh git@127.0.0.1
出现如下内容:
hello git, this is git@linux-dev running gitolite3 v3.5.2-4-g62fb317 on git1.8.1.2
R W gitolite-admin
R W testing
代表gitolite工作正常
成功安装后gitolite会自动生成两个仓储,一个是testing.git用来测试,另一个gitolite-admin就是用来管理gitolite的配置仓储。
5)库管理员添加用户和工程
git clone git@xxxxxxx:gitolite-admin
->添加git用户
将用户的sshkey.pub 放到gitolite-admin/keydir
->添加仓库和权限
打开gitolite-admin/conf/gitolite.conf文件, 依葫芦画瓢
->提交配置, 将配置推送到gitolite服务器
git add xxxxx
git commit -m "xxxx"
git push
6) 问题解析
remote: Empty compile time value given to use lib at hooks/update line 6
remote: Use of uninitialized value in require at hooks/update line 7.
remote: Can't locate Gitolite/Hooks/Update.pm in @INC (@INC contains: /etc/perl /usr/local/lib/perl/5.14.2 /usr/local/share/perl/5.14.2 /usr/lib/perl5 /usr/share/perl5 /usr/lib/perl/5.14 /usr/share/perl/5.14 /usr/local/lib/site_perl .) at hooks/update line 7.
remote: BEGIN failed--compilation aborted at hooks/update line 7.
remote: error: hook declined to update refs/heads/master
To git@192.168.1.27:repositories/xxx.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'git@192.168.1.27:repositories/xxx.git'
网上的大量的文章都没戳到痛处
原因是git push的时候,ssh跳过了gitolite,并且从/home中查找库, 根本原因是authorized_keys的配置有问题.
1) authorized_keys内部账户不对
2)authorized_keys文件权限不对,添加chmod a+x authorized_keys 执行权限.
3) 官方解析如下:
why bypassing gitolite causes a problem
When you bypass gitolite, you end up running your normal shell instead of the special gitolite entry point script gitolite-shell
.
This means commands (like 'info') are interpreted by the shell instead of gitolite.
It also means git operations look for repos in $HOME
.
However, gitolite places all your repos in ~/repositories
, and internally prefixes this before calling the actual git command you invoked. Thus, the pathname of the repo that you use on the client is almost never the correct pathname on the server. (This is by design. Don't argue...)
This means that, you get 2 kinds of errors if you bypass gitolite
When you use
git@server:reponame
with a key that bypasses gitolite (i.e., gets you a shell), this prefixing does not happen, and so the repo is not found. Neither a clone/fetch nor a push will work.Conversely, consider
git@server:repositories/reponame.git
. The clone operation will work -- you're using the full Unix path, and so the shell finds the repo where you said it would be. However, when you push, gitolite's update hook kicks in, and fails to run because some of the environment variables it is expecting are not present.