Extract from the original Git Authoritative Guide
-
Milestones can be forced to update. When the milestone is changed, can the version library that has already obtained the milestone automatically update the milestone by using the obtain or pull back operation again? The answer is no. ( View original text ) ——From page 245 -
SVN file deletion has serious side effects - the file change history is artificially fragmented（ View original text ) ——Quoted from page 119 -
Understand the source code of Git, Git is no longer mysterious. ( View original text ) ——Quoted from page 109 -
Understand the principle of Git, Git is no longer mysterious. ( View original text ) ——Quoted from page 109 -
How to use version control system correctly Do only one thing at a time: Or completed a new function, Or a bug is modified Or after writing a section, Or if you add a picture, you can submit it once. Don't remember to submit when you are off duty, then the version control system will be downgraded to a file backup system. ( View original text ) ——Quoted from page 17 -
After a modified file is registered in the submission staging area, it can continue to be modified. The content that continues to be modified will not be submitted unless the git add command is repeated for the file. At this time, the file has two versions, one in the staging area and one in the workspace. At this time, execute git commit to directly submit the content registered in the staging area. ( View original text ) ——Quoted from page 17 -
$cd /path/to/my/workspace/demo $git config -e /path/to/my/workspace/demo/.git/config (Version Library) $git config -e --global /home/xxx/.gitconfig (. gitconfig file in the user's home directory) $git config -e --system /etc/gitconfig (System level profile) Repository level profiles Global configuration file (under the user's home directory) System level configuration file (under/etc directory) Lower priority in turn（ View original text ) ——Quoted from chapter: 4.3 Thinking: git config -
What is the SHA1 hash value? Hash is a data digest algorithm (or hash algorithm), which is an important theoretical cornerstone in the field of information security The algorithm converts arbitrary length input into fixed length output through hash operation A fixed length output can be a digital digest or hash value of the corresponding input content The famous abstract algorithms are MD5 and SHA1 For example, SHA1 can process input data from zero to more than 2 million TB and output a fixed 160 bit digital digest What sha1sum command can be used to generate summary under Linux ( View original text ) ——Quoted from page 88 -
If you accidentally introduce a large file that should not be submitted: winxp.img, it will be very simple to operate. You should use the patch to submit the command. $ git rm --cached winxp.img $git commit --amend ( View original text ) ——Quoted from page 16 -
But after the initial success, CVS is also exhausted: 1. Loose RCS files on the server side lead to low efficiency in establishing milestones or branches. The more files on the server side, the slower the speed. 2. Branches and milestones are not visible because they are recorded dispersedly in various RCS files on the server side. 3. Mergers are difficult because there is no tracking of mergers, which leads to repeated mergers and serious conflicts. 4. Lack of support for atomic submission will result in incomplete data submitted by the client to the server. 5. Files with the same storage content but different file names cannot be optimized because each file is stored differently on the server side. 6. You cannot version control the renaming of files and directories. Although you can directly modify the RCS file name on the server side to save the history of the renamed file, doing so will actually destroy the history. ( View original text ) ——Quoted from page 6 -
The advantages of SVN design are: 1. It has a global version number. Every time it is submitted, The SVN version number will be automatically increased by one. This provides great convenience for the use of SVN. Recall that in the CVS era, each file has its own independent version number (RCS version number). To obtain the global version number, you can only achieve it by manually and continuously establishing milestones. 2. Atomic submission is implemented. SVN will not submit part of the contents of the document bag while the rest are not, as CVS does. 3. The file name is not restricted. Because the server no longer needs a file name similar to the client file, the file name is no longer limited by the character set and case of the server operating system. 4. File and directory renaming is also supported. ( View original text ) ——Quoted from page 8 -
The biggest anti tradition of the distributed version control system is that it does not need a centralized version library, and everyone works in the local version library created by cloning. That is to say, everyone has a complete version library. All operations such as viewing the submission log, submitting, creating milestones and branches, merging branches, and rolling back are directly completed locally without network connection. Everyone is the owner of the local version library, and there is no longer any restriction on who can submit and who cannot submit. In addition, various collaborative work models (push and pull back between version libraries, and patch file transfer, etc.) make the participation of open source projects explode. ( View original text ) ——Quoted from page 9 -
The correct way to use the version control system is to do only one thing at a time: submit once after completing a new function, modifying a bug, writing a section, or adding a picture. Don't remember to submit at the end of the day, otherwise the version control system will be downgraded to a file backup system. ( View original text ) ——Quoted from page 17 -
Display the location of the repository. git directory $ git rev-parse --git-dir Show Workspace Root $ git rev-parse --show-toplevel Relative directory relative to the workspace root directory $ git rev-parse --show-prefix Displays the depth from the current directory (cd) back (up) to the root of the workspace $ git rev-parse --show-cdup ( View original text ) ——Quoted from page 63 -
The parameter -- reset author means to synchronously modify the ID of the author. Otherwise, it will only affect the ID of the committer. ( View original text ) ——Quoted from page 66 -
◇ Although they are all M (Modified) marks, their positions are different. Before the git add command is executed, this M is in the second column (the first column is a space). After the git add command is executed, the character M is in the first column (the second column is blank). ◇ The character M in the first column means that the file in the version library is in an intermediate state - submit task (submit staging area, Stage). ◇ The character M in the second column means that the current file in the work area is in the middle state - submit task (submit temporary storage area, Stage). ( View original text ) ——Quoted from page 73 -
By calling the git diff command with different parameters, you can compare the contents of the workspace, staging area, and HEAD in pairs. (1) Workspace and Staging Area Comparison $ git diff (2) Comparison between staging area and HEAD $ git diff --cached (3) Work area and HEAD comparison $ git diff HEAD ( View original text ) ——Quoted from page 80 -
File Ignore 1. The file. gitignore can be placed in any directory 2. There are errors in ignoring the file, and the consequences are very serious 3. Ignore is only valid for untracked files, and invalid for files that have been added to the repository 4. Local exclusive ignore file One is exclusive neglect for specific version libraries. That is, set the file ignore in a file. git/info/exclude in the version library. git directory. The other is global "exclusive" neglect. That is, an ignore file specified by Git's configuration variable core.excludesfile is valid for all local version libraries. ( View original text ) ——Quoted from page 126 -
More about Git's syntax rule of ignoring files: 1. Blank lines or lines starting with a pound sign (#) in the ignored file will be ignored. 2. You can use wildcards. See the Linux manual: glob (7). For example, the asterisk (*) represents any number of characters, the question mark (?) represents a character, and the square brackets ([abc]) represent the range of optional characters. 3. If the name is preceded by a path separator (/), it indicates that the file to be ignored is in this directory, not in a subdirectory. 4. If the last side of the name is a path separator (/), it indicates the entire directory to be ignored. Files with the same name will not be ignored, otherwise files and directories with the same name will be ignored. 5. By adding an exclamation mark (!) at the front of the name, it means not to ignore it. The following file ignores the example and includes the above points: #This is a comment line -- ignored *. a # Ignore all files with. a extension ! Lib.a # However, the lib.a file or directory should not be ignored, even if *. a is ignored previously /TODO # Only the TODO files in this directory are ignored, and the TODO files in subdirectories are not ignored Build/# Ignore all files in the build/directory Doc/*. txt # Ignore files such as doc/notes.txt, but do not ignore files such as doc/server/arch.txt（ View original text ) ——Quoted from page 129 -
The git rev list command can help you study the syntax of various versions of Git. 1. A submission ID can actually represent a version list, which means all the historical submissions of the version. $ git rev-list --oneline A 2. Two or more versions are equivalent to the union of the list referred to when each version is used separately. $ git rev-list --oneline D F 3. The symbol (^) in front of a version means that the version and its historical versions are excluded. $ git rev-list --oneline ^ G D 4. The "dot" representation equivalent to the above. Use two points to connect two versions, such as G D， It is equivalent to ^ G D. $ git rev-list --oneline G..D 5. If the version is reversed, the order of the parameters is not important, but the order of the versions before and after the dot notation is important. Syntax: ^ B C $ git rev-list --oneline ^B C Syntax: C ^ B $ git rev-list --oneline C ^B Syntax: B C is equivalent to ^ B C $ git rev-list --oneline B..C Syntax: C B is equivalent to ^ C B $git rev-list --oneline C..B 6. The meaning of three-point notation is that the two versions can access it together. E.g. B C will access F 1. J excluded. $ git rev-list --oneline B...C 7. For three-point representation, the sequence of the two versions is irrelevant. In fact, r1... r2 is equivalent to r1 r2 -- not $(git merge base -- all r1 r2), so it is independent of the order. $ git rev-list --oneline C...B 8. The historical submission of a submission, except for itself, is represented by the syntax r1 ^ @. $ git rev-list --oneline B^@ 9. The submission itself does not include its history submission. Use the syntax r1 ^! express. $git r... ( View original text ) ——Quoted from page 144
