Gitosis across Windows, Linux uses conceptual full solution

Start with git, but the old think the company's code put on the top not very reassuring, after all, is a commercial code. So search the online bloggers How to build a private git server to achieve the team, the company's internal code preservation, collaboration, found a lot of articles explaining the steps but no explanation of the principle, and involved in the operation between multiple computers switch, the basic principle of the installer is not clear, I don't know what to do. The corresponding configuration, so that the installer does not know how to install the success, how to calculate the success of the installation, how to use the successful installation? Based on the solution to the problem, in order to avoid the subsequent detours of the author so brush, so that later people to see, Kam.

On the other side: first gitosis system as a code, the project synchronization platform all exist multiple computers, each computer in the gitosis system has different roles, the roles are: Gitosis server, gitosis Management client, Gitosis ordinary client, The Gitosis management client can also be logged in as a normal client, where:

(1) The Gitosis server acts as a server for uploading, storing, synchronizing and downloading the code versions of each GIT client (gitosis Normal client, gitosis management client).

(2) Gitosis the management client as the initial client, the gitosis server initializes the GIT server based on the public key generated by the Gitosis management client, configures the team project on the Gitosis server remotely, and uploads it as git. Add the normal client public key to Keydir to make it a prerequisite for free access, configure each client's access rights for each project (including the Gitosis management client, as it can also be accessed as a gitosis normal client in subsequent daily use).

(3) Gitosis The normal client, generates a public-private key pair, and copies its public key to the Gitosis management client and the corresponding configuration in the Gitosis management client has the corresponding project collaboration permissions.

I believe that you can see this page has been searched for a lot of sites, other sites only forced to tell the steps, and did not make such a detailed explanation, resulting in many people even if the correct installation configuration steps can not be installed properly, or installed correctly can not determine whether the installation is correct, So look at the above description after the installation process you should know how to install it!? But even so, it is only known, although the clear knowledge of it is only known, and why the gitosis system to be so designed? Why why? is still unclear. So for the design idea and the detailed steps I further describe for you:

Brother's current situation is to install and set up the Gitosis server ("U-server") in Ubuntu14.04, install the GIT bash client on win10, Two win10 computer as a gitosis management client and Gitosis ordinary client (hereinafter referred to as "a management host"), and the other only as a gitosis ordinary client (hereinafter referred to as "B"), and in this three computers installed, Operation to further accurately explain how the gitosis installation, how to calculate the installation, the installation of how to use.

Server Setup steps: (server: Ubuntu 14.04):

(1) < in U server >ubuntu system is installed by default Python, but gitosis is installed through Python, and relies on python-setuptools tools, so first install the Python tool:

sudo apt-get install Python-setuptools

(2) < in U server > download and install Gitosis

Create or select a folder Exp: ~/SRC

CD ~/SCR

git clone https://github.com/res0nat0r/gitosis.git (connect if you fail yourself to Google)

CD gitosis

Python setup.py Install

(3) < in U server > Add user git

sudo adduser \

--system \

--SHELL/BIN/SH \

--gecos ' git version control ' \

--group \

--disable-password \

--home/home/git \

Git

(4) < in a management host > The gitosis on the Gitosis server side (a management host) is initialized based on the public key generated by the Gitosis management client (or the Gitosis server is correct because the public key that is generated by the "A management host" is initialized to make " A management host "becomes" The Gitosis Management client "), you need to generate a key pair on the a management host.

If (a management host. SystemType = = Windows):

You should install Git bash under git bash:

ssh-keygen-t RSA This Windows git bash how to install don't ask brother we say the problem key

Return to the Id_rsa (private key) and id_rsa.pub (public key) file

else if (a management host. SystemType = = Linux)://This actually I did not try, but you can give it a try

Directly on the command line:

SSH-KEYGEN-T RSA

Return to the Id_rsa (private key) and id_rsa.pub (public key) file

Copy the id_rsa.pub file to the U server's/tmp/file///In many cases still believe the U disk!

(5) < in U server > Initialize gitosis

Sudo-h-u git gitosis-init </tmp/id_rsa.pub

(6) < in U server > Modify post-update Permissions

sudo chmod 755/home/git/repositories/gitosis-admin.git/post-update

Many of the paths on the U server are not necessarily this, in this case: Find/-name post-update

Believe me, believe Louis, you can find it!

(7) < in a managed host > while the [u server] has completed gitosis initialization with the public key of [a management host], it is necessary to clone the [U server] from the [u server] gitosis-admin.git to [ A management host] for further configuration:

git clone [email protected] hostname: GITOSIS-ADMIN.GIT//Host name can be [u server] IP on LAN

CD Gitosis-admin.git

Access to [a management host]gitosis-admin.git] The individual projects of the [U-server], and the individual projects are further managed.

For example, assign John's permissions on the Foo project on [a management host]:

gitosis.conf (file) keydir/(directory) exists under Gitosis-admin.git

copy [b host] generated public key from [Host B] (process reference step for generating public key on Host B <4>) to [a management host], copy the public key to [a management host] under the name of [host] gitosis-admin.git/keydir/, where [Host B] name can refer to the host name at the end of the generated public key: [email protected].

Further configuration of the gitosis.conf, when the gitosis.conf file is not configured, the contents of the file are:

“

[Gitosis]

[Group Gitosis-admin]

Members = [email protected]

writable = Gitosis-admin

"Where group represents [a management host] management of the Gitosis server on the project of the group, the Group for the Project Management Group Gitosis-admin, management group members only have brother's management hostname: [email protected], Its permissions for the gitosis-admin can be modified, from here can be seen gitosis developers design ideas, that gitosis managers and ordinary gitosis users no fundamental difference, Just have greater permissions to modify the Gitosis-admin project itself.

After creating the new program, the gitosis.conf file is as follows:

“

[Gitosis]

[Group Gitosis-admin]

Members = [email protected]

writable = Gitosis-admin

[Group Foo]

writable = Foo

Members = [email protected] Jew [email protected] Jewgrunhoa

”

The new project named Foo, can modify the project as Foo Project, the person who can access and modify the project (member) is:

[Email protected], [email protected]

where [email protected] itself is the Gitosis management host, after this join can also be used as gitosis client to join the Foo Project collaboration. [Email protected] is another computer in elder brother, of course, the corresponding. Pub public key file is copied under the name "Jewgrunhoa.pub" to gitosis-admin.git/keydir/.

After the gitosis.conf content modification and the public key addition in the keydir/directory is complete, enter the command under [a management host] Gitosis-admin.git:

git Add.

Git commit-am "Add foo ' s memeber!"

git push

The contents of the [a management host] configuration are synchronized to the [U server], thus adding the [email protected], [email protected] Two hosts ' access and Modify permissions under Foo on the Gitosis server.

Each gitosis client can access, modify the project to allow access on the Gitosis server, and it seems that only the Gitosis management client can create the project on the Gitosis server (other normal gitosis client lines are not yet tried), using the [email Protected] (the Gitosis management client in use) Add the Project Foo, in the following steps:

mkdir Foo

CD foo

Git init

Touch Hellokitty.txt

git Add.

Git commit-am ' first commit '

git remote add origin [email protected]:foo.git

192.168.0.108 is the IP address of the Gitosis server within the local domain

Git push Origin Master

This creates the Foo project on the gitosis server.

Further, the method of accessing the project on the <b host > Gitosis General client is:

git clone [email protected]:foo.git

CD foo

Modify the contents of the Hellokitty.txt file under foo/

Git commit-am ' change hellokitty.txt ' && git push

This completes the modification of the Hellokitty.txt file in the Foo.git and synchronizes it to the Gitosis server.

The rest of Google is pretty easy to fix.

Gitosis across Windows, Linux uses conceptual full solution