Git (wiki: En CHS is a free and open source distributed version control system developed by Linux kernel author Linus Torvalds. Large open source projects such as Linux kernel, Android, Chromium, Mono, dotnet and UE4 all use Git to manage their projects

Git code is also hosted on Github. The link is github.com/git

With centralized version control systems (open source software: SVN; Free software: CVS; Business software: Microsoft’s VSS, IBM’s Rational ClearCase)

Git advantages:

(1) Local is a full image of the repository, and therefore supports offline work

② Most operations only require access to local files and resources, and each commit is a complete copy of all files, so it is very fast




Note: Centralized version control systems such as SVN store the differences between each file and the initial version




Note: Git has a complete copy of all files for each commit, which makes it very fast that Git does not perform a differential calculation restore on all files when it goes back to a commit

(3) Powerful and fast branch function, very suitable for nonlinear development process

Git faults:

(1) Only the whole, and can not be subdirectory and branch for the unit to update, submit and other operations

② The permission of subdirectories and branches cannot be controlled independently

③ Since each commit is a complete copy of all files, it takes up more disk space

This makes source code, configuration files, and so on more suitable for Git management, whereas larger binaries such as resources tend to inflate the repository

In project practice, large binary files such as resources can be managed with Git-LFS, while UE4 is managed with GitDependencies developed by itself

The basic concept

Origin: Default remote repository name

Master: default branch name

Origin/Master: default remote branch name

HEAD: alias of the Commit at the top of the current branch, i.e. the sha-1 hash of the most recent Commit for the current branch

ORIG_HEAD: position of the last HEAD pointer. Git /ORIG_HEAD. You can use ORIG_HEAD to refer to the commit in subsequent commands

Commit: Each commit is a complete snapshot of the entire file, uniquely identified by a commitID (a 40-bit hexadecimal SHA-1 hash calculated based on the content or directory structure of the file). In a sense, Git maintains a commitID directed acyclic graph

Detached HEAD: the HEAD does not point to any branch. This can happen in one of the following situations:

Use the checkout command to jump to a commit where there is no branch

② Rease indicates the state in which conflicts are processed

③ Switch to a remote branch cache

In Git, when executing a command, be sure to know: Where are you? To whom is this order executed?

The git version used for this article is: Git version 2.13.0. Windows

Running the command line suggests using git bash (which can be started from the right-click git bash here menu) for three main reasons:

(1) When running git log and other commands that need to display multiple pages of content in Windows CMD, the CMD will be stuck (sometimes you can’t exit by pressing Q)

Git bash can use MinGW built-in Linux environment commonly used command tools

③ Git bash coloring is better for reading

Diagram common operations

Working Directory: Indicates the Working Directory. The directory tree structure at the operating system level can also be understood as a tree directory object

Stage(Index) : the staging area, which is a list of files waiting for Commit. It is implemented as a flat list of files, but can also be understood as a Tree directory object

Local Repository(History) : Local Repository. Each node of a directed acyclic graph is a Tree directory object

Remote Repository: Remote Repository. Each node of a directed acyclic graph is a Tree directory object




Note: Git checkout — <file>①② means that when changes are made in the staging area, the work area is overwritten with the changes in the staging area first

Comparison of SVN commands

svn git instructions
svn checkout git clone Check out the project
svn update

git fetch

git pull

update
svn commit

git commit

git push

submit
svn add git add add
svn mv git mv mobile
svn rm git rm delete
svn status git status Check the status
svn log git log To view the log
svn diff git diff Check the difference
svn revert

git checkout

git reset

git revert

Undo or discard modifications
svn copy

git checkout -b/-B

git branch

Create a branch
svn switch git checkout Switch branch
svn copy git tag Create a tag
svn merge

git merge

git rebase

Branch merge



File storage mechanism

Git stores use a content-addressing file system. At its core is a simple key-value database that returns a 40-bit hexadecimal SHA-1 hash as an index when any type of content is inserted into the database.

In the version repository, Git maintains the following four types of data structures: objects and indexes, and maintains and manages the revision version and historical information of projects by saving the commitID directed acyclic graph log.

Blob – one BLOB holds one version of the data of one file

Tree — represents a directory containing blob hashes, file names, subdirectory names, and other metadata for all files in the directory. Create a complete hierarchy of files and subdirectories by recursively referencing other directory trees

Commit — one commit object holds metadata for each change in the repository, and each commit object points to one version of the Git directory tree object

Tag – divided into light label and note label. A lightweight tag is actually a reference to a particular commit, and a annotated tag is a complete, verifiable object stored in Git (stored in.git/refs/tags) that also contains the tagger’s name, E-mail, log, comments, and so on

Git uses Zlib to compress and store the header information (object type: blob or tree or commit + 1 space + data content length + 1 null byte) and the object data into a file

The compressed file is named with a hexadecimal SHA-1 hash and can be decompressed to view using the pigz.exe -dz < file path. Note: The Windows version of Pigz.exe can be downloaded here

Sha1 (“blob/tree/commit “+ filesize + “\0″ + data) 7\0 sha1 (” blob foobar \ n “) = “323 fae03f4606ea9991df8befbb2fca795e648fa” note: \ n binary 0 a





Low-level commands – Parse Git objects

Git/objects-type f // Use the find command to view all files in the. Git /objects directory (recursive subdirectory)

Git rev-list –objects –all git rev-list –objects –all

git rev-list –objects –all | grep 83c4fbc43a6f187d4e8a247a1c9aced872b2315d // See SHA – 1 the hash value of 83 c4fbc43a6f187d4e8a247a1c9aced872b2315d file name

echo “Hello World!” | git hash – object – stdin / / calculation content for the Hello World! The SHA-1 hash of the file

echo “Hello World!” | git hash – object – w – stdin / / calculation content for the Hello World! The sha-1 hash of the file and is written to the current git local repository

Git hash-object readme.txt // Check the sha-1 hash of readme.txt

Git hash-object -w readme.txt // Look at the sha-1 hash of readme.txt and write it to the current git local repository

Git cat-file -p master^^{tree} git cat-file -p master^^{tree} git cat-file -p master^^{tree

100644 blob 7abd3a56703ad4a7120571967f5d06607b5e5502 README.txt

040000 tree 9f448c40e684dc38109574007c661277c815fb7e ss

Note: 040000: indicates a directory. 100644: indicates a general file. 100755: indicates an executable file

Git cat – file – p 7 abd3a56703ad4a7120571967f5d06607b5e5502 / / check the hash value for SHA – 1 7 abd3a56703ad4a7120571967f5d06607b5e5502 file content

Git show 7 abd3a56703ad4a7120571967f5d06607b5e5502 / / check the hash value for SHA – 1 7 abd3a56703ad4a7120571967f5d06607b5e5502 file content

Git cat-file -t f3961f5 // Check the type of the f3961f5 commit object. The value is “COMMIT”

Git cat-file -p f3961f5 // Check the information about the f3961f5 commit object: the information includes the Git directory (tree object), the SHA-1 hash value of the last commit object, and the Author, Date, and comment information of the commit object

tree ead34240822030a3f71df4fc351057d80d7d83f8

parent 33d5bbc5d61b024aab5078e40548c4e3da808e0e

author nicochen <[email protected]> 1537258258 +0800

committer nicochen <[email protected]> 1537258258 +0800

123 desc txt

Git cat-file -p tag1.0 // Check the lightweight tag or tag tag1.0 information

Git cat-file tag tag1.0 git cat-file tag tag1.0

git ls-tree ead34240822030a3f71df4fc351057d80d7d83f8 // See tree directory objects ead34240822030a3f71df4fc351057d80d7d83f8 contained in the blob object file and directory tree

Git ls-tree HEAD // Check the bloB file object and tree directory object contained in the tree directory object pointed to by HEAD

git verify-pack -v .git/objects/pack/pack-a9282552b62cbe3f255fbb20374695a17c1ba2a2.idx // Check the pack – a9282552b62cbe3f255fbb20374695a17c1ba2a2. Pack the contents of the package

Git update-index n.txt // Adds the n.txt file to the staging area

Git update-index –add n.txt // Add n.txt files with untracked or modified state to the staging area

git update-index –add –cacheinfo 100644 5d11580eed65ffd34b6786274a60460b3582aa7d n.txt // Use of type 100644, SHA – 1 the hash value for 5 d11580eed65ffd34b6786274a60460b3582aa7d information will track or modify the state of n.t xt added to the staging area

Git write-tree // Generates a tree object from the entire staging area and prints its SHA-1 hash

Echo “add n.t xt |” git commit – tree b7ca405196ca9e8fb4d5404b315bef9f2c841f 31 – p HEAD / / use the git Write – tree get 31 b7ca405196ca9e8fb4d5404b315bef9f2c841f tree object to create a comment to add n.t xt submission object, and will be submitted to the object’s father set to the current HEAD

Git update – ref refs/heads/master 372 aa8e425b57ca30e2974b8e7737133caaa0b7f / / if the current branch is the master, Update HEAD to git commit – tree command to get above 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submission object, at this point in the git log can see a commit record

Git write-tree –prefix=ss // Generate a tree object with the contents of the ss directory in the temporary area and print its SHA-1 hash

Git update-ref -d refs/remotes/origin/v1.0

Git update-index –chmod=+x engine_mac.sh –chmod=+x engine_mac.sh

The command of

Viewing Command Help

Git config –help // Check the git config command

Git help config //

configuration

Git config –global user.name “kekec” git config –global user.email “[email protected]” // Configure the E-mail information

Git config –global core.editor vim // Configure the default text editor to be called when Git needs you to input information

Git config –global alias.st status git config –global alias.st status

Git config –list git config –list git config –list

Git config user.name // Check the user name of the current repository

Git config-e –global // Edit the global configuration file in c:/users/< username >/.gitconfig

Git config -e // Edit the directory where the configuration file of the current repository resides:.git\config

Creating a repository

Git init // Create an empty Git code base in the current directory

Git init MyGame // create a folder called MyGame in the current directory, and then create an empty git code base init

Git directory structure:




Hooks: hook scripts executed for different operations

Info /exclude: used for file filtering, as does the.gitignore file (which must be located in the same directory as the.git folder and can be created on Windows by using the type nul >.gitignore command). The difference is that the file is not committed to the repository, so the filtering only takes effect locally and does not affect anyone else

# Ignore all files ending in.so
*.so
# Except game.so! game.soJust ignore the readme.md file in the project root directory, not including subdir/ readme.md
/README.md
Ignore all files in the.svn/ directory
.svn/
# ignore doc/notes.txt but not doc/server/arch.txt
doc/*.txt
Ignore all files with the TXT extension in the doc/ directory
doc/**/*.txtCopy the code

Logs /refs/heads: Version logs for each local branch

Logs /refs/remotes: Logs of the remote branch cache

Logs /refs/stash: Storage area data

Logs /HEAD: Records git operations

Objects: level 2 file index (split sha-1 hash into: 2 bits +38 bits), which stores commit data, BLOb file data, and tree directory data

Objects /pack: The pack file is the compressed data for the COMMIT, tree and BLOb files; The IDX file is the index of each data object in the pack file

Objects /info/ Packs: This file keeps a list of pack files for all Git libraries

Refs /heads: local branch HEAD

Refs /remotes: HEAD of each remote branch cache

Refs /tags: Information about individual note labels

COMMIT_EDITMSG: last submitted comment

Config: indicates the configuration information about the repository

Description: Warehouse description, used by GitWeb

Index: information about the staging area

HEAD: Recent commit pointing to the current branch (e.g., ref: refs/heads/master)

ORIG_HEAD: When a Git merge/git pull/git reset operation is performed, the previous version of the HEAD before the new value is recorded in OERG_HEAD to restore or roll back the previous state

FETCH_HEAD: Git Fech records all fetched branch heads in. Git /FETCH_HEAD

MERGEHEAD: Commit ID of the HEAD being merged

Packed -refs: Remote version library cache and remote label cache

Log and file status

Git reflog // Check the operation record. Note: Use HEAD@{n} to identify each operation record

Git show HEAD@{5

Git status // Check the current branch file in the staging and workspace (it displays the current branch)

Note 1: States of files staged: : staged; Status of files in the workspace: : untrack, Modified

Note 2: Empty directories in your workspace are not tracked by Git

Git status -s –ignored // see all files in the staging and working areas in clean mode

Git status-uno // Check the non-untrack status files for the staging and working areas

Git status-uall // Check the staging and workspace status files (recursive subdirectories show the files inside)

Git log // check the local repository commit record (show the current branch, HEAD pointer to which branch which commit)

Git log –stat // Check the commit record of the local repository (this will show you the current commit, which commit the HEAD pointer points to, and brief statistics on the file changes per commit)

Git log — readme.md // Check the local repository commit record for readme.md

Git log –graph — readme.md // Graphically view the local repository commit record for readme.md

Git log -p readme.md // check the local repository commit record for the readme.md file.

Git log –grep “test” // Display commit with test string in comment

Git log –author=kekec git log –author=kekec

Git log -s “SplitPath(FString &str)” // check when SplitPath(FString &str) was added to the files in the project

Git log –since=2. Weeks

Git log –since=”2 weeks 3 days 2 hours 30 minutes 59 seconds ago

Git log –after=”2018-10-7″ –before=”2018-10-12″ git log –after=”2018-10-7″ –before=”2018-10-12

Git log –after=”2018-10-7″ –until=”2018-10-12″ –before=”2018-10-12″

Note: the –since and –until tags are equivalent to the –after and –before tags, respectively

Git whatchanged readme.md // Check the local repository commit record for readme.md (including file renaming)

Git whatchanged –follow readme.md

Git log-3 // Check the last three local repository commits

Git log-3 –pretty –oneline git log-3 –pretty –oneline

Git log –graph –oneline // View local repository commit records for the current branch in graphically concise mode

Git log release –graph –oneline // View local repository commit records for the release branch in graphically concise mode

Git log –graph –oneline –no-merges git log –graph –oneline –no-merges

Git log –graph –oneline –merges — git log –graph –oneline –merges — git log –graph –oneline –merges

Git log –graph –oneline –name-only git log –graph –oneline –name-only

Git log –graph –oneline –name-status git log –graph –oneline –name-status

Git log –graph –oneline –stat — git log –graph –oneline –stat

Git log –graph –oneline –shortstat git log –graph –oneline –shortstat

Git log –graph –oneline — listener –all // See the local repository commit tree for all branches in graphical clean mode

Git log –graph –pretty=format:”%H – %an, % AD: %s” // Custom format to graphically view the local repository commit tree for all branches

Full hash of the commit object %H short hash of the commit object %T Full hash of the tree %T short hash of the tree %P Full hash of the parent %P short hash of the parent %an Author name % AE Author email address % AD Author revision date (can be customized with the –date= option) %ar Author revision date, % CN committer’s name % CE committer’s email address % CD Submission date % CR Submission date and % S submission notes are displayed as how long ago

git log master.. V5.0 // View the list of commit records that the V5.0 branch has not yet merged into the Master branch

The git log v5.0.. Master // View the list of commit records that the master branch has not yet merged into the V5.0 branch

git log master… V5.0 // git log master. Git log v5.0… master

Git shortlog -sn // Count the number of committers

Git blame readme.md // Display the latest modification information to readme.md

git show 3a6c702376168aa15a2f3d7bc98000d07a70d023 README.md // To view the README. Md file 3 a6c702376168aa15a2f3d7bc98000d07a70d023 submitted to modify content

Git show HEAD // Check the last committed changes

Git show –name-only HEAD git show –name-only HEAD

Labels (View/Create/Switch/Delete)

Git tag // lists all tags

Git tag -l ‘tag1*’ // Lists all tags starting with tag1

Git tag tag1.0 // Create a lightweight tag named tag1.0

Git tag-a tag1.0 -m “tag1.0 desc” git tag -a tag1.0 -m “tag1.0 desc” git tag -a tag1.0 -m “tag1.0 desc” git tag -a tag1.0 -m “tag1.0 desc

Git tag tag2.0 abffefc5d82078cbaea7fcbb5106ab0c21cbeba9 / / at abffefc5d82078cbaea7fcbb5106ab0c21cbeba9 submitted to create lightweight tag called tag2.0

Git tag-a tag2.0 -m “tag2.0 desc” abffefc // Create a tag named tag2.0 at the abffefc commit

Git tag -d tag2.0 // Delete the tag named tag2.0

Git show tag1.0 // View information related to the name tag1.0

Git ls-remote –tags // See all remote tags

Branch (View/Create/Switch/Delete)

Git branch // Lists all local branches

Git branch -r // Lists all remote branch cache

Git branch -a // Lists all local and remote branch caches

Git branch -av // lists all local and remote branch cache (with brief description)

Git branch -vv // Check the tracing relationship between all local and remote branches

Git branch v1.0 // create branch v1.0 under HAED of current branch

Git branch — branch v1.0 origin/v1.0 — branch v1.0 Otherwise, the command fails to be executed. 2 The v1.0 branch is not switched to the v1.0 branch

Git branch v2.0 aa8e425b57ca30e2974b8e7737133caaa0b7f / / 372 In 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submitted to create branch called v2.0 (create time don’t cut the v2.0 branch)

Git branch -m v1.0 x1.0 // rename v1.0 to x1.0

Git checkout v1.0 // switch to branch v1.0

Git checkout -b v1.0 // create and switch to v1.0 branch

Git checkout -b v1.0 // create git checkout -b v1.0 branch

Git checkout -b v1.0 5a95f2d // Create and switch to the v1.0 branch at 5a95f2d commit

Git checkout -b v1.0 tag1.0 // create and switch to the v1.0 branch at tag1.0

Git checkout -t origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0 // set origin/v1.0

Git checkout -b x1.0 -t origin/v1.0

Note 1: Before switching branches, you must process changes to the workspace (untracked files are not processed) and the staging area to switch successfully

Note 2: After a successful switch, the workspace will be set to the content of the component branch

Note 3: Commit cannot be performed in the remote branch cache. You need to create the corresponding local branch and commit to the local branch

Git checkout -f v1.0 // Force the switch to v1.0 branch and discard all changes to files in the staging area and workspace (untracked files in the workspace are not affected)

Git checkout -f -b v1.0 origin/v1.0 // < > git checkout -f -b v1.0 origin/v1.0

Git checkout – // switch to the last branch

Git branch -d v2.0 // delete branch v2.0

Git branch -d v2.0 // Delete a branch named v2.0

Git branch -dr origin/v2.0 // Delete the remote branch origin/v2.0 cache

File (add/Delete/Submit/Revoke)

Git add readme.md // Add the readme.md file from the current directory to the staging area

Git add. // Add all files in the current directory (recursive subdirectory) to the staging area

Git add -u. // Add all state-tracking files in the current directory (recursive subdirectories) to the staging area

Git add Doc/\*.txt // add all TXT files in the Doc folder (recursive subdirectory) of the current directory to the temporary area

Git rm readme.md // delete the workspace file and place the delete in the staging area (if readme.md is modified in the workspace or staging area, the command will fail)

Git rm -f readme.md // Force the deletion of the workspace file and place the deletion in the staging area (the deletion will be performed even if readme.md has been modified in the workspace or staging area)

Git rm –cached readme.md // Do not delete the files corresponding to the workspace, just delete readme.md into the staging area for submission

Git mv readme.md test.md // Rename readme.md to test.md and place the name in the staging area

Git commit -m “desc” // Add desc comment and commit all changes in the staging area to the local repository

Git commit readme.md -m “desc” // Add desc comment and commit the changes to readme.md in the staging area to the local repository

Git commit — amend-m “desc” // Add the desc comment to overwrite the previous commit with the current commit (if the last commit contained 1.txt and 2.txt changes, the current commit only contains 1.txt changes; After the command is executed, the current 1.txt file and the previous 2.txt file are stored in the local repository. If there is no commit, it is used to rewrite the log information of the last commit

Git commit -m “desc” –amend readme.txt // Add a desc comment to overwrite the last commit with the current commit in readme.txt

Git commit -a -m “desc” // Add desc comment and commit all changes in the workspace and staging area to the local repository

Git commit -am “desc” //

git commit -c b5cad94d229e72bd7aff5fe2c6f022b29c30e7a8 // 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submit information (author, the submitter, annotation, timestamp, etc.) to submit the revision

Git reset — readme.md // Discard changes to readme.md in the staging area

Git reset readme.md // discard changes to the readme.md file in the staging area

Git reset b5cad94 readme.md // Overwrite readme.md in the staging area with the readME.md version from the local repository b5cad94 commit

Git reset // Discards all file changes in the staging area (workspaces are not affected)

Git reset –mixed // –mixed is the default

Git reset –hard // Discard all changes to files in the staging area and workspace (untracked files in the workspace are not affected)

git reset –soft b5cad94d229e72bd7aff5fe2c6f022b29c30e7a8 // Only the current branch of the HEAD to 372 aa8e425b57ca30e2974b8e7737133caaa0b7f (all the files in the staging area and work area changes are not discarded)

Git reset –soft HEAD~ // only point the HEAD of the current branch to the last commit (all changes to files in the staging area and workspace are not discarded)

Git reset –soft HEAD~2

Git reset –merge <commit> // Roll back the merge or pull in the contaminated workspace

$ git pull                         (1) 
Auto-merging nitfol 
Merge made by recursive. 
nitfol                |   20 +++++---- 
... 
$ git reset --merge ORIG_HEAD      (2)Copy the code

(1) Even if you have made some local changes to your workspace, you can safely git pull if you know that what you are pulling won’t overwrite what is in your workspace.

Git reset –hard ORIG_HEAD has the side effect of emptying your workspace, which is to discard all changes that have not been added locally.

To avoid discarding the contents of your workspace, you can use Git reset –merge ORIG_HEAD, noting that –hard is replaced with –merge to avoid clearing the workspace on rollback.

Git reset –keep <commit> // Keep the workspace and discard some previous commits

Let’s say you’re editing some files, you’ve committed them, and you’re working on them, but now you realize that the current content in your workspace belongs to a different branch, unrelated to the previous commit. At this point, a new branch can be opened and the contents of the workspace remain.

$ git tag start 
$ git checkout -b branch1 
$ edit 
$ git commit ...                            (1) 
$ edit 
$ git checkout -b branch2                   (2) 
$ git reset --keep start                    (3)Copy the code

(1) This time the changes in Branch1 are submitted.

(2) At this point, it is found that the previous commit does not belong to this branch. At this time, the branch branch2 is created and switched to branch2.

(3) You can use reset –keep to clear the commit after start, but keep the workspace unchanged.

Git checkout — readme.md // — switch to readme.md branch

// Overwrite readME.md in the workspace with the changes in the staging area when readme.md is modified in the staging area

// Overwrite readme.md in the workspace with changes at the HEAD pointer in the local repository when readme.md is not in the staging area

Git checkout –. // Use the staging area and local repository to restore all files in the current directory (recursive subdirectory). Note: if there are changes in the staging area, use the staging area first

Git checkout HEAD readme.md // Commit to overwrite readme.md in the staging area and workspace using HEAD in the local repository

git checkout 9a387f22ff949fa16336508adc2284384bd6a890 README.md // Using a local repository of 9 a387f22ff949fa16336508adc2284384bd6a890 modify the staging area and the workspace. The README md

Git checkout -b v2.0 tag2.0 // create and switch to the v2.0 branch at the commit named tag2.0

Git revert – no – 3 a6c702376168aa15a2f3d7bc98000d07a70d023 / edit/rollback 3 a6c702376168aa15a2f3d7bc98000d07a70d023 commits, and then submit to the local repository

Git Revert HEAD~ // rollback the last commit of HEAD, then the vim environment edit comment will pop up. Discard the changes, use the default comment content, enter 😡 or :wq to save the currently modified comment content), and then commit to the local repository

Git revert -n HEAD~3 // Roll back the commit at HEAD~3 and do not automatically commit to the local repository

git revert -n HEAD~2.. HEAD // Roll back the two commits between HEAD and 2, HEAD. The commits are not automatically committed to the local repository

Note: Git Reset removes the commit by moving the HEAD backwards, whereas Git Revert rolls back and forth the previous commit with a new commit (the HEAD moves forward).

Check the difference

Git diff readme.md // Check the difference between the workspace and staging area of readme.md in the current directory

Git diff –cached readme.md // Check the difference between the staging area of readme.md in the current directory and the last commit in the local repository

git diff –cached 372aa8e425b57ca30e2974b8e7737133caaa0b7f README.md // View the current directory of the README. Md in the staging area and 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submit the differences between the local repository

Git diff HEAD readme.md // Check the difference between readme.md commits in the workspace and the local repository HEAD pointer in the current directory

git diff 372aa8e425b57ca30e2974b8e7737133caaa0b7f README.md // View the current directory of the README. Md in the workspace and 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submit the differences between the local repository

git diff 372aa8e425b57ca30e2974b8e7737133caaa0b7f HEAD README.md // View the current directory of the README. Md in local warehouse 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submission and submit the differences between the last time

Git diff aa8e425b57ca30e2974b8e7737133caaa0b7f 372 HEAD / / check local warehouse 372 aa8e425b57ca30e2974b8e7737133caaa0b7f submission and submit the differences between the last time

Git diff 372aa8e b5cad94 readme.md // Check the difference between the 372AA8e commit and the b5cad94 commit in the local repository for readme.md in the current directory

Note: Git diff can be changed to Git Difftool to use the external difftool (you can configure beyond compare as the default Difftool and mergetool in c:/users/< username >/.gitconfig file) to see the difference

[diff]
    tool = bc3
[difftool]
    prompt = false
[difftool "bc3"]
    cmd = "\"e:/program files (x86)/beyond compare 3/bcomp.exe\" \"$LOCAL\ \ ""$REMOTE\ ""Copy the code

Branch merge

Git merge-base Master Feature // Look for the best co-commit parent for the Master and Feature branches

Git merge merge Feature // merge the current branch Master

Git merge -m “merge test” -m “merge test” -m merge test

Git merge — merge Feature Master — merge Feature Master

Git rebase Feature // Merge the rebase Feature into the Master of the current branch

Note 1: Git rebase will first find the common ancestor node, cut all the commit records from the ancestor node, and then merge them into the Master branch.

Note 2: Git merge handles conflicts more directly, but adds some redundant commit records; Git Rebase ensures a clear and linear commit record, but it also leaves merge operations unrecorded

Git rebase: merge the Feature branch into the Master branch

Note 4: Before merging the Feature to the Master branch, you must execute git pull -r origin Feature to merge the remote branch with the local branch

Note 5: Git add = ‘UU’ > UU = ‘UU’ > UU = ‘UU’ Finally, proceed with git merge/rebase –continue to commit the merge

Note 6: The conflict content of the readme. md file is as follows

<<<<<<< HEAD 123 456 789 000 111 222 333 444 555 ss // Current branch ======= 123 456 789 000 ss tt // Feature branch >>>>>>> Feature

Note 7: You can use git MergeTool to handle conflicts using the external mergetool (you can configure Beyond Compare as the default MergeTool in c:/users/< username >/.gitconfig file).

After you have modified the current file, you can call the Git Mergetool again to handle the next conflict until all conflicts are processed, then use Git add to add the file, and finally continue with Git merge/rebase –continue to commit the merge

[merge]
    tool = bc3
[mergetool]
    prompt = false
[mergetool "bc3"]
    cmd = "\"e:/program files (x86)/beyond compare 3/bcomp.exe\" \"$LOCAL\ \ ""$REMOTE\ \ ""$BASE\ \ ""$MERGED\ ""Copy the code

Git rebase/I Feature //

pick 07c5abd Introduce OpenPGP and teach basic usage

pick de9b1eb Fix PostChecker::Post#urls

pick 3e7ee36 Hey kids, stop all the highlighting

pick fa20af3 git interactive rebase, squash, amend

# Rebase 8db7e8b.. fa20af3 onto 8db7e8b # # Commands: # p, pick = use commit # r, reword = use commit, but edit the commit message # e, edit = use commit, but stop for amending # s, squash = use commit, but meld into previous commit # f, fixup = like “squash”, but discard this commit’s log message # x, exec = run command (the rest of the line) using shell # # These lines can be re-ordered; they are executed from top to bottom. # # If you remove a line here THAT COMMIT WILL BE LOST. # # However, if you remove everything, the rebase will be aborted. # # Note that empty commits are commented out

Git merge/rebase –abort // Destroys the current merge or rebase operation

Git merge/rebase –skip //

Git merge/rebase –continue git merge/rebase –continue git merge/rebase –continue

Git merge Origin /master // After the fetch is complete, merge the remote cache master branch to the current branch

Git rebase origin/master // After the fetch is complete, you can merge the remote cache master branch rebase into the current branch

Git rebase –onto master 76cada~ // Merge current branch from commit ebase [76cada, HEAD] to master

Git cherry-pick 9a341e // Merge the 9a341e commit into the current branch. If there is no conflict, use 9a341e to commit. Otherwise, resolve the conflict first, and then proceed with Git cherry pick –continue to complete the merge commit

Git cherry – pick 371 c2… 971209 // Commit (371c2, 971209) to current branch (each commit creates a COMMIT on current branch)

Git cherry – pick 371 c2 ~… 971209 // Add commit [371c2, 971209] to current branch (each commit creates a COMMIT on current branch)

Git cherry-pick -n 9a341e d2f99e // Add the 9a341e and d2f99e commits to the current branch (no commit), and manual commit is required later

Git cherry-pick –abort // Undo the current cherry-pick operation

Git cherry-pick –quit // Clean up the current operation state and force exit the cherry-pick operation without undoing the modifications

Git cherry-pick –continue // After manually handling the conflict, git cherry-pick –continue is finally executed to complete the commit of the merge

View the remote repository

Git remote-v // Display the URL of the remote repository. Note: Since Git is distributed, there may be many remote repositories

origin https://github.com/kekec/Test.git (fetch)

origin https://github.com/kekec/Test.git (push)

Git remote-ls // Check the remote repository URL and branch information

From https://github.com/kekec/Test.git

fae0fc82d711425daa897a63137d7e1af09512ba HEAD

fae0fc82d711425daa897a63137d7e1af09512ba refs/heads/master

Git remote // Check the name of the remote repository

Git remote rename Origin test git remote rename Origin test

Git remote show origin //

* remote origin Fetch URL: https://github.com/kekec/Test.git Push URL: https://github.com/kekec/Test.git HEAD branch: Master Remote Branches: Master Tracked V3.1 Tracked Local branch configured for ‘git pull’: master merges with remote master Local refs configured for ‘git push’: Master Intermediate to Master (Fast-forwarder) V3.1 (up to date)

Git remote rm origin // Delete the. Git /config file to add information related to remote origin

Git remote add origin in. / / https://github.com/kekec/Test.git/git config file to add remote origin point to the remote repository URL (if exists, the command execution failure)

[remote "origin"]
    url = https://github.com/kekec/Test.git
    fetch = +refs/heads/*:refs/remotes/origin/*Copy the code

Git remote set – origin https://github.com/kekec/Test.git url / / modify. Git/config file to add remote origin point to the remote repository url

Git remote prune origin // Clear the remote branch cache if it does not exist in the remote repository

Remote operation

Git clone https://github.com/kekec/Test.git / / https://github.com/kekec/Test.git on the current branch of cloning to local (will create a directory called Test, Use the default name origin for the remote repository name.

git clone https://github.com/kekec/Test.git MyProject // https://github.com/kekec/Test.git on the current branch cloning to local (will create a directory called MyProject, remote warehouse name using the default name origin)

Git clone – b v1.0 v1.0 branch of HTTP: / / https://github.com/kekec/Test.git / / https://github.com/kekec/Test.git clone to a local (will create a directory called Test, Use the default name origin for the remote repository name.

Git clone – b v1.0 https://github.com/kekec/Test.git d: \ MyGame / / https://github.com/kekec/Test.git v1.0 branch cloning to d: \ MyGame directory (in d: \ MyGame to create a directory called Test, remote warehouse name using the default name origin)

Git clone -o TestPrj HTTP: / / https://github.com/kekec/Test.git / / https://github.com/kekec/Test.git on the current branch of cloning to a local (will create a directory called Test, And set the remote repository name to TestPrj.)

Git fetch origin master // Fetch the master branch status change from the remote repository (workspace files are not updated)

Git fetch // pull all branch and tag state changes from the remote repository (workspace files are not updated)

Git fetch -p // pull all branch and tag state changes from the remote repository and clear the local cache of branches and tags that have been deleted (workspace files are not updated)

Git fetch Origin –tags // Pull all tags from remote repository to local (workspace files are not updated)

Git pull < branch name >:< branch name >

Git pull origin master // Merge the remote origin/master branch into the current branch (update origin/master, origin/HEAD pointer to the latest commit)

Git pull master/https://github.com/kekec/Test.git/implement the fetch first, Merge the remote Origin /master branch into the current branch (not update the Origin /master, origin/HEAD pointer to the latest commit)

Git pull origin v1.0:master // Merge the remote Origin/V1.0 branch into the local master branch

Git pull origin // Execute the fetch and merge the corresponding remote branch into the current branch

Git pull // Perform the fetch, then merge the corresponding remote branch into the current branch (the current branch needs to store the trace relationship of the remote branch, and the current branch only has one remote repository)

Git pull -p // Perform the fetch, merge the corresponding remote branch into the current branch, and clear the local cache of deleted remote branches and tags

Git pull -r origin master // Fetch and rebase the remote origin/master branch to the master branch

Git push < remote branch name >

Git push -u origin master // Push the local repository to the master branch of the remote repository URL, and record the corresponding relationship between the current branch and the master of the remote branch in the.git/config file

Git push origin // Push the current branch to the corresponding remote branch

Git push // push the current branch to the corresponding remote branch (the branch has only one remote repository)

Git push origin-f // Use the current branch update to overwrite the corresponding remote branch (also use the current branch update if there is a conflict)

Git push origin v1.0 // remotes/origin/v1.0

Git push origin –all // Push all local branch updates to the corresponding remote branch

Git push origin tag1.0 // Update local tag1.0 to remote tag1.0

Git push Origin –tags // Update all local tags to the corresponding remote tags

Git push origin :v1.0 // Delete remote branch v1.0

Git push origin :refs/tags/tag1.0

Git push origin -d v1.0

Storage area

Git stash // Backs up all changes in the workspace to a storage area, and then discards all changes in the workspace and staging area

Git stash pop // Restores the current branch workspace with a top-stack backup (stash@{0}) and removes the top-stack backup

Git stash apply stash@{1} // Restore the current branch workspace with a backup below the top of the stash (stash@{1}), but do not remove any backups from the stash

Git stash list // Check the list of stash stacks

Git stash show -p stash@{0} // Check the contents of each file in the backup at the top of the stack

Git stash drop // Remove the top of the stack backup from the repository (not used to restore the current branch workspace)

Git stash clear // Clears the stash stack list

The workspace

Git clean-nd // detects which files and directories (untracked status) in the workspace will be deleted

Git clean-fd // Deletes files and directories in the workspace that are not tracked

The staging area

Git ls-files // query the list of files in the staging area (recursive subdirectories)

Git ls-files-s // View bloB block information for all files in the staging area

Git ls-files-s — readme.md // Check the readme.md file bloB data block information in the staging area

Other commands

Git FSCK –full // Lists all unreferenced blob, tree, commit objects

Git archive –format zip –output d:/file.zip master // Zip all files in the current branch to d:/file.zip

Git thin body

Git count-objects -v // Check git object statistics

Find the git/objects -type f -print0 | xargs 0 du – hk | sort – nr | head – 5 / / find the git repository of five largest files (du – k units in hk for KB)

Find. Git/objects -type f – size + 1 m -print0 | xargs 0 du – hm | sort – nr | head – 5 / / find the git repository size more than 1 m’s five biggest file (du – K in HM represents MB)

git verify-pack -v .git/objects/pack/pack-b340eea7566df839294b71ec91a327ca2ece0b94.idx | sort -k 3 -nr | head -5 // Look for the top five files in your compressed Git repository

git filter-branch –force –index-filter ‘git rm –cached –ignore-unmatch FramePro.cpp’ –prune-empty –tag-name-filter Cat — –all // Clean up the Framepro. CPP thoroughly from the git library history

Git for-each – ref – format = ‘delete % (refname) refs/what | git update – ref – stdin/reference/clean up all the abandoned ref

Git gc –prune=now // ① Compress all objects into a pack binary to save space and improve efficiency ② remove stale objects that are not relevant to any commit

Git reflog expire –expire=now –all

In addition to using git native commands, you can use the specialized tool BFG (Java implementation) to slim down your Git library

Classic Gitflow



(1) The Master branch stores the official release history (all commits on the Master branch are assigned a version number)

(2) Develop branch serves as the integration branch of functions

(3) Each new Feature is located in its own Feature branch, which uses the Develop branch as its parent. When the new functionality is complete, merge back into the Develop branch. New feature commits should never interact directly with the Master branch

(4) Fork a release from the Develop branch as soon as there is enough functionality to do a release (or as soon as the scheduled release date is near).

The new branch is used to start the release loop, so no new functionality can be added to the branch from this point in time. This branch should only do Bug fixing, document generation, and other release-oriented tasks.

When the release is complete, the release branch is merged into the Master branch and tagged with a version number. In addition, changes made since the release branch was created will be merged back into the Develop branch.

The Hotfix branch is used to patch production Releases quickly. Once the fix is complete, changes should be merged back into the Master (tagged) and Develop (current release) branches.

reference

Pro Git Second edition PDF

Introduction to Git

A list of common Git commands

Git remote operation details

Git Workflow

Git uses a canonical process

Git branch management policy

Summary of basic concepts and usages of GIT

Git Workflow Guide: Gitflow Workflow



“IVWEB Technology Weekly” shock online, pay attention to the public number: IVWEB community, weekly timing push quality articles.

Weekly articles collection: weekly

Team open source project: Feflow