This article source: http://blog.csdn.net/bluishglc/article/details/49310125 prohibited any form of reprint, or will entrust CSDN official maintenance rights!
1 references
All relevant details can be obtained from this document:
http://git.oschina.net/progit/4-%E6%9C%8D%E5%8A%A1%E5%99%A8%E4%B8%8A%E7%9A%84-Git.html#
2 installation
Git does not have a server-side and Clint-side, and Git is installed on a git server. The simplest way to install is to use the package management tools provided directly by the system. For example Centos/rhel, you can use:
yum install git
3 protocol
GIT supports four major protocols for transmitting data: local transfer, SSH protocol, Git protocol, and HTTP protocol, so we can simply and quickly get through these four protocols.
3.1 FILE Local protocol
There is almost one possible scenario for a local protocol: the team is using a shared file system (for example, NFS), and each member of the team can access it as if it were a local file system.
3.2 SSH Protocol
SSH is the most common transport protocol for Git, which is a very mature and universal access Protocol for SSH itself, and git is a very smart choice based on SSH. In addition, SSH is the only network protocol that supports both read and write operations in four protocols .
The repo of a typical SSH protocol is this:
git clone [email protected]:/path/to/my-project.git
3.3 GIT Protocol
The Git protocol is the fastest existing transport protocol. If you're providing a public project with a lot of traffic, or a huge project that doesn't require permission to read, it's a good idea to set up a Git daemon to supply the repository. It uses the same data transfer mechanism as the SSH protocol, but eliminates the overhead of encryption and authorization.
3.4 HTTP/S Protocol
The advantage of the HTTP protocol is that it is easy to erect. A few commands are necessary to allow the world to read the contents of the repository.
Simply summarize: if it's a company project, SSH may be the only protocol your team needs to use. In the case of an open source project or allowing anonymous read-only access to the project, there is a need to support the GIT or http/s protocol in addition to the SSH protocol for others to access the read.
4 configuration
In fact git has no special configuration, but if we use SSH protocol for data transmission we need to create a full-time login and login key, so so-called "configuration" is actually SSH-related configuration.
4.1 GIT (SSH) server-side configuration
Create a git user and user group
-d /var/git git
Command This province is very simple, here to explain why we want to create this git user, This user is not to run git to create a full-time user, but only for SSH access to create . As we mentioned in the previous "SSH Protocol" section of the address format:
git clone [email protected]:/path/to/my-project.git
The "[email protected]" Here is essentially the command-line format of the user and remote host that SSH provided at login, so since we need to log in and read and write data using SSH, is it always necessary to have a login account? OK, then create a git-specific account to specifically support Git's data transfer.
In addition, we set the git user's home directory to/var/git in order to differentiate the normal login account. And this/var/git is the ideal place to put all the repository.
4.2 GIT (SSH) client side configuration
Similarly, there is no real git client configuration, or SSH login problem, is to create an SSH key pair for local use, and copy the public key to the server side of git users ~/.ssh/authorized_keys
, simply say: As long as the local can be logged into the key [email Protected] Even if the configuration of the client is completed.
This article does not repeat the configuration of SSH key login. Just to repeat a role with the scene here: the client to access the GIT server should be generated by the client key, the private key client is saved, the public key is copied to git server git user's Authorized_keys file.
5 operation
Once the configuration is complete, we can create (initialize) The repository on the server side. Assuming that the project we are creating is called "project," we should execute the following command on the server side:
cdcd project.git$ git --bare init
The parameter –bare indicates that a "bare" warehouse is created that does not contain a working directory.
Next, a client can add the repo to a remote repository and push a branch to upload the first version of the project file to the repository. The command is as follows:
cd‘initial commit‘$ git remote add origin [email protected]:/var/git/project.git$ git push origin master
Once you have a file push to the remote repository, the other clients can clone:
$ git clone [email protected]:/var/git/project.git
Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.
Git Server Setup