https://gitbook.cn/books/5e81adf58d6af944d1f26356/index.html
1. Install Git on the server
Switch to the root account:
su root
Check if Git is installed on the server. If the following message appears, it means that there is Git:
[root@instance-5fcyjde7 ~]# git
usage: git [--version] [--help] [-c name=value]
[--exec-path[=<path>]] [--html-path] [--man-path] [--info-path]
[-p|--paginate|--no-pager] [--no-replace-objects] [--bare]
[--git-dir=<path>] [--work-tree=<path>] [--namespace=<name>]
<command> [<args>]
The most commonly used git commands are:
add Add file contents to the index
bisect Find by binary search the change that introduced a bug
branch List, create, or delete branches
checkout Checkout a branch or paths to the working tree
clone Clone a repository into a new directory
commit Record changes to the repository
diff Show changes between commits, commit and working tree, etc
fetch Download objects and refs from another repository
grep Print lines matching a pattern
init Create an empty Git repository or reinitialize an existing one
log Show commit logs
merge Join two or more development histories together
mv Move or rename a file, a directory, or a symlink
pull Fetch from and merge with another repository or a local branch
push Update remote refs along with associated objects
rebase Forward-port local commits to the updated upstream head
reset Reset current HEAD to the specified state
rm Remove files from the working tree and from the index
show Show various types of objects
status Show the working tree status
tag Create, list, delete or verify a tag object signed with GPG
'git help -a' and 'git help -g' lists available subcommands and some
concept guides. See 'git help <command>' or 'git help <concept>'
to read about a specific subcommand or concept.
If you don't have Git, just install it. The default version installed by yum is 1.8.3.1:
yum install git
After the installation is successful, take a look at the version you installed:
git --version
2. Set up a Git account on the server side
Create a Git Linux account, this account is only used for Git private server operations, also for safety reasons.
If you do not create a new account Linux, created in their own words commonly used Linux accounts, tremor to a day rm -rf *operation, data can no more.
The password setting of the Linux Git account here is as complicated as possible. I will set it as'gitpassword' for demonstration purposes.
adduser git
passwd gitpassword
Then switch to a Git account and perform the following operations:
[root@instance-5fcyjde7 ~]# su - git
Check if the directory you are in is under the git directory:
[git@instance-5fcyjde7 ~]$ pwd
/home/git
3. Server-side key management
Create the .ssh directory. If the .ssh already exists, you can ignore this item.
Why do I need to configure the SSH public key? Do you remember that I have to configure my public key on GitHub when I am anxious to upload and upload code using GitHub.
This also means that there is no need to enter the password every time you operate the Git repository.
cd ~/
mkdir .ssh
Enter the .ssh file and create an authorized_keys file. This file is the public key of our client.
cd ~/.ssh
touch authorized_keys
Don’t forget to set permissions for authorized_keys. Many students find that they can’t log in without password because they forgot to set permissions for authorized_keys:
chmod 700 /home/git/.ssh
chmod 600 /home/git/.ssh/authorized_keys
Next, we need to put the client's public key on the Git server, and we are going back to the client to create a public key.
On our own computer, there are public and private keys. The two files are: id_rsa and id_rsa.pub.
- If it is a Windows system, the directory of the public key and private key is under C:\Users\Username.ssh.
- If it is Mac or Linux, the directory of public and private keys is here
cd ~/.ssh/. If you find that there is no public key and private key on your computer, create one yourself.
Command to create a key:
ssh-keygen -t rsa
In the process of creating the key, just click Enter all the way. No need to fill in anything. Copy the public key to the Git server, and copy the id_rsa.pub we just generated to the /home/git/.ssh/ directory of the Git server.
On the Git server, add the public key to the authorized_keys file:
cd /home/git/.ssh/
cat id_rsa.pub >> authorized_keys
How to check whether the key we configured is successful? Log in to the Git server directly at the client point to see if it is a secret-free login:
ssh git@git 服务器 ip
E.g:
ssh [email protected]
If you can log in without secret, then the server-side key configuration is successful.
4. Deploy the Git repository on the server side
We are logging in to the Git server and switching to a Git account. If the root account is switched to a Git account:
su - git
If another account is switched to a Git account:
sudo su - git
Enter the git directory:
cd ~/git
Create our first Git private server warehouse, we call it the world warehouse. Then first create a folder named world.git, and then enter this directory.
Some students asked why the folder name should be followed by .git. In fact, it is okay to name it otherwise. But careful students may have noticed, we usually on GitHub git clonesomeone else's warehouse when the warehouse behind the name, plus all the .git.
For example, the following example is actually a naming rule of GitHub for warehouse names, so we also follow GitHub's naming rule.
git clone https://github.com/youngyangyang04/NoSQLAttack.git
So our operation is:
[git@localhost git]# mkdir world.git
[git@localhost git]# cd world.git
Initialize our world warehouse:
git init --bare
If we want to create multiple warehouses, just create multiple folders and initialize them here. The operation process is the same as the world warehouse.
Now that our server-side Git warehouse is deployed, let's take a look at the client side and how to use this warehouse.
5. The client connects to the remote warehouse
Let's create a folder called world on our computer.
In fact, the naming here is arbitrary, but we want to keep in sync with the warehouse name of the Git server. This is more intuitive which warehouse we are operating.
mkdir world
cd world
Enter the world file and initialize the operation:
cd world
git init
Create a test file in the world directory and add it to Git version management:
touch test
git add test
git commit -m "add test file"
Synchronize the secondary warehouse and the remote warehouse:
git remote add origin git@git 服务器端的 ip:world.git
git push -u origin master
At this point, the test file has been submitted to our Git remote private server.
6. Git private server security issues
There are two security issues here.
6.1 Don't leak the Linux Git password
Otherwise, people can ssh git@git 服务器 IPlog on to your Git PW server. Of course, if you buy a cloud server from a cloud vendor, if someone maliciously wants to connect to your server by trying a different password link, try more than three times, the client's IP will be blocked, and the email will be blocked at the same time. Tell us where the IP can come from.
So you can rest assured that as long as we don't leak the password, basically no one will continue to try the password to log on to our Git private server at the same time.
6.2 Do not give the private key file id_rsa to others
If someone gets this private key, they can log in to our Git private server without a password. I believe that everyone will not actively give their private key to others.