06_Git commit specification
Article directory
6.1 Information contained in the commit
As shown in the figure below (intercepted from Angular commit 970a3b5 ), a commit contains the following information:
- commit message - A description of the content of the commit
- author & committer - author and committer
- changed files - Modified files
- hash & parent - the hash of the commit and its position in the commit tree
6.2 Commit Message
The commit message describes the currently submitted function-related information , which generally includes header, body,footer
<header>
<BLANK LINE>
<body>
<BLANK LINE>
<footer>
header
<type>(<scope>): <short summary>
│ │ │
│ │ └─⫸ 现在时态的摘要，不要大写，结尾没有句号。
│ │
│ └─⫸ common|compiler|compiler-cli|core...
│
└─⫸ Commit Type: build|ci|docs|feat|fix|perf|refactor|test
<header>Among them, <type>and <summary>are mandatory and <scope>optional. Suggestions <header>need to be kept under 50 characters.
<type>Indicates the type of this submission, generally as follows:
build: Involves build-related changesci: Changes related to continuous integrationdocs: documentfeat: new functionfix: bugfixperf: performance related changesrefactor: Refactoring related (non-bug, non-new function)test: Test-related, including adding new tests or changing existing tests
<scope>Indicates the range affected by the change. In Angular, a submission may involve form processing, animation processing, and so on.
<summary>is a brief description of the commit
body
<body>is a more detailed description of the commit message.
Describe the motivation for this modification, such as why this modification was introduced, what was the logic before, what is the logic now, what are the impacts of this modification, etc.
footer
<footer>It is optional, and generally involves descriptions of destructive changes, deprecation of functions, etc., as well as GitHub issuereferences to , PR references, etc.
BREAKING CHANGE: <breaking change summary>
<BLANK LINE>
<breaking change description + migration instructions(迁移指令)>
<BLANK LINE>
<BLANK LINE>
Fixes #<issue number>
DEPRECATED: <what is deprecated(弃用了什么)>
<BLANK LINE>
<deprecation description + recommended update path(重大更改描述+迁移说明)>
<BLANK LINE>
<BLANK LINE>
Closes #<pr number>
Standardized submission information can be parsed using tools to automatically generate documents or release logs.
In some large-scale open source projects, it is time-consuming and labor-intensive to manually sort out version update documents, interface updates, and compatibility effects. Using a unified specification can greatly automate this part of the work.
Of course, different projects have different requirements and format standards for submitted information. Open source projects or company projects also have different requirements for submitted information, and generally need to follow the agreement of the project. More mature open source projects can generally READMEfind out how to contribute in the documentation, or have a separate CONTRIBUTING.mddocument to agree on the code style and submission method.
6.3 Git Hooks
Git Hooks are git triggering custom scripts when specific important actions occur.
Hooks are stored in the hooks subdirectory of the Git directory. That is, .git/hooks in most projects. When initializing a new repository, Git places some example scripts in this directory by default. The names of these samples all end in .sample, if you want to enable them, you have to remove this suffix first.
Git has two types of hooks: client-side and server-side.
There are two hooks related to automated deployment, post-update and github based on post-update packaged webhook
The following four are involved in submitting:
pre-commit: Execute before Git generates the commit object
prepare-commit-msg: Execute after pre-commit to generate the default commit information
commit-msg: Execute after the developer writes the commit information, only a temporary file name Parameter
post-commit: Execute immediately after commit-msg, more for notification
Therefore, we can use the functions provided by Git Git Hooksto automatically verify the submitted information to ensure that developers comply with the specifications.
We can use it prepare-commit-msgto explain the submission information specification, and use it to commit-msgcheck the execution of the specification. A non-zero return of the script will interrupt this submission.
If you want to use related ones , you can create corresponding files Git Hooksin the directory , the file name is and , and grant executable permissions. In this way, when we operate , the corresponding script will be executed..git/hooksprepare-commit-msgcommit-msggit commit
Git commits do not include .gitdirectories, so corresponding hookschanges are not committed to the repository. .githooksWe can create a folder in the root directory of the warehouse and put our implemented code in this directory, and refer to it by changing the configuration or soft link:
# use config
git config core.hooksPath .githooks
# or use soft link
ln -sf .githooks/* .git/hooks
6.4 Author & Committer
In Git, Author represents the author who originally wrote the commit, and Committer represents the person who applies the commit, such as the merged Pull Requestproject administrator. If you are an individual developer or only use a single Git platform service (such as GitHub, BitBucket, etc.), we generally do not need to make special configurations for the author. However, if multiple Git platforms are used or there are internal company requirements, we may need to set up different users and mailboxes for different warehouses. For example, personal GitHub accounts can be set globally, and corporate mailboxes can be set for internal warehouses of the enterprise.
# 全局默认配置
git config --global user.email "<github email>"
git config --global user.name "<github username>"
# 企业内部仓库
git config user.email "<enterprise email>"
git config user.name "<real name>"
6.5 Changed files
Different submissions may involve more or less files, and the following principles are generally followed:
git diffUse to view the changes of the file before submitting , usegit addto add the files expected to enter the submission, usegit statusto view the status of the file, and finally usegit committo submit- Only commit related changes in a single commit, for example two separate commits should be used to fix two different bugs
- Encourage frequent submissions, which can share implemented functions faster and reduce the risk of code loss
- Semi-finished products cannot be submitted in the main branch or the collaborative function branch, and the test needs to be passed before submission
- Compile output, logs, intermediate products, etc., do not introduce into the submission, use
.gitignoreto exclude related files - Do not submit passwords, authorization credentials, keys, etc.
- For configuration files (such as database connection information, etc.), configuration templates are generally used, and individuals maintain local files, which are
.gitignoreconfigured in .
6.6 Hash & Parent
In general, commit hashwe don't need to pay extra attention to parent node information, but in specific scenarios we may need to commitrepair or do other processing. In such a scenario, we need to understand the entire git commit chain, the parent node corresponding to each commit, the common ancestor between branches, and the differences between local and remote, and we need to follow the workflow used by the project throughout the commit Model.
- In some Git workflow models,
git pull --rebaseupdates to local commits are made using - In principle, it is forbidden to operate on the main branch, etc.
git push -f, if it involves a rollback, usegit revert <commit> - Involving multi-branch code synchronization, you can use
git cherry-pickthe command
Workflow for merge and rebase
# merge⼯作流
git pull (或fetch && merge)
找到当前冲突⽂件，编辑解决冲突
git pull
# rebase工作流
git rebase
while(存在冲突) {
git status
找到当前冲突⽂件，编辑解决冲突
git add -u
git rebase --continue
if(git rebase --abort)
break;
}
The difference between merge and rebase
1. Merge will generate one more merge commit, but rebase will not.
2. The commit tree of merge is non-linear, and the commit tree of rebase is linear (by rewriting the commit history).
Usage scenarios of merge and rebase
rebase: I have been working on my own development branch, and then one day I want to merge the mainline changes into the branch and do an integration. In this case, it is better to use rebase
The branch uses rebase, because the commits put in later are all new, so other branches pulled out from this public branch need to be rebased, which means that when you rebase things in, they are all new commits.