First, the environment
CentOS Linux release 7.5.1804 (Core)
Two, git server communication protocol
Local protocol (Local)
The most basic is the Local protocol (Local protocol), in which the remote repository is a directory in the hard disk. This is common in every team member has access to a shared file system (such as a mounted NFS), or relatively rare case of people share the same computers. The latter is not ideal, because all your code repository if forever on the same computer, more catastrophic loss may occur.
If you are using a shared file system, you can from the local version of the library clones (clone), push (push) and pull (pull). Like to clone a repository or add a remote to an existing project, use the repository path as the URL. For example, cloning a local repository, you can execute the following command
$ git clone /opt/git/project.git
or you can execute this command:
$ git clone File: ///opt/git/project.git
If at the beginning of the URL explicitly specify file: //, then Git behavior will be slightly different. If you only specify the path, Git tries to use hard links (hard link) or directly copy the files needed. If you specify file: //, Git will trigger a process usually used for network transmission of data, it is usually a lower transmission efficiency of the process. Specify file: // main objective is to obtain a no external reference (extraneous references) or object (object) of a clean copy of the library versions - usually after importing from other version control systems or some similar situations need to do so. Here we will use the normal path, because it is usually faster. To add a local repository to an existing Git project, you can execute the following command:
$ git remote add local_proj /opt/git/project.git
Then, you can update the like as push and pull on the network from a remote repository.
Advantage of
the advantages of file-based repository system is simple and direct use existing file permissions and network access. If your team has a shared file system. It is just like setting other shared directories, like the copy of a bare repository into the path everyone can access and set permissions good read / write on it. This method is quick to pull updates from someone else's working directory. If you and others worked together on a project he wants you to pull updates from the repository, run similar
git pull / home / john / project ratio command push service resumption much simpler.
Disadvantage
disadvantage of this method is generally more difficult to configure the shared file system, and access than the basic network connection, which is inconvenient access from multiple locations. If you want to push content from home, you must first mount a remote disk, compared to access the network connection, configuration inconvenient and slow. It is worth mentioning is that if you are using a similar shared mount system, this approach is not necessarily the fastest. Access your local repository speed data access speed is the same with you. On the same server, if Git allows access to the local hard disk, usually via NFS to access the repository slower than accessing via SSH. Ultimately, the agreement does not protect warehouses to avoid accidental damage. Each user has full shell access "remote" directory, there is no way to stop them from modifying or deleting files and damage to internal Git repository.
HTTP protocol
Git has two modes of communication via HTTP. Only one way available before Git 1.6.6 version, is very simple and is usually read-only mode. Git 1.6.6 version introduces a new, more intelligent protocol, so that Git can be as smart as SSH negotiation and transmission of the data. After a few years, this new HTTP protocol because of its simplicity, intelligence become very popular. The new version of the HTTP protocol generally known as "smart" HTTP protocol, the old version is generally referred to as "dumb" HTTP protocol. We first look at the new "smart" HTTP protocol.
Smart (Smart) HTTP protocol
"smart" operating mode HTTP protocol and SSH, and Git protocol similar, but runs on standard HTTP / S HTTP port and can use a variety of authentication mechanisms, which means it will be easier than using the SSH protocol more, such as using the HTTP protocol basis for an authorized user name / password, without having to set up SSH public key. Smart HTTP protocol may have been the most popular way to use Git, and it is to support like git: // protocol settings as an anonymous service can also provide authentication and encryption when transferring the same protocol like SSH. And only a URL you can have done, eliminating the need to set a different URL for different needs. If you are going to push to (general, requires) a need to authorize the server, the server will prompt you to enter a user name and password. When the server gets the data from the same. In fact, similar to the GitHub service, you see on the web page URL (for example, https: //github.com/schacon/simplegit []), and you clone, push to use (if you have permission) is the same.
Dumb (Dumb) HTTP protocol
if the server does not provide intelligent service HTTP protocol, Git client will try to use more simple "dumb" HTTP protocol. Dumb HTTP protocol in web server only the bare repository treated as ordinary files, provide file services. The beauty of dumb HTTP protocol that is simple to set up. Basically, just need a bare repository on a HTTP root directory, set a post-update hook is called on it. At this point, as long as access to a web server on your repository, you can clone your repository. Here's how to set HTTP access to the repository from:
CD $ / var / WWW / the htdocs /
$ Git clone --bare / path / to / git_project gitproject.git
$ CD gitproject.git
$ Music Videos Hooks / POST-update.sample Hooks / POST-Update
$ Hooks the chmod A + X / post-update
should do it. Git comes with the post-update hook default execute the appropriate command (git update-server-info) , to ensure the normal operation via HTTP fetching and cloning operation. This command will be executed after you push to the repository through SSH; then others can be cloned by a command like this:
$ Git clone https://example.com/gitproject.git
Here we use the Apache was installed with common path / var / www / htdocs, but you can use any static web server - just put the bare repository into the correct directory can be. Git data is the basic document provided in the form of static. Choose between a normal, will be providing read / write smart HTTP service and simple read-only dumb HTTP service. Both will rarely mixed to provide services.
优点
我们将只关注智能 HTTP 协议的优点。不同的访问方式只需要一个 URL 以及服务器只在需要授权时提示输入授权信息，这两个简便性让终端用户使用 Git 变得非常简单。相比 SSH 协议，可以使用用户名／密码授权是一个很大的优势，这样用户就不必须在使用 Git 之前先在本地生成 SSH 密钥对再把公钥上传到服务器。对非资深的使用者，或者系统上缺少 SSH 相关程序的使用者，HTTP 协议的可用性是主要的优势。与 SSH 协议类似，HTTP 协议也非常快和高效。你也可以在 HTTPS 协议上提供只读版本库的服务，如此你在传输数据的时候就可以加密数据；或者，你甚至可以让客户端使用指定的 SSL 证书。另一个好处是 HTTP/S 协议被广泛使用，一般的企业防火墙都会允许这些端口的数据通过。
缺点
在一些服务器上，架设 HTTP/S 协议的服务端会比 SSH 协议的棘手一些。除了这一点，用其他协议提供Git 服务与 “智能” HTTP 协议相比就几乎没有优势了。如果你在 HTTP 上使用需授权的推送，管理凭证会比使用 SSH 密钥认证麻烦一些。然而，你可以选择使用凭证存储工具，比如 OSX 的 Keychain 或者 Windows 的凭证管理器。参考 “凭证存储” 如何安全地保存 HTTP 密码。
SSH 协议
架设 Git 服务器时常用 SSH 协议作为传输协议。因为大多数环境下已经支持通过 SSH 访问 —— 即使没有也比较很容易架设。SSH 协议也是一个验证授权的网络协议；并且，因为其普遍性，架设和使用都很容易。通过 SSH 协议克隆版本库，你可以指定一个 ssh:// 的 URL：
$ git clone ssh://user@server/project.git
或者使用一个简短的 scp 式的写法：
$ git clone user@server:project.git
你也可以不指定用户，Git 会使用当前登录的用户名。
优势
用 SSH 协议的优势有很多。首先，SSH 架设相对简单 —— SSH 守护进程很常见，多数管理员都有使用经验，并且多数操作系统都包含了它及相关的管理工具。其次，通过 SSH 访问是安全的 —— 所有传输数据都要经过授权和加密。最后，与 HTTP/S 协议、Git 协议及本地协议一样，SSH 协议很高效，在传输前也会尽量压缩数据。
缺点
SSH 协议的缺点在于你不能通过他实现匿名访问。即便只要读取数据，使用者也要有通过 SSH 访问你的主机的权限，这使得 SSH 协议不利于开源的项目。如果你只在公司网络使用，SSH 协议可能是你唯一要用到的协议。如果你要同时提供匿名只读访问和 SSH 协议，那么你除了为自己推送架设 SSH 服务以外，还得架设一个可以让其他人访问的服务。
Git 协议
Git 协议是包含在 Git 里的一个特殊的守护进程；它监听在一个特定的端口（9418），类似于 SSH 服务，但是访问无需任何授权。要让版本库支持 Git 协议，需要先创建一个git-daemon-export-ok 文件 —— 它是 Git 协议守护进程为这个版本库提供服务的必要条件 ——但是除此之外没有任何安全措施。要么谁都可以克隆这个版本库，要么谁也不能。这意味这，通常不能通过 Git 协议推送。由于没有授权机制，一旦你开放推送操作，意味着网络上知道这个项目 URL 的人都可以向项目推送数据（所以一般不会使用）。
优点
目前，Git 协议是 Git 使用的网络传输协议里最快的。如果你的项目有很大的访问量，或者你的项目很庞大并且不需要为写进行用户授权，架设 Git 守护进程来提供服务是不错的选择。它使用与 SSH 相同的数据传输机制，但是省去了加密和授权的开销。
缺点
Git 协议缺点是缺乏授权机制。把 Git 协议作为访问项目版本库的唯一手段是不可取的。一般的做法里，会同时提供 SSH 或者 HTTPS 协议的访问服务，只让少数几个开发者有推送（写）权限，其他人通过git:// 访问只有读权限。Git 协议也许也是最难架设的。它要求有自己的守护进程，这就要配置xinetd 或者其他的程序，这些工作并不简单。它还要求防火墙开放 9418 端口，但是企业防火墙一般不会开放这个非标准端口。而大型的企业防火墙通常会封锁这个端口。
三、构建git服务器
使用共享的方式创建git服务器
1、安装Samba服务
yum install -y samba
2、创建Samba用户
2.1创建本地用户
[root@bogon ~]# useradd git_user_read # 只读用户 [root@bogon ~]# useradd git_user_write # 只写用户
2.2映射Samba用户
[root@bogon ~]# pdbedit -a git_user_read new password: # 输入密码 retype new password: # 确认密码 Unix username: git_user_read ... [root@bogon ~]# pdbedit -a git_user_write new password: # 输入密码 retype new password: # 确认密码 Unix username: git_user_read ...
3、关闭SELinux
vi /etc/selinux/config 将SELINUX=enforcing改为SELINUX=disabled # 重启生效
4、创建共享目录
[root@web ~]# mkdir /home/git_root/ [root@web ~]# chmod -R 777 /home/git_root
5、配置Samba
[root@web ~]# vim /etc/samba/smb.conf [git_dir] path = /home/git_root/ # git 根目录 comment = this is git root directory valid users = git_user_write git_user_read # 可读用户 write list = git_user_write # 可写用户
其它配置默认即可，我们只需在文件的最后加上上述代码块即可。然后开启Samba服务：
[root@web ~]# systemctl start smb [root@web ~]# systemctl start nmb
6、验证Samba配置
这里最好把防火墙关闭了，要不然有可能会出问题。
[root@web ~]# systemctl stop firewalld
验证主机：
本机 Windows 7 使用git_user_read用户登陆
虚拟主机 Centos 7 192.168.10.129 使用git_user_write用户登陆
由上面简单的动画我们可以看出git_user_read用户只有读取的权限，git_user_write用户有写入的权限。说明我们Samba的配置没有问题。下面我们开始真正进入正题
7、初始化git仓库
登陆我们的git服务器Centos 7 192.168.10.10，在/home/git_root/下创建我们的git仓库，这里我们创建了一个damo_repo。
[root@web git_root]# mkdir damo_repo [root@web git_root]# git init --bare damo_repo/ [root@web git_root]# chmod -R 777 damo_repo/
7.1clone远程仓库
这里我使用本机Windows 7 ，在我的I盘中新建了一个git_repo用于存放从git服务器拉取的数据，然后在”控制面板--凭据管理器“中添加访问凭据。
这里我添加的是git_user_write用户，因为它有写入权限。
$ git clone //192.168.10.10/git_dir/damo_repo
clone成功后我们会看到如下：
我们在仓库中随便创建个test.html文件，如下操作：
test.html文件简单写个<h1>This is test</h1> $ git add . $ git commit -m 'test' $ git push -u origin master
7.2使用192.168.10.129客户端验证。
由于192.168.10.129是Centos 7，我们的git服务器时基于Samba做的。所以这里需要在192.168.10.129上挂载192.168.10.10服务器上的git仓库。
如下操作：
[root@web home]# mount -t cifs -o username=git_user_read,password=123 //192.168.10.10/git_dir/ /mnt/ [root@web home]# mkdir git_repo # 在home目录下创建git_repo用于存储git项目 [root@web home]# cd git_repo/ [root@web git_repo]# git clone file:///mnt/damo_repo/ # 获取git仓库中的项目
然后我们会看到如下界面;
下面我们创建一个文件尝试推送查看是否可以
[root@web damo_repo]# vim abc.sh echo 'Hello World' [root@web damo_repo]# git add . [root@web damo_repo]# git commit -m 'abc' [root@web damo_repo]# git push -u origin master # 推送失败 Counting objects: 4, done. Compressing objects: 100% (2/2), done. Writing objects: 100% (3/3), 309 bytes | 0 bytes/s, done. Total 3 (delta 0), reused 0 (delta 0) remote: error: insufficient permission for adding an object to repository database ./objects remote: fatal: failed to write object error: unpack failed: unpack-objects abnormal exit To file:///mnt/damo_repo/ ! [remote rejected] master -> master (unpacker error) error: 无法推送一些引用到 'file:///mnt/damo_repo/'
失败的原因是Samba权限的问题。git_user_read用户只有读取的权限，没有写入的权限。
小结：
- 使用的是本地协议（Samba）。
- git仓库的目录权限和Samba权限配合使用对用户权限进行管理。
- 获取git服务器仓库：
如果Git服务器是本机，使用git clone file:///仓库地址。
如果Git服务器不是本机，本机是Windows，在控制面板中的凭证管理器中添加git服务器地址，用户名和密码。然后使用git clone //192.168.10.10/仓库。
如果Git服务器不是本机，本机是linux，需要使用mount命令将git服务器仓库关在到本机，然后使用git clone file:///本地挂载位置 。
使用git协议搭建git服务器
未完待续。。。。。。。。。。。。。。