Skip to content

Instantly share code, notes, and snippets.

@rouzbeh84

rouzbeh84/.gitmessage

Last active September 19, 2017 22:15
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rouzbeh84/73962b0aa626b60dd1c2af16093b5dbc to your computer and use it in GitHub Desktop.
Save rouzbeh84/73962b0aa626b60dd1c2af16093b5dbc to your computer and use it in GitHub Desktop.
Download ZIP
comgitit
Raw
.gitmessage
# <type>(<scope>): <subject>
#
# <body>
#
# <footer>
#
# ** TYPES **
# feat (new feature)
# fix (bug fix)
# docs (changes to documentation)
# style (formatting, missing semi colons, etc; no code change)
# refactor (refactoring production code)
# test (adding missing tests, refactoring tests; no production code change)
# chore (updating grunt tasks etc; no production code change)
#
# ** FOOTERS **
# References #1, #4, and #2.
# Fix #1. note this marks the item as accepted in Sprintly
# Closes #1 and #2. note this marks the item as accepted in Sprintly
# ** Funtip **
# Work hard, play hard! Consider prefixing your commit messages with a relevant emoji for
# great good:
#
# :art: `:art:` when improving the format/structure of the code
# :racehorse: `:racehorse:` when improving performance
# :non-potable_water: `:non-potable_water:` when plugging memory leaks
# :memo: `:memo:` when writing docs
# :penguin: `:penguin:` when fixing something on Linux
# :apple: `:apple:` when fixing something on Mac OS
# :checkered_flag: `:checkered_flag:` when fixing something on Windows
# :bug: `:bug:` when fixing a bug
# :fire: `:fire:` when removing code or files
# :green_heart: `:green_heart:` when fixing the CI build
# :white_check_mark: `:white_check_mark:` when adding tests
# :lock: `:lock:` when dealing with security
# :arrow_up: `:arrow_up:` when upgrading dependencies
# :arrow_down: `:arrow_down:` when downgrading dependencies
# :shirt: `:shirt:` when removing linter warnings
Raw
commit-guide.md

Git

credit to Sparkbox.

Never forget all this juicy knowledge! Set your commit message template to this wonderful example, by running:

git config --global commit.template "path/to/.gitmessage"

The Art of the Commit Message

We use a strict style for all of our commit messages. The style we use helps ensure that our commits stay small and are easy to browse.

The Layout

<type>: <subject>

<body>

<footer>

The Title (the first line)

The title consists of the <type> 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>

  • feat (new feature)
  • fix (bug fix)
  • docs (changes to documentation)
  • style (formatting, missing semi colons, etc; no code change)
  • refactor (refactoring production code)
  • test (adding missing tests, refactoring tests; no production code change)
  • chore (updating grunt tasks etc; no production code change)

Subject

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

Funtip

Work hard, play hard! Consider prefixing your commit messages with a relevant emoji for great good.

  • 🎨 :art: when improving the format/structure of the code
  • 🐎 :racehorse: when improving performance
  • 🚱 :non-potable_water: when plugging memory leaks
  • 📝 :memo: when writing docs
  • 🐧 :penguin: when fixing something on Linux
  • 🍎 :apple: when fixing something on Mac OS
  • 🏁 :checkered_flag: when fixing something on Windows
  • 🐛 :bug: when fixing a bug
  • 🔥 :fire: when removing code or files
  • 💚 :green_heart: when fixing the CI build
  • ✅ :white_check_mark: when adding tests
  • 🔒 :lock: when dealing with security
  • ⬆️ :arrow_up: when upgrading dependencies
  • ⬇️ :arrow_down: when downgrading dependencies
  • 👕 :shirt: when removing linter warnings

Example:

:fire: feat (buybox): removed unused container elements

The Body

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

Inspired by Karma's commit style.

The 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.

Raw
commit-tips.md

A Note About Git Commit Messages via TBaggery 19 Apr 2008

I want to take a moment to elaborate on what makes a well formed commit message. I think the best practices for commit message formatting is one of the little details that makes Git great. Understandably, some of the first commits to rails.git have messages of the really-long-line variety, and I want to expand on why this is a poor practice.

Here’s a model Git commit message:

Capitalized, short (50 chars or less) summary

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 an email 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); tools like rebase can get confused if you run the two together.

Write your commit message in the imperative: "Fix bug" and not "Fixed bug" or "Fixes bug." This convention matches up with commit messages generated by commands like git merge and git revert.

Further paragraphs come after blank lines.

  • Bullet points are okay, too

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

  • Use a hanging indent Let’s start with a few of the reasons why wrapping your commit messages to 72 columns is a good thing.

git log doesn’t do any special special wrapping of the commit messages. With the default pager of less -S, this means your paragraphs flow far off the edge of the screen, making them difficult to read. On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns. git format-patch --stdout converts a series of commits to a series of emails, using the messages for the message body. Good email netiquette dictates we wrap our plain text emails such that there’s room for a few levels of nested reply indicators without overflow in an 80 column terminal. (The current rails.git workflow doesn’t include email, but who knows what the future will bring.) Vim users can meet this requirement by installing my vim-git runtime files, or by simply setting the following option in your git commit message file:

:set textwidth=72 For Textmate, you can adjust the “Wrap Column” option under the view menu, then use ^Q to rewrap paragraphs (be sure there’s a blank line afterwards to avoid mixing in the comments). Here’s a shell command to add 72 to the menu so you don’t have to drag to select each time:

$ defaults write com.macromates.textmate OakWrapColumns '( 40, 72, 78 )' More important than the mechanics of formatting the body is the practice of having a subject line. As the example indicates, you should shoot for about 50 characters (though this isn’t a hard maximum) and always, always follow it with a blank line. This first line should be a concise summary of the changes introduced by the commit; if there are any technical details that cannot be expressed in these strict size constraints, put them in the body instead. The subject line is used all over Git, oftentimes in truncated form if too long of a message was used. The following are just a handful of examples of where it ends up:

git log --pretty=oneline shows a terse history mapping containing the commit id and the summary git rebase --interactive provides the summary for each commit in the editor it invokes if the config option merge.summary is set, the summaries from all merged commits will make their way into the merge commit message git shortlog uses summary lines in the changelog-like output it produces git format-patch, git send-email, and related tools use it as the subject for emails reflogs, a local history accessible with git reflog intended to help you recover from stupid mistakes, get a copy of the summary gitk has a column for the summary GitHub uses the summary in various places in their user interface The subject/body distinction may seem unimportant but it’s one of many subtle factors that makes Git history so much more pleasant to work with than Subversion.

Raw
examples.md

Example Commit Messages

feat: 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: 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

feat: 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

style: add couple of missing semi colons

docs: updated fixed docs from Google Docs

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

feat: 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.
Raw
github-actions.md

The following keywords, followed by an issue number, will close the issue:

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

For example, to close an issue numbered 123, you could use the phrases "Closes #123" in your pull request description or commit message. Once the branch is merged into the default branch, the issue will close.

Closing an issue in the same repository

To close an issue in the same repository, use one of the keywords above followed by a reference to the issue number. For example, a commit message with Fixes #45 will close issue 45 in that repository once the commit is merged into the default branch.

If the commit is in a non-default branch, the issue will remain open and the issue will be referenced with a tooltip.

Closing an issue in a different repository

To close an issue in another repository, use the username/repository#issue_number syntax, as described in "Autolinked references and URLs."

For example, including Closes example_user/example_repo#76 will close the referenced issue in that repository, provided you have push access to that repository.

Closing multiple issues

To close multiple issues, preface each issue reference with one of the above keywords. You must use the keyword before each issue you reference for the keyword to work.

For example, This closes #34, closes #23, and closes example_user/example_repo#42 would close issues #34 and #23 in the same repository, and issue #42 in the "example_user/example_repo" repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment