Study Notes on Pro git

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，HoweverAnd then submit C3 and C4. Then add another one from the C3 location.clientBranch to modify the client code. Therefore, C8 and C9 are submitted. Finally, returnserverBranch 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 canserverBranch rathermasterBranch changes (that is, C8 and C9), skipserverPut it directlymasterRepeat it in the branch, but this requiresgit rebaseOf--ontoOption to specify the new base branchmaster:

    $ git rebase --onto master server client

This is like saying: "retrieveclientBranch, locateclientBranch andserverAfter the common ancestor of the branchesmaster". Is it a bit complicated? However, the result 3-32 is very cool.clientAfter C3, but this only indicates the order of time, rather than further modification on the basis of C3 modification, becauseserverAndclientThe 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 nowmasterBranch (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 decidedserverBranch changes are also included. We can directlyserverBranchmasterInstead of manually switchingserverBranch before performing the derivative operation-Git rebase [main branch] [feature branch]The command First extracts the feature BranchserverAnd then in the main branchmasterREPLAY:

    $ git rebase master server

So,serverApplicationmaster, As shown in Figure 3-34:

Figure 3-34. Add a server branch to the master branch.

Then you can quickly enter the main branchmasterNow:

    $ git checkout master
    $ git merge server

NowclientAndserverBranch 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