Skip to content

git commit messages

Jump to bottom Edit New page
Lars Moelleken edited this page Jul 23, 2016 · 4 revisions

Git

Git plus GitHub

You should use (git) version control for all of your projects! You can host our code e.g. on GitHub, Gitlab or Bitbucket. Large features get their own branch and are merged with a pull request.

Good commit messages serve at least three important purposes:

  • To speed up the reviewing process.
  • To help us write a good release note.
  • To help the future maintainers (it could be you!), say five years into the future, to find out why a particular change was made to the code or why a specific feature was added.

Install

  1. add this file into your home-dir

https://github.com/voku/dotfiles/blob/master/.gitmessage

  1. add this into your "~/.gitconfig"-file
[commit]
  template = ~/.gitmessage

The Layout

<type>: <scope> -> <subject>

<body>

<footer>

The Title (the first line)

The title consists of the <type>, <scope> and the <subject>.

Protip: Find yourself with an and in that commit title? Consider breaking the commit down. git commit -p is your friend!

Allowed Values for <type>

  • [+]: feature, test, fix
  • [*]: documentation, code-style, fix linter warning; no code change
  • [~]: refactoring production code
  • [!]: breaking changes, so pay attention
  • [!!!]: security fix, so caution

Scope

This is just the scope of the change. Something like (dashboard) or (backend).

Subject

An [imperative tone][365] is also helpful in conveying what a commit does, rather than what it did. For example, use change, not changed or changes.

Example:

[+]: functions -> update "targz()"

The Body

The body of the commit message should use a style similar to the one proposed in this [article by tpope][tpope]. The body, just like the subject, should use an imperative tone.

Footer

Here you can reference issues and pull-requests that relate to your commit, like so:

closes #125

You can see the official Github doc for all the keywords to close issues and pull-requests.

Example Commit Messages

[+]: example -> summarize changes in around 50 characters or less

More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.

Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.

Further paragraphs come after blank lines.

 - Bullet points are okay, too

 - Typically a hyphen or asterisk is used for the bullet, preceded
   by a single space, with blank lines in between, but conventions
   vary here

If you use an issue tracker, put references to them at the bottom,
like this:

closes #123
see also at #456, #789
#time 2h 
notification for @voku

[+]: frontend -> added 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

[+]: frontend -> fix 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

[*]: docs -> add couple of missing semi colons

updated fixed docs from Google Docs

Couple of typos fixed:
- indentation
- batchLogbatchLog -> batchLog
- start periodic checking
- missing brace

[!]: 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: '@',
  myBind: '@',
  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.

Links

Add a custom footer
Add a custom sidebar
Clone this wiki locally