00. Table of Contents
Article directory
01. Overview
By now there are ways to use Git to get your daily work done. However, in order to use the Git collaboration feature, you also need a remote Git repository. Although it is technically possible to push and pull from a personal repository to modify content, this method is discouraged because it is easy to confuse other people's progress if you are not careful. Additionally, you want your collaborators to be able to access the repository even when your computer is not online - having a more reliable public repository is useful. Therefore, the best way to collaborate with others is to create a shared repository that you and your collaborators have access to and can push and pull data from there.
Setting up a Git server is not difficult. First, select the communication protocol you want the server to use. In this chapter we will introduce the available protocols and their respective advantages and disadvantages. The following section explains a typical setup using those protocols and how to run them on your server. Finally, if you don’t mind hosting your code on someone else’s server and don’t want to go through the hassle of setting up and maintaining your own server, you can try one of the warehouse hosting services we introduced.
A remote repository is usually just a bare repository - that is, a repository without a current working directory. Because the repository only serves as a collaboration medium, there is no need to check the snapshot from disk; only Git data is stored. To put it simply, the bare warehouse is .gitthe content of the subdirectory in your project directory and does not contain other data.
02. Agreement
Git can use four different protocols to transmit data: Local protocol (Local), HTTP protocol, SSH (Secure Shell) protocol and Git protocol. Here, we'll discuss those protocols and the situations in which they should be used (or avoided).
2.1 Local protocols
The most basic one is the Local protocol , in which the remote version library is another directory on the same host. This is common when every member of the team has access to a shared file system (such as an NFS mount), or less commonly when multiple people share the same computer. The latter is not ideal, because if all your code repositories live on the same computer for a long time, catastrophic loss is more likely to occur.
If you use a shared file system, you can clone, push, and pull from the local repository. To clone a repository or add a remote to an existing project like this, use the repository path as the URL. For example, to clone a local repository, you can execute the following command:
$ git clone /srv/git/project.git
or
$ git clone file:///srv/git/project.git
file://Git behaves slightly differently if specified explicitly at the beginning of the URL . If you just specify a path, Git will try to use a hard link or copy the required file directly. If specified file://, Git will trigger the process usually used to transmit data over the network, so the transmission efficiency will be lower. The main purpose of specifying file://is to get a clean copy of the repository without extraneous references or objects - usually after importing from another version control system or some similar situation. We'll use the normal path here because it's usually faster.
To add a local repository to an existing Git project, execute the following command:
$ git remote add local_proj /srv/git/project.git
local_projThen, you can push and pull updates from the remote repository through the new remote repository name just like on the network.
advantage
The advantage of a file system-based repository is that it is simple and directly uses existing file permissions and network access permissions. If your team already has a shared file system, setting up a repository is easy. Just like setting up other shared directories, put a copy of the bare version library in a path that everyone can access, and set the read/write permissions. We will discuss how to export a Git on the server. Naked repository.
This is also a quick way to pull updates from someone else's working directory. If you are working on a project with someone else and they want you to pull updates from the repository, it is git pull /home/john/projectmuch easier to run a similar command than to push it to the server and then fetch it back.
shortcoming
The disadvantage of this approach is that generally shared file systems are more difficult to configure and are less convenient to access from multiple locations than basic network connection access. If you want to push content from home, you must first mount a remote disk. Compared with the access method of network connection, the configuration is inconvenient and the speed is also slow.
It is worth mentioning that this method is not necessarily the fastest if you are using a file system similar to a shared mount. The speed of accessing the local repository is the same as the speed of accessing the data. On the same server, if Git is allowed to access the local hard disk, generally accessing the repository through NFS is slower than accessing through SSH.
Ultimately, this agreement does not protect the warehouse from accidental damage. Every user has full shell permissions on the "remote" directory, and there is no way to prevent them from modifying or deleting internal Git files and corrupting the repository.
2.2 HTTP protocol
Git has two modes for communicating over HTTP. Prior to Git 1.6.6, only one method was available, which was very simple and usually in read-only mode. Git version 1.6.6 introduces a new, smarter protocol that allows Git to negotiate and transfer data as intelligently as through SSH. In the following years, this new HTTP protocol became very popular because of its simplicity and intelligence. The new version of the HTTP protocol is generally called the smart HTTP protocol, and the old version is generally called the dumb HTTP protocol. Let's first take a look at the new smart HTTP protocol.
Smart HTTP protocol
Smart HTTP operates similarly to SSH and Git protocols, except that it runs on the standard HTTP/S port and can use various HTTP authentication mechanisms, which means that it is much simpler to use than the SSH protocol. For example, the HTTP protocol can be used Username/password authorization eliminates the need to set up an SSH public key.
The Smart HTTP protocol is perhaps the most popular way to use Git. It not only supports git://setting up anonymous services like the HTTP protocol, but also provides authorization and encryption during transmission like the SSH protocol. And you can do it all with just one URL, eliminating the need to set different URLs for different needs. If you want to push to a server that requires authorization (usually it does), the server will prompt you to enter your username and password. The same goes for when getting data from the server.
In fact, for services like GitHub, the URL you see on the web page (such as https://github.com/schacon/simplegit) is the same one you use when cloning and pushing (if you have permission).
Dumb HTTP protocol
If the server does not provide services for the smart HTTP protocol, the Git client will try to use the simpler "dumb" HTTP protocol. In the dumb HTTP protocol, the web server only treats the bare version library as an ordinary file and provides file services. The beauty of the dumb HTTP protocol is that it's easy to set up. Basically, you just need to put a bare repository in the HTTP root directory and set up a hook called post-update (see Git hooks). At this point, as long as you can access your repository on the web server, you can clone your repository. Here's how to set up access to the repository over HTTP:
$ cd /var/www/htdocs/
$ git clone --bare /path/to/git_project gitproject.git
$ cd gitproject.git
$ mv hooks/post-update.sample hooks/post-update
$ chmod a+x hooks/post-update
that's it. Git's own post-updatehook will execute the appropriate command ( git update-server-info) by default to ensure that fetching and cloning operations through HTTP work properly. This command will be executed after you push to the repository via SSH; others can then clone it with a command similar to the following:
$ git clone https://example.com/gitproject.git
Here we used the usual path /var/www/htdocs set up in Apache, but you can use any static web server - just put the bare version library in the correct directory. Git's data is provided in the form of basic static files (see Git internals for details).
Typically, the choice is between a smart HTTP service that provides read/write and a simple read-only dumb HTTP service. Rarely do services mix the two.
advantage
We will only focus on the advantages of the smart HTTP protocol.
Different access methods only require one URL and the server only prompts for authorization information when authorization is required. These two simplicity make it very simple for end users to use Git. Compared with the SSH protocol, the ability to use username/password authorization is a great advantage, so that users do not have to generate an SSH key pair locally and then upload the public key to the server before using Git. For non-experienced users, or those who lack SSH-related programs on their systems, the availability of the HTTP protocol is a major advantage. Similar to the SSH protocol, the HTTP protocol is also very fast and efficient.
You can also serve a read-only repository over HTTPS, so that you can encrypt the data during transmission; or, you can even let the client use a designated SSL certificate.
Another benefit is that the HTTPS protocol is widely used, and general corporate firewalls will allow data through these ports.
shortcoming
On some servers, setting up a server using the HTTPS protocol is more difficult than using the SSH protocol. Beyond this point, there are few advantages to using other protocols to serve Git over the smart HTTP protocol.
If you're using authorized push over HTTP, managing credentials can be a bit more cumbersome than using SSH key authentication. However, you can choose to use a credential storage tool, such as Keychain for macOS or Credential Manager for Windows. See how the credential store securely stores HTTP passwords.
2.3 SSH protocol
When setting up a Git server, the SSH protocol is commonly used as the transmission protocol. Because in most environments the server already supports access via SSH - even if it doesn't it's easy to set up. The SSH protocol is also a network protocol for authenticating authorization; and, because of its ubiquity, it is easy to set up and use.
To clone a repository via SSH protocol, you can specify a ssh://URL:
$ git clone ssh://[user@]server/project.git
Or use a short scp-style notation:
$ git clone [user@]server:project.git
In both cases, if you don't specify an optional username, Git will use the name you're currently logged in with.
Advantage
There are many advantages to using the SSH protocol. First, setting up SSH is relatively simple - the SSH daemon is common, most administrators have experience using it, and most operating systems include it and related management tools. Second, access via SSH is secure - all transmitted data is authorized and encrypted. Finally, like the HTTPS protocol, Git protocol, and local protocols, the SSH protocol is very efficient and compresses data as much as possible before transmission.
shortcoming
The disadvantage of the SSH protocol is that it does not support anonymous access to Git repositories. If you use SSH, then even if you are just reading data, users must access your host through SSH, which makes the SSH protocol not conducive to open source projects. After all, people may just want to clone your warehouse and view it. If you only use it on a corporate network, the SSH protocol may be the only protocol you use. If you want to provide anonymous read-only access and the SSH protocol at the same time, then in addition to setting up an SSH service for your own push, you must also set up a service that can be accessed by others.
2.4 Git protocol
Finally, there is the Git protocol. This is a special daemon included in Git; it listens on a specific port (9418), similar to the SSH service, but does not require any authorization for access. To make the repository support the Git protocol, you need to create a git-daemon-export-okfile first - it is a necessary condition for the Git protocol daemon to provide services for this repository - but there are no security measures other than that. Either anyone can clone this repository, or no one can. This means that pushing via the Git protocol is generally not possible. Since there is no authorization mechanism, once you open the push operation, it means that anyone on the network who knows the URL of the project can push data to the project. Needless to say, very few people do this.
advantage
Currently, the Git protocol is the fastest network transmission protocol used by Git. If your project has a large number of visits, or your project is very large and does not require user authorization for writing, setting up a Git daemon to provide services is a good choice. It uses the same data transfer mechanism as SSH, but eliminates the overhead of encryption and authorization.
shortcoming
The disadvantage of the Git protocol is the lack of authorization mechanism. It is not advisable to use the Git protocol as the only means of accessing the project repository. In general practice, SSH or HTTPS protocol access services are provided at the same time, so that only a few developers have push (write) permissions, and others only have git://read permissions through access. The Git protocol is also perhaps the most difficult to set up. It requires its own daemon process, which requires configuration xinetdor systemdother programs. These tasks are not simple. It also requires the firewall to open port 9418, but enterprise firewalls generally do not open this non-standard port. Large enterprise firewalls usually block this port.
03. Set up git on the local server
3.1 Create git user
deng@local:~/test$ sudo adduser git
3.2 Switch to git user
deng@local:~/test$ su - git
密码：
git@local:~$
3.3 Create a bare warehouse
git@local:~$ git init --bare project.git
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/git/project.git/
git@local:~$
3.4 Add a link to the remote warehouse to the local warehouse
git remote add <仓库名称> <用户名>@<ip地址>:<共享仓库的绝对路径>
# 另外一个用户初始化本地仓库
deng@local:~/test/project$ git init
提示：使用 'master' 作为初始分支的名称。这个默认分支名称可能会更改。要在新仓库中
提示：配置使用初始分支名，并消除这条警告，请执行：
提示：
提示： git config --global init.defaultBranch <名称>
提示：
提示：除了 'master' 之外，通常选定的名字有 'main'、'trunk' 和 'development'。
提示：可以通过以下命令重命名刚创建的分支：
提示：
提示： git branch -m <name>
已初始化空的 Git 仓库于 /home/deng/test/project/.git/
deng@local:~/test/project$ git add *
deng@local:~/test/project$ git commit -m "初始化项目"
deng@local:~/test/project$ git remote add origin [email protected]:/home/git/project.git
deng@local:~/test/project$
3.5 Push the local warehouse to the remote server warehouse
# git push <远程仓库名> <要推送的分支>
deng@local:~/test/project$ git push origin master
The authenticity of host '10.36.100.57 (10.36.100.57)' can't be established.
ED25519 key fingerprint is SHA256:/nUDhkdz+kuI350kWGwCt0rv4HvTjjlKDtgLO2WjvvI.
This host key is known by the following other names/addresses:
~/.ssh/known_hosts:1: [hashed name]
~/.ssh/known_hosts:14: [hashed name]
~/.ssh/known_hosts:17: [hashed name]
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '10.36.100.57' (ED25519) to the list of known hosts.
枚举对象中: 241, 完成.
对象计数中: 100% (241/241), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (235/235), 完成.
写入对象中: 100% (241/241), 384.45 KiB | 4.75 MiB/s, 完成.
总共 241（差异 53），复用 0（差异 0），包复用 0
remote: 处理 delta 中: 100% (53/53), 完成.
To 10.36.100.57:/home/git/project.git
* [new branch] master -> master
deng@local:~/test/project$
04. Other git commands on the local server
4.1 Delete the remote warehouse
deng@local:~/test/project$ git remote rm origin
deng@local:~/test/project$
4.2 View remote warehouse information
deng@local:~/test/project$ git remote add origin [email protected]:/home/git/project.git
deng@local:~/test/project$ git remote -v
origin [email protected]:/home/git/project.git (fetch)
origin [email protected]:/home/git/project.git (push)
deng@local:~/test/project$
4.3 Use git push for subsequent push
deng@local:~/test/project$ vim test.c
deng@local:~/test/project$ git add test.c
deng@local:~/test/project$ git commit -m "修改test.c"
[master 1530bd4] 修改test.c
1 file changed, 3 insertions(+)
deng@local:~/test/project$ git push origin master
枚举对象中: 5, 完成.
对象计数中: 100% (5/5), 完成.
使用 4 个线程进行压缩
压缩对象中: 100% (3/3), 完成.
写入对象中: 100% (3/3), 295 字节 | 295.00 KiB/s, 完成.
总共 3（差异 2），复用 0（差异 0），包复用 0
To 10.36.100.57:/home/git/project.git
5fb6dbf..1530bd4 master -> master
deng@local:~/test/project$
4.4 Get projects from remote warehouse
git clone <用户名>@<ip地址>:<共享仓库的绝对路径>
Case
deng@local:~/test/tm$ git clone [email protected]:/home/git/project.git
正克隆到 'project'...
remote: 枚举对象中: 244, 完成.
remote: 对象计数中: 100% (244/244), 完成.
remote: 压缩对象中: 100% (185/185), 完成.
remote: 总共 244（差异 55），复用 239（差异 53），包复用 0
接收对象中: 100% (244/244), 384.67 KiB | 9.86 MiB/s, 完成.
处理 delta 中: 100% (55/55), 完成.
deng@local:~/test/tm$
4.5 Update code from remote repository
deng@local:~/test/tm/project$ git pull
已经是最新的。
deng@local:~/test/tm/project$