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 intoMavenTo facilitate automatic installation or upgrade scripts compiled through the project;
  • Provides generic built-in scripts to facilitate hook configuration, currently only availablevalidate-commit-messageThe 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