How can you write better commit messages?

Actually, commit messages shouldn't be overburdened. I'd advise developers to primarily describe the problems they've resolved. Emphasize navigational clarity in the details, rather than providing exhaustive explanations about the "how." These messages aid in navigating a PR or branch during reviews, whether by peers, supervisors, or newcomers seeking to understand the evolution of the codebase

Commit message are important for anyone in the company, but you can feel its value when you have new members in the team who aren’t familiar with your standards… why? Cause by spending time in the team, you will be familiar with the concepts you have been using for a while, but once a new member came and understood what you are doing, this can be considered as one of the key successes. The second thing which is FORGETTING… As humans that’s normal to forget what we are doing here, that’s why the commit message always a reference for you and others to remember what was done. Different commits with different messages and different work is a good thing as well to facilitate the code review and the process for you and your team mates.

Another benefit of good commit messages is that you can automatically create changelogs which can be added to your documentation or just server as an audit trail of what changed between versions. This saves a lot of time in the long run.

In my experience you can Elevate Collaboration by using Effective Commit Messages by following below guidelines: 🖊️ 💡 1. Be Descriptive: Clear summaries for quick insights. 2. Imperative Mood: Start with a directive verb. 3. Reference Issues: Tie changes to context. 4. Avoid Ambiguity: Specify updates and reasons. 5. Concise & Clear: 50 characters for subject line. 6. Separate Concerns: Distinct, focused commits. 7. Proofread: Reflects professionalism. Commit messages guide teams through code. They track changes and troubleshoot. Embrace these practices for seamless collaboration!💻📝 #CommitMessages #CollaborationTips #CodeQuality

The main purpose of a commit message is to provide clear and concise information about the changes made in a commit. The commit message should be able to explain the changes made in that commit. It should not be more than that. It should not be more than 50-70 characters.

Writing better commit messages is like telling a hilarious joke at a library: it should be concise, informative, and leave no room for confusion. Imagine your code changes are the punchline, and your commit message is the setup – make it witty, but don't turn it into a stand-up show; version control can be a tough crowd! So, keep it short, sweet, and as clear as a dad joke on a sunny day.

Over the years I have used smart commits which automatically connects your Jira issue with commit. As for the message, I prefer to one liner in most cases otherwise maybe we are doing a lot in one commit. The commit message should be clear and concise and should say what this commit does. It should sound like, this commit does this. For instance, "adds custom links in the bio" OR "improves user profile views query performance".

As senior programmers’ advice: - write needed information with as few words as possible. - Make it super easy to understand. - If more/much information needed, create a link to it. - If having a ticket system, write the ticket no.

I love conventional commit styling. Here is a real example my teams follow: ---- refactor(job-carousel): modified posted x weeks ago to support weeks Previously the days were only being converted into months and years. Now we have added the support for weeks. The module calculates the nearest correct value and rounds it off properly. - Posted X days ago - Posted X weeks ago - Posted X years ago. ---- Clear commit messages make the history clean. It needs a bit of training from the leadership but adds great value. Reach out if your team needs my help 😉

I’ve heard it said that your messages should be telling git what to do. Example: Git, “Fix for loop bug” in your remote repo. Rather than: Git, “Fixes the loop bug” in your remote repo. But at the end of the day, the most important mood to choose in your messages is the one the rest of the team uses. This will create a cleaner history as you wont have switching between present and past tense.

Richard Piacentini, were your devs happy to see CC police their commit messages? I've known about CC for a long time, but I've never been on a team that used it. I kept wondering if CC garners as much developer hate as it does love. :D Kinda like the same wonder I have about TDD too! It's the kind of coding discipline like flossing teeth, and I've never met a person who likes flossing. The kind of discipline everyone wishes were already in-place when a critical Prod bug pulls all the devs into a conference room the next morning doing the post-mortem, and then see commit-messages like "Fix code." :D

You can use tools like commitlint combined with Git Hooks to enforce some styles, however, IMHO in the end of the day what really matters is the mindset of the team and the person writing the commit messages.

For open source projects, include the full URL to the issue tracker instead of just the issue number, even if you use GitHub or GitLab where issue numbers are automatically linked. This is useful if your project (or a fork) decides to move the code or issue tracker elsewhere: Having the full URL ensures that future contributors can still access previous issue reports in the old location.

Below some examples: ❌ "Update database" ✅ "Migrate user table to add email column" ❌ "Improve loading" ✅ "Reduce load time by optimizing image sizes" ❌ "Refactor code" ✅ "Refactor payment processing to use Strategy Pattern" ❌ "Bug fixes" ✅ "Fix race condition in user session handling" ❌ "Enhance login" ✅ "Add 2-factor authentication to login process"

If you work with backlog, in the title of the PR add the title or number of the backlog item, so that it is more evident which change the PR refers to, for example. Item: 987-XXX, or Item 987-XXX - Change table column. In commit messages, add each one with the task title as a commit message, so there is more control over each change.

An example would be ... "[number] ; [Brief description of the resolution]" ABC-001 ; Added a new column in the database table AAA and also added it in the class model Aaa.

I truly recommend reading the commit messages from huge code bases like: - Linux - OSS packages You can pick some great insights from there.

It’s better to write a clear, understandable & meaningful messages, This can be achieved by considering the below points: 1. Identify the type of the commit like if it’s: feature, hotfix, fix, merge, etc… 2. Identify the feature which will have these changes like: loginScreen, homeScreen, etc… 3. You can map each change with an image to be catchy like: update ✨, fix 🔧,etc… 4. Describe the changes you have done in this commit like: Changing the design of the login button. 5. If you are using smart commit, you can link it to your Jira card like: [App-123] By the end instead of having that: ❌ Update the button design ❌ 💡 We will have ✅ Feature(loginScreen) ✨Update the login button design. [App-123]

The structure I personally like to follow, an inspiration from conventional commit standard: <kind>: <what> <why> Signed-off-by: <whom> There could be more than one sign-offs, and kind can be feature, bugfix, documentation etc. The 'how' part should be self-explanatory from the commit itself!

When writing git commit messages, we should keep an eye on the following: - Do not include description in the commit message - Avoid including any reference to tracking tools. e.g Jira Id

Use the summary as an introduction to summarize the code change, and don’t try to explain everything in one line. Remember that you’ve the body in your favor. Also, if possible, keep options like “Squash commits” after merging it will squash all the commits messages into bullet points making it readable to the people who want to check it later.

To enhance your commit messages over time: 1. Prioritize clear and concise subject lines. 2. Include context in the commit body. 3. Reference related issues or tasks. 4. Be consistent with your message structure. 5. Learn from examples and embrace feedback for improvement.

Draft commits before changing code. Preview your coding intentions to help focus on a clear set of changes. Clarity in your commit leads to clarity in your summary.

Building a culture around good commit messages is important to cultivating a shared language in a team/project. When everyone speaks the same 'code language', understanding flourishes. But how do we foster this culture? 1) Highlight Issues: Show real problems caused by unclear commits. And be empathetic when you do this. 2) Train: Host workshops using real code examples to teach clear messaging. 3) Feedback/Review: Use Code review sessions to review and give feedback on commit clarity. 4) Lead by Example: Leaders should model clear commits, setting the standard. 5) Celebrate: Spotlight great commit messages to motivate the team. Always remember to be empathetic towards the team. They will make mistakes - And Its okay :)

Writing commit messages, tagging the releases and ticket id inside commit message always helps to backtrack when needed, having the culture about this and standard around what and how the commit should be written with message always sets the direction.

A good tool to make your follow standard commit formats is to use commitlint. Helps remind if a person is using wrong commit msg

Include in commit message an ID of the story the commit is part of (feature, bug, etc) which then allows scraping the commit messages to build up a list of stories, and from those extract testing parameters thereby allowing targeted testing of a set of changes automatically. E.G. if a story contains a field pointing to a test script, then for a set of commits can extract a list of test scripts to run as a sanity check of that group of commits as part of a continuous integration testing system - invaluable to make sure a large number of changes by multiple developers doesn't break things.

If you're using Git, use "history rewriting" features to avoid clogging the commit history with unnecessary entries. For example, if you commit some code with a typo and then fix the typo, it's not necessary to have "Add ABC" immediately followed by "Fix typo". For simple cases like typo fixes, Git provides the option to "amend" the most recent commit. For more complex cases, interactive rebase can be used to merge different commits, even out of order. I've used this to clean up a series of commits like "Add A", "Add B", "Fix typo in B", "Change variable names in A" before submitting for review. In any case, make sure you do this before pushing (i.e., while the commits are only on your machine).