Git can use four major protocols to transmit data: Local transport, SSH protocol, Git protocol, and HTTP protocol.
1 Local protocol
The remote repository is another directory on the hard disk in this protocol. This is common when each member of the team has access to a shared file system (for example, NFS), or a relatively infrequent number of people sharing the same computer. The latter is not ideal because all of your code warehouse instances are stored in the same computer, increasing the likelihood of catastrophic data loss.
If you use a shared file system, you can clone, push, and fetch in a local repository. To clone from such a warehouse or to add an existing project as a remote repository, you can use a path to the warehouse as a URL. For example, cloning a local repository can be done with the following command:
First, we build a library as a server-side (though it's locally,)
Then we create a clone this small project in a different directory, and this small project will treat/home/git/repos.git as a remote server,
Push the clone down small project repos (equivalent to SVN's submission to server) to/home/git/repos.git
Git clone/home/git/repos.git
A. Git directory is generated in the current directory under the Repos directory repos directory,
Repos directory run git remote will default to have a origin remote end, which is the source of the clone,
While Git's project has a branch, the default branch name is Master
So to push the current project to the remote end, you need to specify which branch to push to which remote side,
That GIT push origin master
(When the master branch of the project is pushed to the Origin remote side (i.e./home/git/repos.git),)/
Of course, you can add other remote terminals
Git repos$
git remote add another_server/tmp/repos.git (if/tmp/repos.git exists,)
Git repos$
Git remote
Another_server
Origin
Another user again from/home/git/repos.git clone, there is more A.java file
=============================================================================================================== ============
SSH Protocol,
in a lecture on http://blog.csdn.net/jixiuffff/archive/2010/10/26/5966852.aspx
================================================================================ Git Protocol
Next comes the Git protocol. This is a special daemon contained in a Git package that listens for a specific port (9418) that provides a similar SSH service without any authorization. Using the GIT protocol to operate the warehouse, you need to create a Git-export-daemon-ok file--it is a prerequisite for the protocol process to deliver the warehouse service--but there are no security measures in addition to the service. Either everyone can clone the Git repository, or no one (usually read-only). This also means that the protocol is usually not used for push. You can allow push operations; However, because there is no authorization mechanism, once the operation is allowed, anyone on the network who knows the URL of the project will have push permission. Needless to say, this is a very rare situation.
For example, in the/home/git directory there is a repos.git, the want to put Repos.git git://protocol access
Need to run
The GIT protocol is relatively simple to set. Basically, just run the command as a long-term daemon:
Git daemon--reuseaddr--base-path=/home/git
This is not enough, if you want to repos.git through the GIT://protocol, you need to create an empty file (as long as the file exists)
=============================================================================================================== ==========
HTTP/S Protocol
Finally there is the HTTP protocol. The beauty of HTTP or HTTPS protocol is the simplicity of erection. Basically, just put Git's pure warehouse files in the HTTP file root directory, configure a specific post-update hook (hook), it is done (git hook details see chapter seventh). From this point on, everyone who can access the Web service on the server where the Git warehouse resides can perform cloning operations
Of course, to install Apache and other Web servers