Build a Git server
GitHub is a remote warehouse that hosts open source code for free. However, for some commercial companies that regard the source code as their life, they neither want to disclose the source code nor pay protection fees to GitHub, so they can only build a Git server to use as a private warehouse.
To build a Git server, you need to prepare a machine running Linux. It is strongly recommended to use Ubuntu or Debian, so that the installation can be completed with a few simple apt commands.
Assuming that you already have a user account with sudo privileges, let’s start the installation officially.
The first step is to install git:
$ sudo apt-get install git
The second step is to create a gituser user to run the git service:
$ sudo adduser gituser
The third step is to create a certificate login:
su gituser
cd /home/gituser
mkdir .ssh && chmod 700 .ssh
touch .ssh/authorized_keys && chmod 600 .ssh/authorized_keys
Collect the public keys of all users who need to log in, which is their own id_rsa.pub file, and import all public keys into the /home/gituser/.ssh/authorized_keys file, one per line.
The fourth step is to initialize the Git warehouse:
Generally speaking, the name of the Git warehouse ends with .git. First select a directory as the Git warehouse, assuming it is /srv/sample.git, and enter the command in the /srv directory:
$ sudo git init --bare sample.git
Git will create a bare warehouse. The bare warehouse has no workspace, because the Git warehouse on the server is purely for sharing, so users are not allowed to log in to the server directly to change the workspace, and the Git warehouse on the server usually ends with .git . Then, change the owner to gituser:
$ sudo chown -R gituser:gituser sample.git
The fifth step is to disable shell login:
For security reasons, the gituser user created in the second step is not allowed to log in to the shell, which can be done by editing the /etc/passwd file. Find a line similar to the following:
gituser:x:1001:1001:,,,:/home/gituser:/bin/bash
Change to:
gituser:x:1001:1001:,,,:/home/gituser:/usr/bin/git-shell
Note: Here "/usr/bin/git-shell" should refer to the binary application of git.
In this way, the gituser user can use git normally through ssh, but cannot log in to the shell, because the git-shell we specified for the gituser user will automatically exit every time he logs in.
The sixth step is to clone the remote warehouse:
now, you can clone the remote warehouse through the git clone command, and run it on your own computer: no sudu
$ git clone gituser@server:/srv/sample.git
Cloning into 'sample'...
warning: You appear to have cloned an empty repository.
The rest of the push is simple.
submit code
git init // 初始化版本库
git add . // 添加文件到版本库（只是添加到缓存区），.代表添加文件夹下所有文件
git commit -m "first commit" // 把添加的文件提交到版本库，并填写提交备注
So far, we have completed the initialization of the code base, but the code is local and has not been submitted to the remote server, so the key point is that to submit to the remote code server, the following two steps are performed:
git remote add origin 你的远程库地址 // 把本地库与远程库关联
git push -u origin master // 第一次推送时
git push origin master // 第一次推送后，直接使用该命令即可推送修改
Push the content of the local library to the remote. Using the git push command actually pushes the current branch master to the remote. After executing this command, you will be asked to enter the user name and password, and the upload will start after the verification is passed.
Note: The user name and password need to be created through commands ssh-keygen -t rsa -C “[email protected]”, and the obtained secret key (public key) file must be placed on the git server, so as to have the authority to push the code
Manage public keys
/home/gituser/.ssh/authorized_keysIf the team is small, it is feasible to collect everyone's public key and put it in a file on the server . If the team has hundreds of people, it is impossible to play like this. At this time, Gitosis can be used to manage the public key.
We won’t introduce how to play Gitosis here. Teams with hundreds of people are basically in the top 500. I believe it is not a big problem to find a high-level Linux administrator.
Administrative rights
There are many companies that not only regard source code as life, but also regard employees as thieves. They will set up a complete set of permission control in the version control system. Whether each person has read and write permissions will be accurate to each branch or even each directory. Because Git was developed for Linux source code hosting, Git also inherits the spirit of the open source community and does not support permission control. However, because Git supports hooks, a series of scripts can be written on the server side to control submission and other operations to achieve the purpose of authority control. Gitolite is that tool.
We will not introduce Gitolite here, so don't waste your limited life in permission struggles.
Summary
• To facilitate the management of public keys, use Gitosis;
• To control permissions abnormally like SVN, use Gitolite.
On the Git server, you first need to enable RSA authentication in /etc/ssh/sshd_config:
RSAAuthentication yes
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
Create the .ssh directory under /home/git, then create the authorized_keys file, and put the id_rsa.pub inside Copy the content into the authorized_keys file
service sshd restart
Serious warnings: 1. You must ensure that the folder permissions of the root directory of the git user are 755. 2. You must ensure that the .ssh folder permissions under the root directory of the git user are 700. 3. You must ensure that the permissions of the .ssh folder under the root directory of the git user are The authorized_keys file in the .ssh folder has permissions of 600
Switch branch
git chechout branch name
The difference between git init and git init—bare
It is better to use git --bare init instead of git init when initializing the remote warehouse:
if git init is initialized with git init, the directory of the remote warehouse also contains the work tree, when the local warehouse When pushing to the remote warehouse, if the remote warehouse is on the branch of the push (if it is not on the branch of the push at that time, there is no problem), then the result after the push will not be reflected on the work tree, that is, the corresponding in the directory of the remote warehouse The file is still the previous content, you must use git reset --hard to see the content after the push.
It is best to use the following command to initialize the remote warehouse:
git --bare init
instead of:
git init
"Normal repository" refers to a GIT repository created with the "git init" command;
"Bare library" refers to the GIT library created with the "git init –bare" command;
when you create a normal library, in the working directory, in addition to the .git directory, you can also see all the sources contained in the library document. You have a native repository that can be browsed and modified (add, commit, delete, etc.).
When you create a bare library, there is only one .git directory in the working directory, and there is no file structure similar to the local library for you to browse and modify directly. But you can still use the git show command to browse, for example (the parameter is the SHA1 value of a commit):
git show 921dc435a3acd46e48e3d1e54880da62dac18fe0
Generally speaking, a bare library is often created as a shared library for everyone to work with, and everyone can push their own local modifications into it. A common naming method is to add .git after the library name, for example:
# mkdir example.git
# cd example.git
# git init --bare .
You now have a shared library called example. On your own local machine, you can do an initial check-in with the git remote add command:
// assume there’re some initial files you want to push to the bare repo you just created,
// which are placed under example directory
# cd example
# git init
# git add *
# git commit -m "My initial commit message"
# git remote add origin [email protected]:example.git
# git push -u origin master
Everyone in the project team can clone this library, and then push their own code to this library after completing local modifications.
git clone [email protected]:example.git
cd example
git push origin <local_branch_name>:<remote_branch_name>
The method of git deleting remote folders or files
is as follows, I remove all the files in src, but the local files are still kept.
git rm -r -n --cached */src/* //-n: With this parameter, when the command is executed, no files will be deleted, but a preview of the list of files to be deleted by this command will be displayed.
git rm -r --cached */src/* //finally execute the command.
git commit -m "Remove the version control of all files in the src directory" //submit
git push origin master //submit to the remote server
When setting the default branch in the git bare warehouse, an
error message appears when deleting a remote branch:
$ git push --delete origin foobar,
that is, foobar is the current branch of the remote warehouse (caused by using git clone --bare to generate a bare warehouse), because the remote warehouse is a bare warehouse, so you cannot use the normal git checkout command to switch branches. In the bare warehouse, use the following command to switch the current branch:
$ git symbolic-ref HEAD refs/heads/devel
In this way, the current branch of the bare warehouse is switched to the devel branch, and it is no problem to delete the foobar branch.
$ git push origin: foobar
This command essentially modifies the .git/HEAD file so that its content is:
ref: refs/heads/devel
fatal: Not a valid object name: 'master'.
After you need to initialize the warehouse, you need to add files to it and submit it, which can be used: git branch command to query the master branch;
git pull错误：refusing to merge unrelated histories
The problem scenario is reproduced:
I built a project locally and created a new project on github. Now I want to push the local project to the new github project.
Add remote project warehouse address to local project: git remote add origin url
Pull remote project code: git pull origin master. Error "refusing to merge unrelated histories"
Re-pull: git pull --allow-unrelated-histories origin master, success
Reason: Local projects and managed projects are completely different projects
! [Deprecated] master -> master (non-fast-forward)
can be resolved by forcing an update:
git pull -f origin dev:dev
I use Git every day, but I can't remember many commands.
Generally speaking, you only need to remember the 6 commands in the figure below for daily use. But if you use it proficiently, you may have to remember 60 to 100 commands.
Below is my list of commonly used Git commands. The translations of several proper nouns are as follows.
•Workspace: work area
•Index / Stage: temporary storage area
•Repository: warehouse area (or local warehouse)
•Remote: remote warehouse
git commit is mainly to submit the changes in the temporary storage area to the local repository
Add/delete files
Add the specified file to the staging area
$ git add [file1] [file2] …
Add the specified directory to the temporary storage area, including subdirectories
$ git add [dir]
Add all files in the current directory to the staging area
$ git add .
Ask for confirmation before adding each change
For multiple changes of the same file, it can be submitted in batches
$ git add -p
Delete the workspace file and put this deletion into the temporary storage area
$ git rm [file1] [file2] …
Stop tracking the specified file, but keep the file in the workspace
$ git rm --cached [file]
Rename the file and put this rename into the temporary storage area
$ git mv [file-original] [file-renamed]
Code submission# Submit the temporary storage area to the warehouse area
$ git commit -m [message]
Submit the specified file in the temporary storage area to the warehouse area
$ git commit [file1] [file2] … -m [message]
Submit the changes in the workspace since the last commit, directly to the warehouse area
$ git commit -a
Show all diff information when submitting
$ git commit -v
Use a new commit to replace the previous commit
If there is no new change in the code, it is used to rewrite the submission information of the last commit
$ git commit --amend -m [message]
Redo the last commit and include the new changes for the specified files
$ git commit --amend [file1] [file2] …
General steps after this:
sudo git init --bare GenerationDetection.git
sudo chown chatbot:chatbot GenerationDetection.git/