I. Creating Version Library and First Submission
Configure the GIT environment variable to tell git the name and email address of the current user, and the configured username and email address will be used when the version library is submitted.
#git config --global user.name "KangShuo" #git config --global user.email 2471781030@qq.com
The system sets up some git aliases
For example:
git config --system alias.st status git config --system alias.ci commit git config --system alias.co checkout git config --system alias.br branch
Turn on color display in Git command output
#git config --global color.ui true
The next step is to initialize the version library from an empty directory and name it Demo version library, which will run through this chapter.
For illustration, we use a directory named / path/to/my/workspace as the individual workspace root directory, which can be created on disk and set the right permissions.
1. First create the individual workspace root directory
#mkdir –p /path/to/my/workspace
2. Then go into the workspace root directory and create a version library with demo name. Then go into the demo version library and initialize the version library with git command.
#cd /path/to/my/workspace #mkdir demo #cd demo #git init
Or git over version 1.6.5 can run directly
#git init demo
After creating the initial demo version library, you can see that the git init command creates the hidden directory. git in the workspace root directory.
[root@localhost demo]# ls -a . .. .git [root@localhost demo]#
This hidden. git directory is the Git version library.
The directory where the. git version library is located is / path/to/my/workspace/demo, which is called workspace. There is only one. git version library, and nothing else.
3. Next, add a welcome.txt test file in the workspace, which contains a line of Hello.
Note: The file must be created in the workspace root directory, otherwise it cannot be added to the version library.
#cd /path/to/my/workspace/demo #echo "hello" > welcome.txt
4. Add this new file to the version Library
#git add welcome.txt
5. Submit this new file to the version Library
Note: The submission instructions need to be entered in the submission process, which is mandatory for Git. Otherwise, the configuration will be more cumbersome.
Specify submission instructions using the - m parameter
#git commit -m "initialized."
[master(Root submission)36 e8a7e] initialized 1 file changed, 1 insertion(+) create mode 100644 welcome.txt
From the above output information, it can be seen that:
The first line, this submission is submitted on a branch named master, and is the first submission of that branch, submitting ID36e8a7e
In the second line, the submission modifies a file containing the insertion of a line
The third line, the submission creates a new file welcome.txt
2. Why is there only one. git directory in the workspace root directory?
First, the version library. Git is located in the root directory of the workspace, where the rest of the subdirectories do not have any trace files or directories, so Git's design is much more convenient than the traditional version controller.
Version libraries in traditional version controllers are separated from working areas. For example (CVS, SVN, etc.).
CVS: The disadvantage is that the efficiency of transferring files over the network is slow.
Information leak. If the web server's directory contains the CVS directory, hackers can scan the cvs/Entries file to get the list of files in the directory, so as to get the information they want.
svn: The disadvantage is also the leak of website information. Another point is that when searching for the content of files in the workspace directory, the original copy of files in the. svn directory will double the search results and confuse the search results.
However, Git's design of putting version libraries in the workspace root directory enables all version control operations (except interoperability with other remote version libraries) to be performed locally, without the need to connect to the network to perform related operations.
Git also provides a Git grep command to better search for workspace file content
# git grep "workspace file content search"
How do you locate the version library when you execute the git command when the workspace contains subdirectories?
If you use the strace command to track disk access while executing the git status command, you will see a recursive upward process along the directory.
#strace -e 'trace=file'git status
The following example is a recursive process up the directory
execve("/usr/bin/git", ["git", "status"], [/* 25 vars */]) = 0
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpcre.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libz.so.1", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libpthread.so.0", O_RDONLY|O_CLOEXEC) = 3
open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
getcwd("/root", 4096) = 6
stat(".", {st_mode=S_IFDIR|0550, st_size=4096, ...}) = 0
stat(".git", 0x7fff9fe291c0) = -1 ENOENT (No such file or directory)
access(".git/objects", X_OK) = -1 ENOENT (No such file or directory)
access("./objects", X_OK) = -1 ENOENT (No such file or directory)
stat("..", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
chdir("..") = 0
stat(".git", 0x7fff9fe291c0) = -1 ENOENT (No such file or directory)
access(".git/objects", X_OK) = -1 ENOENT (No such file or directory)
access("./objects", X_OK) = -1 ENOENT (No such file or directory)
fatal: Not a git repository (or any of the parent directories): .git
+++ exited with 128 +++The above operations are always performed silently, as if nothing had happened.
So how do you know the exact location of the GIT repository? How do you know where the workspace's root directory is? You can use Git's underlying command.
1. First enter the workspace to establish the directory a/b/c, and then enter the directory.
#cd /path/to/my/workspace/demo/ #mkdir -p a/b/c #cd /path/to/my/workspace/demo/a/b/c
2. Display version libraries. The specific location of the git directory
#git rev-parse --git-dir /path/to/my/workspace/demo/.git
Display workspace root directory
#git rev-parse --show-toplevel /path/to/my/workspace/demo
3. Relative directories relative to the workspace root directory.
#git rev-parse --show-prefix /a/b/c/
4. Display the depth from the current directory (cd) up to the root of the workspace.
#git rev-parse --show-cdup ../../../
The version libraries in the traditional version control system are separated from the workspace. Is it safe for git to put the version libraries in the workspace directly?
It is not safe to delete the git version libraries together when the root deletion command is executed in the workspace. It seems safe to separate the version libraries from the workspace, but don't forget that other mechanisms should be introduced in order to track the workspace by the version libraries. Is there a better way?
Yes, git cloning can be used to reduce the risk of damage to version libraries caused by mixing version libraries and workspaces
The git cloning operation establishes git cloning in another disk/directory of the machine, and manually or automatically performs the push operation to the cloned version library when there is a new submission in the workspace.
If you use network protocol, you can also clone it on other machines. This makes it safer (dual backup).
3. How are the parameters of the Git config command different?
1. Version library configuration file (high priority)
#cd /path/to/my/workspace/demo/ #git config -e
2. Global Profile
#git config -e --global
3. System Configuration
# git config-e -- system (lowest priority)
Note: The Git configuration file is in INI file format.
The Git config command can be used to read and change the contents of the INI configuration file.
For example:
Read the attribute value of core. bar:
#git config core.bare
For example:
Change or set an attribute value in an INI file
#git config a.b something #git config x.y.z others
As you can see from the above, using the git config command can operate INI files very easily, and in fact can operate any other INI files.
Add configurations to the configuration file test.ini:
#GIT_CONFIG=test.ini git config a.b.c.d "hello，world"
Read the configuration from the configuration file test.ini:
#GIT_CONFIG=test.ini git config a.b.c.d Hello，world
Fourth, who completed the submission?
The global variables user.name and user.email were set for git at the beginning. What would happen if they weren't set?
Delete the settings for user.name and user.email in the git global configuration file:
#git config --unset --global user.name # git config --unset --global user.email
The two commands above have cleared user.name and user.email, and you will not see the output when you execute the following commands.
# git config user.name # git config user.email
Next, try submitting again to see how the submission process will differ, and who will be the submitter shown after submission?
allow-empty: Allows execution of blank commits
This parameter is added because Git does not perform commits by default if no changes are made to the workspace files, and blank commits are allowed with the -- allow-empty parameter.
Execute the following commands:
[root@localhost ~]# cd /path/to/my/workspace/demo [root@localhost demo]# git commit --allow-empty -m "who does commit?"
[master ddd4cba] who does commit?
Committer: root <root@localhost.localdomain>
Your name and email address are automatically set based on login name and host name. Please check that they are correct.
Or not. You can explicitly set it up by following commands to avoid this prompt information appearing again:
git config --global user.name "Your Name"
git config --global user.email you@example.com
After setting up, you can use the following command to correct the user identity used in this submission:
git commit --amend --reset-authorThe output above is due to the absence of git environment variables. If you look at the version library log at this time, you will see two submissions.
#git log --pretty=fuller
[root@localhost demo]# git log --pretty=fuller commit 5fd1f9002ac8a76a28afb803322f041712bacc7f Author: root <root@localhost.localdomain> AuthorDate: Thu Sep 6 14:28:21 2018 +0800 Commit: root <root@localhost.localdomain> CommitDate: Thu Sep 6 14:28:21 2018 +0800 who does commit? commit 36e8a7e26a06d194a56b530848f6dbef7a19df30 Author: KangShuo <2471781030@qq.com> AuthorDate: Thu Sep 6 09:59:03 2018 +0800 Commit: KangShuo <2471781030@qq.com> CommitDate: Thu Sep 6 09:59:03 2018 +0800 initialized
In order to ensure the correctness of submitter and author information at submission time, the settings of user.name and user.email need to be restored.
# git config --global user.name "KangShuo" # git config --global user.email 2471781030@qq.com
Then execute the following command to modify the latest submission and correct the author's and submitter's error messages.
#git commit --amend --allow-empty --reset-author
who does commit? # Please enter a note for your change. with '#'Starting rows will be ignored, and an empty submission # Note that the submission will be terminated. # # Submitter: root <root@localhost.localdomain> # # Located in branch master # No modification
The -- amend parameter is to fix the just submitted submission so that the wrong username and email address in the previous submission can be corrected without generating another new submission.
The allow-empty parameter allows blank submissions. Because the patch submission to be made is actually a blank submission.
The meaning of the reset-author parameter is to synchronously modify the ID of Author, otherwise it will only affect the ID of Commit. Using this parameter also resets AuthorDate information.
As you can see from the log, the latest submitted author and submitter information has been corrected.
[root@localhost demo]# git log --pretty=fuller
[root@localhost demo]# git log --pretty=fuller
commit b6ae6304ff46aca11f80549a5dc4c584b855e04f
Author: root <root@localhost.localdomain>
AuthorDate: Thu Sep 6 17:36:06 2018 +0800
Commit: root <root@localhost.localdomain>
CommitDate: Thu Sep 6 17:36:06 2018 +0800
who does commit?
commit 7a42747703686bab6d685f107b032655bb25f7e0
Author: KangShuo <2471781030@qq.com>
AuthorDate: Thu Sep 6 15:45:47 2018 +0800
Commit: KangShuo <2471781030@qq.com>
CommitDate: Thu Sep 6 15:45:47 2018 +0800
who does commit?
commit 36e8a7e26a06d194a56b530848f6dbef7a19df30
Author: KangShuo <2471781030@qq.com>
AuthorDate: Thu Sep 6 09:59:03 2018 +0800
Commit: KangShuo <2471781030@qq.com>
CommitDate: Thu Sep 6 09:59:03 2018 +0800
initialized5. Is it not safe to set the submitter's name at will?
Distributed version control systems like Git, which allow submitters to be set at will, seem too insecure.
Of course, this is also a feature of distributed control system, which can make everyone the master of git version library, but when working in a team, authorization is necessary. As a submitter, configuration variables should not be changed at will.
Redmine is a project management software for requirement management and defect tracking, which can be integrated with git version library. Git submission can directly close Bug on Redmine, and Git submission can also reflect the progress of project members.
Users in Redmine (project members) are identified by an ID, while Git's submitters are identified by a string containing user names and e-mail addresses. How can Redmine's users be associated with Git's submitters?
Redmine provides a configuration interface to set the mapping between the two. Obviously, if you change the submitter's name and email address at will when Git submits, it will destroy the user correspondence set up in Redmine software.
6. What is an order alias for?
It can satisfy users'special usage habits.
In fact, aliases can contain command parameters
# git config --global alias.ci "commit -s"
With parameters, Auto-add signature identification of submitter's name and email address during submission
7. Back up all work results
[root@localhost ~]# cd /path/to/my/workspace/ [root@localhost workspace]# ls demo [root@localhost workspace]# git clone demo demo-step-1 //Positive cloning to'demo-step-1'... //Done.