:lab Support for Conventional Commits

[CamiloBernal]

Hi,

I'm a big fan of GitExtensions and use it constantly for all my projects. However, as the world of Git evolves and standardizes, the practice of "Conventional Commits" is becoming a de facto standard for many projects across the industry. It would be fantastic to have support for Conventional Commits in GitExtensions. Although Conventional Commits primarily focuses on structuring and adding value to commits, enhancing GitExtensions to better display and facilitate the use of this standard would be incredibly beneficial.

Recently, I've been experimenting with a Conventional Commits plugin for VSCode, and it's excellent. I believe the GitExtensions community would greatly benefit from a similar feature.

[CamiloBernal]

And I would complement it with this: #11616

[CamiloBernal]

Certainly, I'd be happy to elaborate on "Conventional Commits" and how they could be integrated into Git Extensions.

Conventional Commits is a specification for adding human and machine-readable meaning to commit messages. It standardizes the structure of commit messages, making them consistent and easy to navigate. This standard is beneficial for automating the process of versioning and generating changelogs, among other things. A commit message under this specification typically consists of a header, a body, and a footer. The header includes a type, an optional scope, and a succinct description of the change.

For example, a commit message might look like this:

feat(database): add 'connect' method

In this case, "feat" indicates a new feature, "database" is the scope of the change, and "add 'connect' method" is the description.

Integrating Conventional Commits into Git Extensions could involve several features:

1. Validation Tool: Implement a commit message validator that ensures commit messages adhere to the Conventional Commits specification.
2. Commit Message Templates: Offer templates within the commit window for different types of commits (feat, fix, docs, etc.), potentially customized by the user or inferred from the changes made.
3. Enhanced Log Viewing: Modify the log view to highlight or filter commits based on the Conventional Commits types and scopes, making it easier for users to navigate through the commit history.
4. Automation Helpers: Integrate with tools or scripts that automate versioning and changelog generation based on commit history, offering users an easy way to manage releases.

These enhancements could significantly improve the Git Extensions user experience by making commit histories more structured, navigable, and informative. It would also align Git Extensions more closely with current industry practices, benefiting developers who work on multiple projects or teams that adopt the Conventional Commits standard.

I hope this explanation clarifies what Conventional Commits are and how their integration into Git Extensions could be envisioned. I believe these features would be a valuable addition to Git Extensions, enhancing its utility and adoption.

[RussKie]

Have you looked at commit templates?

[CamiloBernal]

Yes, I have explored the commit templates feature, and while it's a step in the right direction, I've found it somewhat lacking in terms of facilitating a smooth workflow for Conventional Commits. The main challenge is that the templates don't inherently guide the user through the structured format required by Conventional Commits, such as specifying the type, scope, and description in a standardized way.

Additionally, the templates don't enforce any validation to ensure the commit messages adhere to the Conventional Commits specification, which can lead to inconsistent application of the standard across a project. Also, they lack the dynamic nature of suggesting or auto-completing types and scopes based on the project's history, which can significantly streamline the commit process and reduce errors.

Ideally, an enhanced feature within Git Extensions would not only offer templates but also provide:

A user-friendly interface to guide the creation of commit messages according to the Conventional Commits format.
Validation checks to ensure compliance with the specification before a commit is finalized.
Dynamic suggestions for types and scopes based on the repository's commit history, improving efficiency and consistency.
This approach would greatly support maintaining a clean and navigable commit history, which is invaluable for automated changelog generation and version management, among other benefits.

[RussKie]

Necessary disclaimer: Git Extensions is a community project maintained by the team of dedicated volunteers. If this feature is something you really wish to see in the application, then you're in the best position to drive it - i.e., come up and propose a design, work through edge cases, feedback, etc. Then come up with a prototype, etc.

Perhaps this could be done as a plugin? Similar to JIRA template plugin.

Here are just few "top of the head" questions that need to be explored and detailed in the proposal:

• How do you expect an enforcement of CC format at the repo level? E.g., a contributor sends a patch via an email or makes a pull-request via GitHub web interface... The enforcement of the CC format at the app level should be consistent with any other policy enforcement if contributor isn't using the app.
• Would an individual be required to use CC format to contribute to a given repository or would it be an opt-in thing? If required, how would the individual find that out (he/she just got the link and cloned the repo)? What would be the user experience?
• How do you expect an enforcement of CC format at the app level? That is, what would be the user experience?

[pmiossec]

I have developed a support of conventional commit message and gitmoji (but not 100% satisfied for this one) in my fork.
I will create a PR for the 1st one at least.

[vbjay]

Nothing wrong with them. Seems useful but it's the same problem as signing. If everyone doesn't use it in the repo, kinda useless. Aso the question of what do you define support as?

Do you envision a commit message helper drop down or autocomplete suggesting the types?

Do you envision commit message validation updates?

You are saying support them without providing any concrete ideas on what that means.

[vbjay]

#11662 (reply in thread)

Looks like you and I were posting comments at same time.

[CamiloBernal]

I was thinking that views like this could be enriched with information from conventional commits (by example).

In addition to facilitating the "build" the commit message, similar to how this extension for VSCode does it: https://github.com/vivaxy/vscode-conventional-commits

[vbjay]

Here is what I'd do. Take a minute. Come up with what you feel that would look like. Come up with areas where it could do stuff. Maybe a look at release notes generator plugin. But I think you have a rough idea without an actual firm plan.

Create the plan. Describe it. Think it through.