1. Git remote Model
-
Remote: Remote Repository
-
Repository: local repository
-
Index: Temporary Storage Area
-
Workspace: Current Workspace
2. Get git Repository 2.1 initialize a new warehouse
Git init
2.2 clone from existing warehouse
Git clone git: // github.com/xxx/xxx.git [dirname]
3. Record every update to the warehouse 3.1 File status change cycle
3.2 check the status of the current file.
Git status
3.3 tracking new files
Git add <FILENAME>
3.4 Update files that have been placed in the temporary storage area but are modified later
Git add <FILENAME>
3.5 view saved and unsaved updates
Git DIFF: view the differences between the workspace and the temporary storage Zone
Difference between the files saved by git diff and the last commit
3.6 submit an update
Git commit or git commit-M "details"
3.7 skip the temporary storage area for direct updates
Git commit-a-m "Update description"
3.8 delete an object
Git Rm <File Name>
If you delete a file that has been modified and stored in the temporary storage area, use the-F option to forcibly delete the file in the temporary storage area. This parameter is used to prevent loss of modified content after files are deleted by mistake.
3.9 remove the object trace but not delete the object
Git Rm -- cached <File Name>
If "\" is added before "*", all matching files in the current directory will be recursively deleted, for example, git RM \ *. tmp.
3.10 move files
Git MV <file 1> <file 2> is equivalent to deleting file 1 first, and then adding file 2
4. view submission history
Git log
Common usage:
4.1 expand content differences
Git log-P-2 (-P expands the difference in content submitted each time, and uses-2 to show only the last two updates)
4.2 only show brief statistics on the number of rows added and changed
Git log -- stat
4.3 The submission history is displayed in the specified format
Git log -- pretty = oneline (put each commit in one line for display, as well as short, full, and Fuller can be used)
4.4 custom record format
Git log -- pretty = format: "% H-% an, % AR: % s". Common Format Placeholders are written in the following way:
Option |
Description |
% H |
Complete hash string of the submitted object (COMMIT) |
% H |
Brief hash string of the submitted object |
% T |
Complete hash string of a tree object |
% T |
Brief hash string of the tree object |
% P |
Complete hash string of the parent object (parent) |
% P |
Brief hash string of the parent object |
% |
Author (author) Name |
% AE |
Author's email address |
% Ad |
Author's revision date (you can use the-date = option to customize the format) |
% Ar |
The author's revision date, displayed in the previous manner |
% CN |
Name of the submitter |
% Ce |
Submitted by email address |
% Cd |
Submission date |
% Cr |
Submission date, displayed in the previous manner |
% S |
Submission instructions |
4.5 restricted filtering Conditions
Git log -- [n | since | after | until | author | committer], option description:
Option |
Description |
-(N) |
Show only the last n submissions |
-- Since, -- after |
Only the submission after the specified time is displayed |
-- Until, -- before |
Only the submission before the specified time is displayed |
-- Author |
Only displays submissions related to the specified author |
-- Committer |
Only displays submissions related to the specified submitter |
5. Cancel operation 5.1 submit the last modification
Git commit-M "Initial commit"
Git add forgotten_file
Git commit -- Amend
5.2 cancel saved files
Git reset head <File Name>
5.3 cancel File Modification
Git checktout -- <File Name>
6. remote warehouse 6.1 view the current remote warehouse
Git remote [-v]
6.2 Add a remote Repository
Git remote add <remote repository Name> <remote repository address>
6.3 capture data from a remote warehouse
Git fetch <remote repository Name>
If a repository is cloned, the remote repository is automatically assigned to the origin. Therefore, the GIT fetch origin captures all updates uploaded to this remote repository since your last clone (or updates submitted by others since the last fetch ). It is important to remember that the FETCH command only pulls remote data to a local warehouse and does not automatically merge the data into the current work branch. You can only merge the data manually when it is ready.
If you have set a branch to track the branch of a remote repository (see the following section and chapter 3), you can use the GIT pull command to automatically capture data, then, the remote branch is automatically merged to the current branch in the local repository. In our daily work, we often use this method fast and well. In fact, by default, the GIT clone command automatically creates a local master branch to track the master branch in the remote warehouse (assuming that the remote warehouse does have a master branch ). Therefore, we generally run git pull to capture data from the original cloned remote repository and merge the data to the current branch in the working directory.
6.4 push data to remote warehouse
Git push [remote repository name] [branch name]
6.5 view remote Repository Information
Git remote show [remote repository name]
6.6 Delete and rename a remote Repository
Git remote rename <old repository Name> <new repository Name>
7. Tag
When releasing a software version, use git to tag the version at a certain time point.
7.1 view existing tags
Git tag [-L <tag mode>]
Example: git tag-l 'v1. 4. 2 .*'
7.2 create a tag
Git uses two types of labels: lightweight and annotated ). A lightweight tag is like a branch that does not change. In fact, it is a reference pointing to a specific commit object. Note labels are actually an independent object stored in the warehouse. They have their own checksum information, including the tag name, email address, date, and label description, the tag itself allows the use of GNU Privacy Guard (GPG) for signing or verification. Generally, we recommend that you use a label with the annotation type to retain relevant information. Of course, if you only add a label temporarily or do not need to add additional information, it is no problem to use a lightweight label.
Labels with notes:
Git tag-A <Tag Name> [-M <tag description>]
-Option A specifies the annotation type, and option M specifies the label description.
Lightweight labels:
Git tag <Tag Name>
7.3 sign tags
Use the private key and GPG to sign the tag.
Git tag-S <Tag Name> [-M <tag description>]
7.4 verify tags
Git tag-v <Tag Name>
The signed public key must be stored in the keyring.
7.5 add tags later
Git tag-v <Tag Name> <first digit of the checksum>
7.6 share tags
Git push <remote repository Name> <Tag Name>
8. Branch Theory
The commit object points to the tree object that contains the index of each file BLOB Object. The essence of git branch is a variable pointer to the commit object. Git uses master as the default name of the branch. Git creates a new branch by creating a new branch pointer: git branch <branch name>.
Head is a pointer to a local branch in the working state. It can be used as the alias of the current branch.
8.1 switch the head to another branch
Git checktout <branch name>
It is best to keep a clean working area when switching the branch.
8.2 new branch and switch
Git checkout-B <new branch name>
Equivalent:
Git branch <new branch name>
Git checkout <new branch name>
8.3 merge branches
Assume that you want to merge the branch hotfix into the branch master, first check out the master branch, and then merge the branch.
Git checkout master
Git merge hotfix
8.4 Delete Branch
Git branch-D <branch name>
8.5 view all branches
Git branch [-v | -- merged | -- On-merged]
-V option is used to view the information of the last commit of each branch. -- merged is used to view which branches have been merged into the current branch.
8.6 use branches for development
Long-term Branch (master): for example, the master branch keeps completely stable code, and the stable branch is always old.
Development Branch: a branch that is parallel to the master for subsequent development or stability testing.
Feature branch: short-term Branch used to implement a single feature.
8.7 remote Branch
Remote branch is the index of the branch in the remote repository. They are local branches that cannot be moved. They are updated only when git performs network interaction. The remote branch is generally expressed in the form of <remote repository Name>/<branch name>.
A git clone will create a local branch master and a remote branch origin/master, both pointing to the last commit of the origin/Master branch.
(1) synchronize data on the remote server: git fetch origin. This command first finds the origin server, obtains data from it, and then moves the origin/Master pointer to the latest position.
(2) push local branch: git push <remote repository Name> <local branch name> [: <remote branch name>]. If <remote branch name> is not specified, the name of the local branch is used.
(3) It is worth noting that the new remote branch is obtained using the fetch operation, and thus the remote branch cannot be edited locally, to merge the content of the remote branch to the current branch, you can use: git merge <remote repository Name>/<remote branch name>.
(4) If you want to edit a branch, you can create a new branch based on the remote Branch: git checkout-B <new branch name> <remote repository Name>/<remote branch name>. The local branch from the remote branch checkout is called the tracking branch. The tracking branch is a local branch directly associated with a remote branch. Enter git push in the tracking branch, and git will deduce to which server the data is pushed. Similarly, running git pull in the tracking branch will obtain remote indexes and merge all their data into the local branch.
(5) delete a remote branch: git push <remote repository Name>: <remote branch name>
8.8 branch Derivation
There are two ways to integrate one branch into another: Merge and rebase ). The principle of merge is to merge the latest snapshots of the two branches and the latest common ancestor of the two, and then generate a new submission object. The rebase principle is: Suppose there are two branches: Experiment and master, and experiment is the branch to be derived. Return to the common ancestor of the two, generate a series of patches Based on the subsequent submissions of experiment, and then use the last object submitted by the base branch master as the new starting point to apply the patch files prepared one by one, finally, a new merged submission object is generated, and the submit history of experiment is rewritten. Its command is:
Git checkout Experiment
Git rebase master
Rebase and merge get the same snapshot content, but rebase can provide a more concise submission history. In general, we want to get a patch that can clean the application on a remote branch. For example, if you are not a maintainer for some projects but want to help you, it is best to use derivation: first develop in one of your own branches. When you are preparing to submit a patch to the main project, perform a derivation operation based on the latest origin/master and then submit it, in this way, the maintainer does not need to do any integration work (in fact, it is the responsibility to resolve the conflict between the branch patch and the latest main code and convert it to the solution by the person who submits the patch ), you only need to perform a fast-forward merge Based on the repository address you provided, or directly adopt the patch you submitted.
It can also be placed in other branches, not necessarily based on the branch before differentiation. Taking the history of 3-31 as an example, we created features to add some functions to the server code.Branch
server,
However
And then submit C3 and C4. Then add another one from the C3 location.client
Branch to modify the client code. Therefore, C8 and C9 are submitted. Finally, returnserver
Branch submitted C10.
Figure 3-31. Separate the history of a feature branch from a feature branch.
Suppose in the next software release, we decided to first modify the client to the main line, and then suspend the modifications to the software incorporated into the server (because further tests are required ). At this time, we canserver
Branch rathermaster
Branch changes (that is, C8 and C9), skipserver
Put it directlymaster
Repeat it in the branch, but this requiresgit rebase
Of--onto
Option to specify the new base branchmaster
:
$ git rebase --onto master server client
This is like saying: "retrieveclient
Branch, locateclient
Branch andserver
After the common ancestor of the branchesmaster
". Is it a bit complicated? However, the result 3-32 is very cool.client
After C3, but this only indicates the order of time, rather than further modification on the basis of C3 modification, becauseserver
Andclient
The code corresponding to the two branches should be two sets of files. Although this is not very strict, it should be understood that after the C3 time point, the C8 and C9 modifications made to the other files should be made, put it in the trunk for replaying .) :
Figure 3-32. Extend another feature branch on the feature branch to another branch.
Fast forward nowmaster
Branch (see Figure 3-33 ):
$ git checkout master
$ git merge client
Figure 3-33. Fast forward to the master branch to include changes to the client branch.
Now we decidedserver
Branch changes are also included. We can directlyserver
Branchmaster
Instead of manually switchingserver
Branch before performing the derivative operation-Git rebase [main branch] [feature branch]
The command First extracts the feature Branchserver
And then in the main branchmaster
REPLAY:
$ git rebase master server
So,server
Applicationmaster
, As shown in Figure 3-34:
Figure 3-34. Add a server branch to the master branch.
Then you can quickly enter the main branchmaster
Now:
$ git checkout master
$ git merge server
Nowclient
Andserver
Branch changes have been integrated into the main branch. You can delete them. In the end, our submission history will look like Figure 3-35:
$ git branch -d client $ git branch -d server
Figure 3-35. final submission history
Rebase risks:Once the submission object in the branch is published to the public warehouse, do not rebase the branch.
Study Notes on Pro git