Update from obsidian - thinkpad
Affected files: .obsidian/plugins/dataview/data.json .obsidian/plugins/obsidian-omnivore/data.json Read Later/2023-10-14 - Using CSS custom properties like this is a waste - YouTube.md Read Later/2023-10-14 - You Don’t Actually Want Open World Games - YouTube.md Read Later/2023-10-15 - Highlighting fold text, community fork of null-ls, leetcode integration, reduce ram ....md Read Later/2023-10-18 - The Unreasonable Effectiveness Of Plain Text.md Read Later/2023-10-21 - How Game Reviews Actually Affect You.md Read Later/2023-10-23 - Study shows stronger brain activity after writing on paper than on tablet or smartph....md Read Later/2023-10-23 - Train Your Brain to Be More Creative.md Read Later/2023-10-25 - Let's Get Webby! 🦀 🕸️.md Read Later/2023-10-25 - What the Rust Book didn't tell you about testing....md Read Later/2023-10-31 - Use cases for Rust.md Read Later/2023-11-01 - Why Signals Are Better Than React Hooks.md Read Later/2023-11-02 - The First Rule of Comments in Code.md Read Later/2023-11-02 - Web Accessibility Tips for Developers – A11y Principles Explained.md Read Later/2023-11-04 - Git Merge vs Rebase vs Squash ¿Qué estrategia debemos elegir-.md Read Later/2023-11-06 - How to Write Components that Work in Any Framework.md Read Later/2023-11-07 - How to Avoid Prop Drilling in React.md Read Later/2023-11-10 - The Complete Guide to Time Blocking.md Read Later/2023-11-14 - The one thing you need to finish your game.md Read Later/2023-11-21 - Career Mistakes to Avoid as a Developer.md Read Later/2023-11-21 - Conventional Commits.md Read Later/2023-11-21 - How to Write Better Git Commit Messages – A Step-By-Step Guide.md Read Later/2023-11-21 - The Life-Changing Magic of Tidying Up Your To-Do List.md Read Later/2023-11-21 - tbaggery - A Note About Git Commit Messages.md Read Later/2023-12-24 - Historias de usuario - Ejemplos y plantilla - Atlassian.md Read Later/2023-12-24 - ¿Qué son los puntos de historia en la metodología ágil y cómo se estiman-.md Read Later/2024-02-15 - React Optimization Techniques to Help You Write More Performant Code.md Read Later/How to Learn Rust.md Read Later/The Secret Power of ‘Read It Later’ Apps.md
This commit is contained in:
parent
1e55015bab
commit
7437d8e57c
30 changed files with 2578 additions and 561 deletions
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
id: 01b3b6c1-27ae-40a4-99fa-d297febc1e7c
|
||||
title: |
|
||||
tbaggery - A Note About Git Commit Messages
|
||||
status: ARCHIVED
|
||||
tags:
|
||||
- read-later
|
||||
date_added: 2023-11-21 11:59:10
|
||||
url_omnivore: |
|
||||
https://omnivore.app/me/https-tbaggery-com-2008-04-19-a-note-about-git-commit-messages-h-18bf2646727
|
||||
url_original: |
|
||||
https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
|
||||
---
|
||||
|
||||
# tbaggery - A Note About Git Commit Messages
|
||||
|
||||
## Notes
|
||||
|
||||
- Tratar de mantener el limite que muestra Treesitter
|
||||
- Utilizar la primera linea como "el asunto de un correo"
|
||||
- Escribir el cuerpo con una separación de una linea en blanco
|
||||
- Usar lenguaje imperativo, _"Fix bug"_ en vez de _"Fixes bug."_.
|
||||
## Original
|
||||
|
||||
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:
|
||||
|
||||
```livecodeserver
|
||||
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](http://github.com/tpope/vim-git), or by simply setting the following option in your git commit message file:
|
||||
|
||||
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:
|
||||
|
||||
```lsl
|
||||
$ 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.
|
||||
Loading…
Add table
Add a link
Reference in a new issue