Hey, I'm very interested in this topic. I use a general template for commit messages that Linus himself suggested
Single problem is that when I'm doing let's say multiple commits on a feature, for the first commit I use the template(that i have set up as default) and for the other commits i use -m messages
When the feature is ready for Pull Request, basically i do an interactive rebase for the specific feature where I squash all the commits into a single one and use message template
After that I force a push on the feature branch and rewrite all the commits into a single one for a specific feature branch
Here is the message template:
<TICKET> Summarize changes in around 50 characters or less
If applied, this commit will refactor subsystem X for readability
If applied, this commit will update getting started documentation
If applied, this commit will remove deprecated methods
If applied, this commit will release version 1.0.0
If applied, this commit will merge pull request #123 from user/branch
If applied, this commit will <commit subject>
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 consequenses 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:
Resolves: <TICKET>
See also: <TICKET>, <TICKET>
Acked-by: FirstName LastName<email>
Signed-off-by: FirstName LastName<email>
Awesome! Have you tried the "Squash and Merge" option at GitHub PR?
Also, this is a very well detailed template!
I think this is good for big changes as git itself doesn't have the concept of Pull Request and Linus receive the patches via email. For me, I prefer maintain the commits minimal and simple, describing each commit what I've done so far. Something like:
Totally agree, using the template I showed can be a real pain sometimes but after the feature is finished and all commits are squashed into a single one with the complex message it makes it easier over the year to keep track of the work on the project.
Thank you very much for your template, I want to take yours and add some details from the one I use for future reference
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Hey, I'm very interested in this topic. I use a general template for commit messages that Linus himself suggested
Single problem is that when I'm doing let's say multiple commits on a feature, for the first commit I use the template(that i have set up as default) and for the other commits i use -m messages
When the feature is ready for Pull Request, basically i do an interactive rebase for the specific feature where I squash all the commits into a single one and use message template
After that I force a push on the feature branch and rewrite all the commits into a single one for a specific feature branch
Here is the message template:
Awesome! Have you tried the "Squash and Merge" option at GitHub PR?
Also, this is a very well detailed template!
I think this is good for big changes as
gititself doesn't have the concept of Pull Request and Linus receive the patches via email. For me, I prefer maintain the commits minimal and simple, describing each commit what I've done so far. Something like:The leged to it is:
type: feat, refactor, style, chore, fix...scope: not necessary but can give a little information about itshort description: describe in 50 letters or less if that commit is applied, what it'll dolong description: describe architectural choices, options, usage of code, why you pick your approach and things like thatreference: can be tickets, issues or external references to JIRA or other softwaresThis is what works for me! 😄
I agree with Ilê for minor tasks I like to do in the same way as he talked.
Personally, I think this more complete template can be applied to huge projects or more specificaly features.
Totally agree, using the template I showed can be a real pain sometimes but after the feature is finished and all commits are squashed into a single one with the complex message it makes it easier over the year to keep track of the work on the project.
Thank you very much for your template, I want to take yours and add some details from the one I use for future reference