Git server construction in centos 6.5

1. Version Control

Version Control is a system that records changes in the content of one or more files for future reference to specific version revisions. There are three version control systems:

1. Local Version Control System

Many people are used to copying the entire project directory to save different versions, and may change the name and backup time to show the difference. The only benefit of doing so is simplicity. But there are also a lot of disadvantages: Sometimes the working directory will be confused, once the wrong file is lost data, there is no way to cancel the recovery.

To solve this problem, many local version control systems have been developed a long time ago. Most of them use a simple database to record the previous update differences of files. As shown in the following figure,

 

2. Centralized Version Control System

Centralized Version Control Systems (CVCs) allow developers on different development systems to work together. Such systems, such as CVS, subversion, and perforce, all have a single centrally managed server that stores the revision of all files, people working collaboratively connect to this server through the client to retrieve the latest files or submit updates. Over the years, this has become the standard practice of version control systems.

 

3. distributed version control system

Distributed version control system (DVCs), such as git, mercurial, bazaar, and darcs. The client does not only extract snapshots of the latest versions, instead, the code repository is fully mirrored. In this way, any server that works collaboratively can be recovered from a local warehouse from any image. Because every extraction operation is actually a complete backup of the code repository,

Furthermore, many such systems can specify to interact with several different remote code repositories. By default, You can collaborate with people in different teams in the same project. You can set different collaboration processes as needed, such as hierarchical workflow, which cannot be implemented in previous centralized systems.

 

2. About git

Git is a perfect Implementation of the distributed version control system. Its basic differences with the centralized version control system SVN are as follows:

• Git is distributed, while SVN is not

  Git and SVN have their own centralized version libraries or servers. However, git is more inclined to be used in the distributed mode, that is, each developer will clone a version library on their own machine after chect out code on the central version Library/server.

• Git stores the content in metadata mode, while SVN stores the content by file

  All resource control systems hide the object metadata in a folder such as. SVN and. CVs. If you compare the size of the. Git directory with that of. SVN, you will find that they are quite different. Because the. Git directory is a clone version library on your machine that owns everything on the central version library, such as tags, branches, and version records.

• Git branch and SVN Branch

  The branch of SVN is another directory in the version library, while the branch of git is a snapshot of the entire version library, and can be quickly switched between several branches under the same working directory.

• Git does not have a global version number, while SVN does

  The SVN version number is actually a source code snapshot of any corresponding time. Git does not have such a global version number, which is also the biggest feature missing by git.

• The content integrity of git is better than that of SVN

  Git uses the SHA-1 hash algorithm for content storage. This ensures the integrity of the Code content and reduces the damage to the version library in case of disk or network problems.

 

The basic workflow of git is as follows:

• Modify some files in the working directory.

• Take a snapshot of the modified file and save it to the temporary storage area.

• Submit the updates and permanently dump the file snapshots saved in the temporary storage area to the GIT directory.

 

3. Git server Construction

1. Environment deployment

System Environment: SERVER: centos 6.5, IP: 192.168.56.1

Client: centos 6.5, IP: 192.168.56.101

Software Version: SERVER: source code compilation and installation, git-1.9.0.tar.gz

Client: Yum online installation mechanism

 

2. Installation

2.1 server side:

# Yum install curl-devel expat-devel gettext-devel OpenSSL-devel zlib-devel Perl-devel

# Wget http://git-core.googlecode.com/files/git-1.9.0.tar.gz

# Tar zxvf git-1.9.0.tar.gz

# Cd git-1.9.0

# Make prefix =/usr/local all

# Make prefix =/usr/local install # Run as the root user

 

View the version: git -- version

Git version 1.9.0

 

Install gitosis: gitosis is a git user permission management system. It manages user permissions by managing the/home/git/. Ssh/authorized_key file on the server. It is a python module package.

# Yum install Python-setuptools

# Git clone git: // github.com/res0nat0r/gitosis.git

# Cd gitosis/

# Python setup. py install

If finished processing dependencies for gitosis = 0.2 is displayed, the request is successful.

 

2.2 Client installation:

# Yum install git

# Git -- version

Git version 1.7.1

 

3. Ssh settings

The client generates the key and uploads it to the server:

# Ssh-keygen-T RSA

# SCP ~ /. Ssh/id_rsa.pub [email protected]: ~ /

 

Check the uploaded key on the server: ls ~ /Id_rsa.pub

 

4. Generate git users on the server, use git users, and initialize gitosis

Add User git:

# Useradd-r-s/bin/sh-C 'git version control'-D/home/git

Set permissions:

# Mkdir-P/home/git

# Chown git: git/home/git

 

Generate a management database on the server:

# Sudo-H-u git gitosis-init <~ /Id_rsa.pub

Initialized empty git repository in/home/git // repositories/gitosis-admin.git/reinitialized existing git repository in/home/git/repositories/gitosis-admin.git/

Note:

1. The generated gitosis-Admin is the GIT user access permission management library. gitosis manages the access permissions of all git libraries through this git library.

2. After initialization, the owner of the public key can modify the special git repository used to configure gitosis.

 

Modify the upload permission:

# Chmod 755/home/git/repositories/gitosis-admin.git/hooks/post-Update

 

5. CLIENT Export Management

# Mkdir-P/Git-repo/

# Cd/Git-repo/

# Git clone [email protected]: gitosis-admin.git

# Cd gitosis-Admin

# Find.

./gitosis.conf

./keydir

./keydir/[email protected]

Note:

gitosis.confControl file used to set users, warehouses, and permissions

The keydir directory stores all the places with the public key of the user with access permissions.

./Keydir/[email protected]: As described earlier, this user has access permissions.

 

6. Create and set a management project on the client

# Cd/Git-repo/gitosis-Admin

View uploaded keys

# Ls keydir/

[Email protected]

 

Authorization and permission Control

# Vim gitosis. conf

[Gitosis]

[Group gitosis-admin]
Writable = gitosis-Admin
Members = [email protected] # display that the user [email protected] is the owner of the initialized gitosis public key and the only person who can manage the gitosis-Admin Project

[Group jay_fans] # group name
Members = [email protected] # key Username
Writable = Git-test # project name

 

7. Initially, add and use the project Git-test

# Cd/Git-Repo

# Mkdir Git-test

# Cd Git-test

# Git init

# Touch readme

# Git add.

# Git commit-a-m "init Git-test"

# Git remote add origin [email protected]: git-test.git

# Git push origin master

Note: Before pushing data to the server for the first time in the new project Git-test, you must set the server address as a remote repository, however, you do not need to manually create the bare repository of the project on the server beforehand-gitosis will be automatically created when the first push is encountered.

 

8. Add other member public keys on the client to the system: add the user's public key to the keydir directory.

# Cd/Git-repo/gitosis-Admin

# Cp/path/to/member/public/key keydir/

# Git add keydir/member. Pub

Modify gitosis. conf

[Group jay_fans] # group name
Members = Jay # New Key Username
Writable = Git-test

 

Submit changes:

# Git commit-a-m "granted Jay commit rights to git-test"

# Git push

Note: gitosis is actually a slave server/home/git /. gitosis. if the conf file reads information, the new permission information will be written to the file through the above operations. If the configuration is incorrect, the push permission will be lost, you can modify the file to reset it. If you manually edit the file, it will be maintained until the next timegitosis-adminPush the configuration content of the new version.

 

Run the following command to obtain the Code:

# Git clone [email protected]: git-test.git

 

4. Use of GitHub

GitHub is a website hosting git projects. It charges fees for closed-source projects, while open-source projects are free of charge. The steps for code release and hosting using GitHub are as follows:

1. log on to the GitHub website https://github.com/, apply for a GitHub account, and create a repository named GitHub-test

 

2. Install the GIT client (Linux)

# Yum install git Git-Gui

 

3. Generate a key pair and copy it to the GitHub website.

# Ssh-keygen-t rsa-c "[email protected]"

[Email protected] email account used to register GitHub for you

 

Log on to GitHub and click Edit your profile-> SSH keys to add content in./. Ssh/id_rsa.pub.

 

4. Set SSH without entering a password

# Eval 'ssh-agent'

# Ssh-add

 

5. Test whether GitHub can be connected.

# SSH [email protected]

Pty allocation request failed on channel 0
Hi rangochan! You 've successfully authenticated, but GitHub does not provide shell access.
Connection to github.com closed.

Connection successful

 

6. Configure git global user configuration

# Git config -- global user. name xxx

# Git config -- global user. Email [email protected]

Xxx and [email protected] are GitHub account names and email addresses respectively.

 

7. Create a local project

# Mkdir GitHub-test

# Cd GitHub-test/

# Git init

# Touch readme

# Git add readme

# Git commit-m' my first commit'

 

Define Remote Server alias Origin

# Git remote add origin [email protected]: xxx/github-test.git

 

Merge local and remote operations. The local default is master.

# Git push origin master

When GitHub uses XXX to modify GitHub-test, the following error occurs because the local snapshot is inconsistent with that on the remote server of GitHub:

! [Rejected] Master-> master (fetch first)
Error: failed to push some refs to '[email protected]: xxx/puppet'
Hint: updates were rejected because the remote contains work that you do
Hint: Not Have locally. This is usually caused by another repository pushing
Hint: to the same ref. You may be want to first integrate the remote changes
Hint: (e.g., 'git pull... ') before pushing again.
Hint: see the 'note about fast-forwards 'in 'git push -- help' for details.

Solution:

Update the changes made in the GitHub project using the pull sub-command.

# Git pull origin master

Then execute git push origin master.

Counting objects: 8, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (5/5), done.
Writing objects: 100% (7/7), 714 bytes | 0 bytes/s, done.
Total 7 (delta 0), reused 0 (delta 0)

 

Log on to the https://github.com/xxx/github-test to view the GitHub-test project

 

8. Update files

# Vim readme

Just for test

 

Automatic commit to change files

# Git commit-

 

Update to remote

# Git push origin master

 

9. Create and merge branches

# Git Branch

* Master

Displays that the current branch is a master node.

# Git Branch New-branch

Create Branch

# Git checkout New-branch

Switch to new branch

# Vi check. py

Create a new file

 

# Git add check. py
# Git commit-a-m "added a Python script"

Commit to local git

# Git push origin New-feature
Merge to remote server

 

If the new-branch is mature, it can be merged into the master
# Git checkout master

# Git merge New-branch

# Git Branch

* Master
New-banch

 

# Git push
Execute merge. Updates in New-branch are also merged in master.

Log on to GitHub and click "Switch branches" to change the branch to view the code of different branches.