git basic concepts and usage summaryOriginal Author: guibin.beijing@gmail.com
In the daily use of git process, often error, such as inadvertently lost uncommitted data, fallback version lost working directory, and so on. After thinking that all of these errors are caused by some basic ambiguity in git, because there are some basic concepts that are not clear, the result of each command on Git will not match the expected results. Below I will comb the basic concepts related to the problems I often encounter.
1. Working directory (working directory)
The working directory of Git is the directory where the files that are currently working are saved, and the working tree is the same meaning. Files in this directory may be deleted or replaced by Git when switching branch. This directory is a temporary directory that temporarily stores the files you have removed from the Git repository, which are kept until the next commit.
2. Git directory (git library directory)
All of the project's history commits are saved in the GIT repository directory and should not be lost as long as you do not roll back the operation.
3. Git index (git indexing)
Git index can be thought of as a staging area between the working directory and the Git repository directory, and the staging area is the same meaning. You can use Git index to build a set of changes that you are ready to commit together. git index and Git Staging area are the same meaning, which refers to the areas where the content that has been add but not yet commit. The simplest way to see what's currently in index is to use the
git statusCommand.
The content listed in "Changes to is committed" in the command is the content in index, and commits to git Directory. The content listed in the command "Changed but not updated" is in working directory and will enter index after Add. The content listed in the command "untracked files" is something that has not been tracked by Git, and add then enters index. What actions can change the content in Git index.
A).
git add <path>, ... .The content in working directory is added to git index.
B).
git reset HEAD <path>The path content in Git index is deleted and re-put back into working directory.
4. Git diff
git diff can compare the differences between working tree and index, between index and Git directory, between working tree and Git directory, and between different commits in Git directory,
git diff [<path> ...]: This command is most commonly used to run this command every time the add enters index, to see what changes are made when add enters index, that is, the difference between working directory and index.
git diff--cached [<path> ...]: This command beginner is less common, but very useful, which means to see the difference between the content that has been added to index but not yet commit and the content of the last commit. That is, the difference between index and git directory.
git diff--cached [<commit>] [<path> ...]: This command is very useful for beginners, and it means to view the difference between the content that has been added into index but not yet commit and the specified <commit>, which is similar to the one above, and the difference is only <commit> This is the difference between the specified version in index and Git directory.
git diff <commit> [<path> ...]: This command is used to view the difference between the working directory and the specified <commit> commit, and <commit>=head if it is different from the latest version in Git directory. If you want to compare the difference with a branch, <commit>= branch name
git diff <commit> <commit> [<path> ...]: This command compares the differences between any two <commit> in Git directory, and if you want to compare the differences between any <commit> and the latest version, turn one <commit> into head.
5. How to merge different branches
In Git, you must know where you are when you execute any command. To whom to execute this command.
For example, when creating a new branch, execute the command:
git branch 1.0-beta, this command is to say that on the current branch, the current branch as the benchmark, create a new branch, called 1.0-beta.
For example, when you merge different branch:
Reference git checkout 1.0-beta
Git merge Master
First switch to 1.0-beta branch, and then merge the code on the backbone (master) onto the current 1.0-beta branch.
After the merge is complete, you may be prompted by a conflict to edit the file identified as "CONFLICT" after resolving the conflict, and then after add,commit the conflicting file, the merge is complete.
6. Git reset
In general use, if you find that you do not want to staging the file add to enter the index, you want to fallback cancellation, you can use the command:
git reset HEAD <file>, Git also prompts you when git add is complete, such as: Quote # Changes to be committed:
# (
Use "git reset HEAD <file> ..." to Unstage)
#
# New File:Test.scala
git reset [--hard|soft|mixed|merge|keep] [<commit> or head]: Resets the current branch (reset) to the specified <commit> or head (by default, if the specified commit is not displayed, the default is head, which is the latest commit), and it is possible to update index and working according to [mode] Directory The value of mode can be hard, soft, mixed, merged, keep. The meanings and effects of each pattern are explained in detail below. A).
--hard: Reset (reset) index and working directory, any changes in working directory since <commit> have been discarded and the head is pointed to <commit>.
B).
--soft: The content in index and working directory does not change, just point head to <commit>. The effect of this mode is that after execution, all changes since <commit> have been shown in the Git status
"Changes to be committed"In
C).
--mixed: Reset index only, but not reset working directory. This mode is the default mode, that is, when the git reset mode is not displayed, the mixed mode is used. The effect of this pattern is that changes to files in working directory will be preserved, not discarded, but will not be labeled as "changes to be committed", but will result in reports that have not yet been updated. The report reads as follows:
Reference unstaged changes after Reset:
M Test.scala
M Test.txt
D).--merge and--keep are not used much, as illustrated in the following example.
Some typical scenarios for git reset are listed below:
A) rollback Add manipulation
Reference $ edit (1)
$ git add frotz.c filfre.c
$ MAILX (2)
$
git reset(3)
$ git Pull git://info.example.com/nitfol (4)
(1) Edit the file frotz.c, filfre.c, make some changes, and add the changes to the index
(2) Check the email and find someone wants you to pull, some changes need you to merge down
(3) However, you have messed up index because index does not match the head commit, but you know that the pull will not affect the modified frotz.c and filfre.c, so you can revert the changes of these two files. Revert, those changes should still be in working directory, so perform
git reset。
(4) Then, after the pull is executed, the automatic merge,frotz.c and filfre.c changes are still in working directory.
B) Rollback of the most recent commit
Reference $ git commit ...
$
git reset--soft head^(1)
$ edit (2)
$ git commit-a-C orig_head (3)
(1) When submitted, you find that the code is not submitted complete, or you want to re-edit the submitted comment, execute
git reset--soft head^, let working tree be the same as before reset, without making any changes.
head^The most recent commit before the head.
(2) Modify the files under the working tree
(3) Then resubmit the comment, author, date, and other information of the commit before reset. Note that when you execute the git reset command, git will copy the old head to the file. Git/orig_head, you can use Orig_head to refer to this commit in the command. In the Commit command
-AThe parameter means to tell git to automatically put all the modified and deleted files into the stage area, and the new files that are not tracked by git will not be affected. In the Commit command
- C <commit>Or
- C <commit>By submitting the information (author, submitter, comment, timestamp, etc.) in the commit object that was committed, the meaning of this commit is very clear, add all the changed files to the stage area, and resubmit with the last commit information.
C) rollback the last commit and put these commits on the branch called topic.
Reference $ git Branch Topic/wip (1)
$
git reset--hard head~3(2)
$ git checkout Topic/wip (3)
(1) You have submitted some commits, but at this point you find that these commits are not mature enough to enter the master branch, but you want to polish the commit changes on the new branch. Hence the implementation of
git branchThe command establishes a new branch called Topic/wip on the current head.
(2) then roll back the last three commits on the master branch.
head~3A commit that points to the current HEAD-3 commit,
git reset--hard head~3That is, delete the last three commits (delete head, head^, head~2) and point head to Head~3.
D) Permanent deletion of the last few commits
Reference $ git commit ...
$
git reset--hard head~3(1)
(1) The last three commits (i.e. HEAD, head^ and head~2) have a problem and you want to permanently delete these three commits.
E) rollback Merge and pull operations
Reference $ git Pull (1)
Auto-merging Nitfol
CONFLICT (content): Merge CONFLICT in Nitfol
Automatic merge failed; Fix conflicts and then commits the result.
$
git reset--hard(2)
$ git pull. Topic/branch (3)
Updating from 41223 ... To 13134 ...
Fast-forward
$ git reset--hard orig_head (4)
(1) Some updates are pulled down from origin, but there are a lot of conflicts, you don't have so much time to resolve these conflicts, so you decide to pull again when you're free.
(2) due to a conflict in the pull operation, all pull down changes have not yet been committed and are still in the stage area, in which case
git reset--hardAnd
git reset--hard HEADThe same meaning, that is, to clear the index and working tree is messed up things.
(3) Merge topic/branch into the current branch, this time there is no conflict, and the merged changes are automatically submitted.
(4) But now you find it premature to merge topic/branch, so decide to roll back the merge and execute
git reset--hard orig_headRoll back the pull/merge operation just now. Description: As mentioned earlier, when you perform git reset, Git puts the head of reset before it into the. git/orig_head file, and the command line uses Orig_head to refer to this commit. Similarly, when you perform pull and merge operations, Git puts the head in the Orig_head before performing the operation in case of a rollback operation.
F) Roll back the merge or pull in the contaminated working tree
Reference $ git Pull (1)
Auto-merging Nitfol
Merge made by recursive.
Nitfol | +++++----
...
$
git reset--merge orig_head(2)
(1) Even if you have changed some of your working tree locally, you can also secure git pull, provided you know that the content you are pulling will not overwrite the contents of your working tree.
(2) After Git pull is finished, you find that the change is not satisfactory, you want to roll back to the state before pulling, from the previous introduction know that we can execute git reset--hard orig_head, but this command has a side effect is to empty your working Tree, that is, discard those changes that you have not add locally. To avoid discarding the contents of the working tree, you can use the
git reset--merge orig_head, notice that the--hard is replaced with--merge, so you can avoid clearing the working tree when rolling back.
G) interrupted work flow
This is often the case in real-world development: You're developing a big feature, and there's an urgent bug to fix, but the current content in working tree hasn't been formed yet, and it's not enough to commit, but you have to switch the other branch to fix Bug Take a look at the following example
Refer to Git checkout feature; # were working in "feature" Branch and
$ got interrupted
$ git commit-a-M "Snapshot WIP" (1)
$ git Checkout Master
Fix fix
$ git commit; # Commit with real log
$ git checkout feature
$
git reset--soft head^; # go back to the WIP State (2)
$
git reset(3)
(1) This is a temporary submission, so just add a temporary comment.
(2) This time reset deletes the WIP commit and sets the working tree to the state before the WIP snapshot is submitted.
(3) At this time, in the index still left the "snapshot WIP" submitted by the Uncommit changes,
git resetThe status of index as not yet committed "snapshot WIP" will be cleared to facilitate the next step.
(H) A separate file for reset
Suppose you've added a file to index, but then you're not going to commit the file, you can use git reset to remove the file from index.
Reference $
git reset--frotz.c(1)
$ git commit-m "commit files in Index" (2)
$ git add frotz.c (3)
(1) Remove the file frotz.c from index,
(2) Submit the documents in index
(3) Add frotz.c to index again
(I) Keep working tree and discard some previous commit
Let's say you're editing some files and you've committed them, and then you're going to work, but now you find that the content in the working tree should belong to another branch, which has nothing to do with the previous commit. At this point, you can open a new branch and keep the contents of the working tree.
Reference $
git tag start $ git checkout-b branch1
$ edit
$ git commit ... (1)
$ edit
$ git checkout-b branch2 (2)
$
git reset--keep start(3)
(1) This time, the change in the BRANCH1 was submitted.
(2) At this time found that the previous submission does not belong to this branch, at this time you create a new BRANCH2, and switch to the BRANCH2.
(3) Now you can use
Reset--keepRemove the commit after start, but keep the working tree intact.
7. Git revert
Git revert is used to roll back some commits. For one or more commits that already exist, remove the changes introduced by these commits and record the rollback operation with a new commit. This command requires the working tree to be clean.
The functionality of git revert and git reset is similar, but there are differences, as described below.
git revertUsed to record and roll back previous commits with a commit, often in the wrong commits. If you want to simply throw away what's in working tree, you can use
git reset--hard Like what
A
git revert head~3: Discards the last three commits, restores the state to the nearest fourth commit, and submits a new commit to record the change.
B
git revert-n master~5..master~2: Discards from the most recent fifth commit (inclusive) to the second (not included), but does not automatically generate a commit, this revert only modifies working tree and index.
8. The difference between git revert and git reset
1. Git revert is a new commit to roll back before Commit,git reset is to delete the specified commit directly.
2. In the rollback of this operation, the effect is similar. However, there is a difference when you continue to merge old versions of the previous version later. Because git revert is a reverse commit "medium and" before the commit, so later merging old branch, cause this part of the change will not reappear, but git reset is to remove some commits on a certain branch, As a result, when the old branch is re-merge, these rollback commits should also be introduced.
3. Git reset is to move head backwards, and git revert is head to move forward, but the new commit content and to revert the content is just the opposite, can offset the content to be revert.
9. How to delete a remote branch
Deleting a remote branch is the push of the local empty branch to the remote.
Reference
#查看远程分支
$
git ls-remoteIdc
Password:
FA7DC3CD254C6FFF683E20722284565B92D869FF HEAD
14a62709ecadd11a266d234d19955f4679fa95ab refs/heads/cpp-1.0
34b38625bce0aa4d4a4e266e20bba3e0ccd1b97e Refs/heads/cpp-1.0.rc1
3F40A21F20F51AAA74E2A6954B64D82506CD4ADF refs/heads/cpp-1.1
2F795085D57B6784A6358D97DBD0D1227891B01A Refs/heads/distri
9. How to delete a local branch
Using the git branch command, you can delete local branches, such as
Reference
git branch-dTobedelbranch
10. How to Clone (clone) a specified branch in a remote repository, rather than the default master branch
Use the-b parameter in the git clone command to specify the branch name, such as cloning the levelIISZ-1.1 branch on the remote aiotrade.git:
Reference
git clone-blevelIISZ-1.1 Username@192.168.4.40:aiotrade.git
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
