Articles Catalogue
Git Advantage
Traditional version control tools such as CVS and SVN are centralized version control, and version libraries are centralized stored in the central processor. Git implements distributed version control. Everyone has a complete version library on his computer. This design has two main advantages:
- History version information can also be obtained offline.
- The problem of single point failure is avoided.
Common Git commands
git init
Using git init, a folder can be initialized to a Git project. After initialization, a new hidden folder. git will appear in the folder.
For example, initialize C: git to a Git project.
$ cd C:\git $ git init Initialized empty Git repository in C:/git/.git/
git status
A Git project can be divided into three parts: workspace, temporary area and version library.
A workspace is the current workspace, the file in the Git folder.
The temporary area is located between the workspace and the version Library in the hidden folder. git, which is used to cache files to be submitted in the workspace.
Version libraries are the final area, and the content submitted to the version libraries is saved as a version of the project.
For example, create a new folder in C: git, test.txt, and view it with git status
$ git status On branch master No commits yet Untracked files: (use "git add <file>..." to include in what will be committed) test.txt nothing added to commit but untracked files present (use "git add" to track)
.gitignore
Generally, we don't need to include some files in Git's management, nor do we want them to always appear in the list of untracked files. Usually these are automatically generated files, such as log files, or temporary files created during compilation. In this case, we can create a file called. gitignore that lists the file patterns to be ignored.
For example, ignore all files ending in. o or. a
$ cat .gitignore *.[oa]
git add
The git add command copies something in the workspace to the temporary area.
For example, add the C: git test. TXT added above to the temporary storage area.
$ git add test.txt $ git status On branch master No commits yet Changes to be committed: (use "git rm --cached <file>..." to unstage) new file: test.txt
git commit
The git commit command submits the contents of the temporary area to the version library and points the HEAD pointer to the version to indicate that it is the current version.
When git commit is executed, a text box pops up and the corresponding submitted instructions are entered. Or use git commit --m "XXX" to submit a shorter explanation.
For example, add the above cached C: git test. txt to the version library.
$ git commit [master (root-commit) 62beab5] new text 1 file changed, 0 insertions(+), 0 deletions(-) create mode 100644 test.txt $ git status On branch master nothing to commit, working tree clean
The git commit-a command allows you to skip git add and temporarily save all track ed files and submit them to the version library.
The git commit-amend command submission temporary area covers the version pointed by the current HEAD pointer and is the "regret medicine" of GIT commit.
git diff
The gid diff command treats the contents in the temporary area as the original version, and the contents in the workspace as the current version, comparing their differences.
For example, modify the content in C: git test. txt and call git diff to see the difference
$ git diff diff --git a/test.txt b/test.txt index e69de29..88c6620 100644 --- a/test.txt +++ b/test.txt @@ -0,0 +1 @@ +something new \ No newline at end of file
The gid diff --cached or git diff -- stage command is used to compare the differences between the staging area and the latest version in the version Library
For example, add the content of the modified C: git test. txt to the temporary area, call git diff -- cache to see the difference, then commit the temporary area and call git diff -- cache to view.
$ git diff --staged $ git add "test.txt" $ git diff --cached diff --git a/test.txt b/test.txt index e69de29..88c6620 100644 --- a/test.txt +++ b/test.txt @@ -0,0 +1 @@ +something new \ No newline at end of file $ git commit [master 5a76c73] change 1 1 file changed, 1 insertion(+) $ git diff --cached
git rm
git rm is used to delete the specified file from the workspace and the temporary area, that is, to make Git no longer track the specified file.
For example, delete C: git test.txt, call git status and git diff to view, delete test.txt in the temporary area with git rm, check again, and finally submit the modification with git commit.
$ rm "test.txt" $ git status On branch master Changes not staged for commit: (use "git add/rm <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) deleted: test.txt no changes added to commit (use "git add" and/or "git commit -a") $ git diff diff --git a/test.txt b/test.txt deleted file mode 100644 index 88c6620..0000000 --- a/test.txt +++ /dev/null @@ -1 +0,0 @@ -something new \ No newline at end of file $ git rm "test.txt" rm 'test.txt' $ git status On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) deleted: test.txt $ git diff $ git commit [master 255b6f5] remove test.txt 1 file changed, 1 deletion(-) delete mode 100644 test.txt
git mv
The git MV "old" and "new" commands are used to rename files in workspace and temporary area, which are equivalent to three instructions:
- mv "old" "new"
- git rm "old"
- git add "new"
git log
The git log command is used to display all historical version information, and each version number is a large number calculated by SHA1.
$ git log --pretty=oneline 2c056afb902361dab926a5c31a206b9199b70708 (HEAD -> master) delete 5a76c73329d8f1f9f4a3af9094515159eb91cf4c change 1 62beab5d681565e2671dcba8b65f6a94da59f22b new text
git reset
The git reset command can shuttle in different versions.
Specifically:
git reset HEAD~x falls back to the previous x versions of the Head pointer.
git reset 62beab5 falls back to the version indicated by the version number starting with 62beab5.
git resrt --soft HEAD ~ points the HEAD pointer to a previous version of HEAD.
git reset --mixed HEAD ~ or git reset HEAD ~ points the HEAD pointer to a previous version of HEAD, and synchronizes the current version into the temporary area.
git reset --hard HEAD ~ points the HEAD pointer to a previous version of HEAD and synchronizes the current version to the temporary and workspace.
Verify the difference between soft,mixed and hard:
$ git reset --soft HEAD~ $ git diff $ git diff --cached diff --git a/test.txt b/test.txt deleted file mode 100644 index 88c6620..0000000 --- a/test.txt +++ /dev/null @@ -1 +0,0 @@ -something new \ No newline at end of file $ git reset 2c056a $ git reset HEAD~ Unstaged changes after reset: D test.txt $ git diff diff --git a/test.txt b/test.txt deleted file mode 100644 index 88c6620..0000000 --- a/test.txt +++ /dev/null @@ -1 +0,0 @@ -something new \ No newline at end of file $ git diff --cached $ git reset 2c056a $ git reset --hard HEAD~ HEAD is now at 5a76c73 change 1 $ git diff $ git diff --cached
In addition, git reset "version" path skips the move HEAD pointer step and overwrites the file referred to by path in version version to the temporary area. Commands with paths can only be at the -- mixed level.
git checkout
The git check out command is used for branch switching, as detailed in the git branch command.
git checkout – "filename"
Git checkout - "filename" is to synchronize content in the temporary area to the workspace.
$ git status On branch master Changes not staged for commit: (use "git add <file>..." to update what will be committed) (use "git checkout -- <file>..." to discard changes in working directory) modified: test.txt no changes added to commit (use "git add" and/or "git commit -a") $ git checkout -- "test.txt" $ git status On branch master nothing to commit, working tree clean
git branch
git branch is used to display all branches.
The git branch "bname" is used to create a new branch.
Git branch-d is used to delete a branch.
branch
Personally, version libraries store versions using a data structure similar to LinkedHashMap. As mentioned earlier, the HEAD pointer is used to point to the current version, which is not entirely correct. When using git log, you can see the words (HEAD - > master). It can be seen that the HEAD pointer points to something called master, which only points to a version number. So what is this master?
This master is a branch, and Git gives the default name of the main branch to be master, just as the default name of the first remote warehouse is origin. The HEAD pointer points to a branch pointer, indicating the current branch, and then points to the version number by the branch pointer. In Git, creating a branch is creating a pointer, and switching branches is moving the HEAD pointer.
It can be imagined that when there are not only one branch in the version library, different branches will develop in different directions, and the linear structure in the version library will become a tree structure.
The git check out command is used to switch branches.
The git checkout-b command is used to create and switch to the branch, equivalent to git branch + git checkout.
Git checkout-b "bname1" and "bname2" can create a local branch using a remote branch as a template.
Note: When there are uncommitted changes in the workspace or temporary storage area, you cannot switch branches at will. The following errors will be reported:
$ git checkout master
error: Your local changes to the following files would be overwritten by checkout:
test.txt
Please commit your changes or stash them before you switch branches.
Aborting
git stash
As mentioned above, you can't switch branches at will when there are uncommitted changes in the workspace or temporary storage area. The git stash command is required when changes to workspaces or temporary areas are insufficient to commit but cannot be deleted.
The git stash command handles the dirty state of the working directory (modified trace files and temporary changes), and then saves the unfinished changes to a stack, which you can re-apply at any time.
The git stash list is used to display all the contents of the stash stack.
git stash apply is used for modifications in the application stack.
git stash drop is used to discard elements in the stack.
The git stash pop application is modified and discarded.
git merge
git merge "branchName" is used to merge a branch into the current branch.
As you can imagine, there are two situations when merging:
1. The branch to be merged is the direct upstream of the version referred to by the current branch, as follows:
* c1e9a79918c87c85369a5989ccef6b98a441ba3f (newBranch) 2nd change * 044cf1bd7915a9c379b2cc05d25f26789ec6eeaf (HEAD -> master) 1st change
At this point, execute git merge "branchName" and move the current branch pointer forward.
$ git merge newBranch Updating 044cf1b..c1e9a79 Fast-forward test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --graph --pretty=oneline * c1e9a79918c87c85369a5989ccef6b98a441ba3f (HEAD -> master, newBranch) 2nd change * 044cf1bd7915a9c379b2cc05d25f26789ec6eeaf 1st change
We see the word Fast-Forward in the prompt, which means simply fast-forward the pointer, but there is a problem with this fast-forward merge: after deleting branches, branch information is lost. If you want to retain branch information, you can add the -- no-ff option.
$ git merge --no-ff -m "merge with no conflict" newBranch Merge made by the 'recursive' strategy. test.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) $ git log --pretty=oneline --graph * 2f6b28377a56915165bf7f9d8572cd6ecba622db (HEAD -> master) merge with no conflict |\ | * c1e9a79918c87c85369a5989ccef6b98a441ba3f (newBranch) 2nd change |/ * 044cf1bd7915a9c379b2cc05d25f26789ec6eeaf 1st change * eb4e818f28467c2eaf60d5e071304ea2dc4d29b3 change to 3 * 87806f775eee0c8f01ef46dce18e11074b4b51ce branch master
2. Both branches have their own new commits, at which point merge reports conflict
$ git merge newBranch Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Automatic merge failed; fix conflicts and then commit the result.
According to the prompt to fix conflicts, open the file and see the following:
<<<<<<< HEAD 123 ======= 12 >>>>>>> newBranch
It's git that identifies the conflicting parts of the two branches. It's simple and easy to understand.
Change the file to the desired merged content, commit, to fix the conflict.
$ git commit -a -m "merge" [master c3c2340] merge $ git log --pretty=oneline --graph * c3c234078b569d04b714e3f25e1ce151bf994b47 (HEAD -> master) merge |\ | * c1e9a79918c87c85369a5989ccef6b98a441ba3f (newBranch) 2nd change * | 51d603739fc50001daa6c2e10f57393e888f1e31 3rd change |/ * 044cf1bd7915a9c379b2cc05d25f26789ec6eeaf 1st change * eb4e818f28467c2eaf60d5e071304ea2dc4d29b3 change to 3 * 87806f775eee0c8f01ef46dce18e11074b4b51ce branch master
git rebase
git rebase and merge work similarly and are also used for merging branches. However, the base change does not retain the original branch form, but integrates the two branches into one branch. Variable base is mainly used to integrate branches locally, avoiding too many branches being submitted to remote warehouses.
Like merge, there are conflicts when merging:
$ git rebase newBranch First, rewinding head to replay your work on top of it... Applying: 3rd change error: Failed to merge in the changes. Using index info to reconstruct a base tree... M test.txt Falling back to patching base and 3-way merge... Auto-merging test.txt CONFLICT (content): Merge conflict in test.txt Patch failed at 0001 3rd change The copy of the patch that failed is found in: .git/rebase-apply/patch Resolve all conflicts manually, mark them as resolved with "git add/rm <conflicted_files>", then run "git rebase --continue". You can instead skip this commit: run "git rebase --skip". To abort and get back to the state before "git rebase", run "git rebase --abort".
Open the file and find the same effect as when merge conflicts:
<<<<<<< HEAD 123 ======= 12 >>>>>>> newBranch
Change the file to the desired merged content and follow the prompt git add, git rebase --continue.
$ git add "test.txt" Admin@DESKTOP-UD83S84 MINGW64 /c/git (master|REBASE 1/1) $ git rebase --continue Applying: 3rd change Admin@DESKTOP-UD83S84 MINGW64 /c/git (master) $ git log --pretty=oneline --graph * 5e47d0da06b5d526963f444d7f1f37df2dc5b963 (HEAD -> master) 3rd change * c1e9a79918c87c85369a5989ccef6b98a441ba3f (newBranch) 2nd change * 044cf1bd7915a9c379b2cc05d25f26789ec6eeaf 1st change * eb4e818f28467c2eaf60d5e071304ea2dc4d29b3 change to 3 * 87806f775eee0c8f01ef46dce18e11074b4b51ce branch master
It is found that the two branches have been merged into one branch without retaining the original branch format.