1 About log submission specifications
A good Commit Message facilitates code review, allows you to find Change records more quickly, and allows you to generate Change logs directly.
In order to standardize the code submission specification, we use the Angular specification:
<type>(<scope>) :<subject>
<A blank line>
<body>
<A blank line>
<footer>
Copy the code
Head (():) is required and body and footer are optional. If you only need to type header, you can use:
git commit -m
Copy the code
Command submission.
To enter multi-line logs such as body and footer, type:
git commit
Copy the code
Jump out of the text editor and write.
1.1 the Header
1.1.1 Type
Commit categories include the following seven:
-Blair: Oh, yeah. -Blair: Oh, yeah. -Blair: Oh, yeah. -Blair: Oh, yeah.test: Adds a test chore: a change in the build process or helperCopy the code
1.1.2 the Scope
The scope of the commit, such as which module/performance/layer (business layer, persistence layer, cache, RPC) will be affected, or if it is a feature code, write the feature name
1.1.3 Subject
A short description of the COMMIT, no more than 50 characters long.
- Use the present tense, imperative
- You don’t need to capitalize the first letter
- Don’t put a period at the end
1.2 the Body
Like subject, use the present tense, imperative. You should explain your motivation for submitting the code and how it compares to the previous version.
1.3 the Footer
The Foot contain can contain the following information:
1.3.1 Describes major Change information
BREAKING CHANGE is a good way to describe the CHANGE
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: The '@',
myBind: The '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor } The removed `inject` wasn't generaly useful for directives so there should be no code using it.
Copy the code
1.3.2 closed JIRA
Such as:
Closes DB-1001, DB1002
Copy the code
1.4 Some Commit Message examples:
feat($browser): onUrlChange event (popstate/hashchange/polling)
Added new event to $browser:
- forward popstate event if available
- forward hashchange event if popstate not available
- do polling when neither popstate nor hashchange available
Breaks $browser.onHashChange, which was removed (use onUrlChange instead)
---------
fix($compile): couple of unit tests for IE9
Older IEs serialize html uppercased, but IE9 does not...
Would be better to expect case insensitive, unfortunately jasmine does
not allow to user regexps for throw expectations.
Closes # 392
Breaks foo.bar api, foo.baz should be used instead
---------
eat(directive): ng:disabled, ng:checked, ng:multiple, ng:readonly, ng:selected
New directives for proper binding these attributes in older browsers (IE).
Added coresponding description, live examples and e2e tests.
Closes # 351
---------
feat($compile): simplify isolate scope bindings
Changed the isolate scope binding options to:
- @attr - attribute binding (including interpolation)
- =model - by-directional model binding
- &expr - expression execution binding
This change simplifies the terminology as well as
number of choices available to the developer. It
also supports local name aliasing from the parent.
BREAKING CHANGE: isolate scope bindings definition has changed and
the inject option for the directive controller injection was removed.
To migrate the code follow the example below:
Before:
scope: {
myAttr: 'attribute',
myBind: 'bind',
myExpression: 'expression',
myEval: 'evaluate',
myAccessor: 'accessor'
}
After:
scope: {
myAttr: The '@',
myBind: The '@',
myExpression: '&',
// myEval - usually not useful, but in cases where the expression is assignable, you can use '='
myAccessor: '=' // in directive's template change myAccessor() to myAccessor } The removed `inject` wasn't generaly useful for directives so there should be no code using it.
Copy the code
For feature development, you can do this:
Feat (Short Video Play Optimization): Full screen play animation effect optimizationCopy the code
2 Submit logs for automatic verification
In the NodeJS project, we can use ghooks + validate-commit-msg to verify the commit log. If the check fails, the commit will be rejected. The NodeJs validation script is compiled by the NodeJs project and written to a.git/hooks/ subfile. The validation will be performed each time the git commit command is executed, depending on the Node environment. In addition, each Git project needs to introduce the corresponding NPM module for compilation, which is not convenient for many micro-service projects.
Therefore, the git-hook-Maven-plugin plugin is written, which has the following characteristics:
- It is very convenient to customize the team’s workflow in the project, including the custom hook hook script into git management class, convenient for the team to share;
- Integrate hook script installation into
Maven
To facilitate automatic installation or upgrade scripts compiled through the project; - Provides generic built-in scripts to facilitate hook configuration, currently only available
validate-commit-message
The hook script, the specification for submitting logs, followsAngularJS Git Commit Message ConventionsThe format.
For details about installation, refer to the documentation.
After configuring this, the next time we commit the code after compiling the project via Maven, if the commit log does not conform to the specification, we will get an error:
➜ project-1 Git :(master) Qualify Git commit -m "test" commit log error: First commit message line (commit header) does not follow format: type(scope): subject - Refer commit guide: https://docs.google.com/document/d/1QrDFcIiPjSLDn3EL15IJygNPiHORgU1_OOAqWjiDU5Y/edit#Copy the code
3 Feature development submission compression merge
For features that are done alone, there may be multiple commits during development, and to keep the commits clean, all the commits for this feature need to be compressed and merged. Let’s look at the code before the compression merge:
* be6e32d (HEAD->master)feat(4a7615e) E618321 下 载 内 容 E618321 下 载 内 容 e618321 下 载 内 容 e618321 下 载 内 容 Show bug fixesCopy the code
Git rebase -i = git rebase -i = git rebase -i = git rebase -i
git rebase -i e618321
Where the hash value after the command is the hash value submitted at the beginning of the compression merge:
Pick e20968e feat(Feat 0c90FCL) Submit the third file Pick 721064e feat(Test Submit): Submit the fourth file Pick 4a7615e feat(Test Submit): Modify the first file Pick be6e32d feat(Test Submit): Modify the second file# Rebase e618321.. be6e32d onto e618321 (6 command(s))
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
# d, drop = remove commit
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out
Copy the code
Note: in this interface, the submission is arranged in the order of the time of submission, with the latest submission at the bottom, as opposed to git lg.
We change the lower 2 to 6 rows to S (squash), and the first row to R (reword). Add rows 2 to 6 to the first commit and modify the commit information:
R 0c90fCL feat(b7160B3): Submit the first file Sbe6e32d feat(test Commit): Modify the second fileCopy the code
Enter :wq to save the configuration and exit the editing mode.
If a conflict occurs, modify the commit log of the conflict after the conflict is resolved.
Finally, there is a confirmation interface for submitting logs after compression and merging. Check whether the logs in the first line meet our requirements. If there is no problem, enter :wq to save and exit the editing mode.
# This is acombination of 7commits.
# The first commit'smessage is:Feat (Test Submission): Test code# This is the 2nd commit message:Feat (Test Commit): Commit the second file# This is the 3rd commit message:Feat (Test Commit): Commit a third fileCopy the code
Now that the merge is complete, we look at the commit log again and find that a commit has been merged:
Eb0121a (HEAD-> Master) feat(E618321Copy the code
Git lg: lg = log –graph –oneline –decorate. Note that this demo code runs directly on the master branch, and actually runs on the feature-xxx branch.
Principles for submitting code and compressing merge:
Rules for committing code during development: Minimize the number of commits; Before pushing, you need to compress all the code for this feature into a single commit; Before submitting the code for review, it is best to compress this artifact into a single submission
4 merge master code using rebase
Suppose we develop a new feature and have compressed and merged the code, and commit the log as follows:
* E618321 (HEAD-> feature-test) feat(HEAD->master) Show bug fixesCopy the code
At this point, the master code also has a new fix submitted:
Eb0121a (HEAD-> Master) Feat (e618321) fix this errorCopy the code
In order to maintain the merge, our current feature point is still at the latest location of the commit log, resulting in the following effect:
We use Rebase to merge the code:
git rebase master
After the merge, the result is as follows, our current feature branch is still committed first:
* 69b4ffb (HEAD -> feature-test) Feat E618321 fix Eb0121A (HEAD-> Master) FeatCopy the code
Rebase code principles:
The feature branch merge master code uses Rebase to always keep the current feature in the most recent commit; If you have multiple colleagues working on a feature, ask others to submit all code before rebase, and ask others to force native code updates after rebase.
References
Git submit correct posture: the Commit message writing guide You may ignore the Git commit specification Git hooks: customize your workflow with Node. Js write front-end own Git – hooks gist.github.com/jasonrobert…
Bash in Linux v.s Mac OS
GitUntrackedFilesMojo
First published: A Git submission specification for keeping version logs clean