Standardize Commit Message Formatting with Template Support

bryans-go commented 3 hours ago

Is your feature request related to a problem? Please describe. In my current workflow, the inconsistency in commit message formats leads to confusion and inefficiencies. Many team members often skip providing detailed context, making it challenging to trace the evolution of our codebase. This has resulted in frustrations during code reviews and when attempting to understand the history of changes.

Describe the solution you'd like I propose implementing a commit message template to enforce a clear and structured format. This template should guide developers in writing informative messages that capture the essence of each change. Here’s a suggested format:

Commit Message Template

<type>(<scope>): <subject>

<body>

<footer>

Breakdown:

<type>: Indicates the nature of the change (e.g., feat for features, fix for bug fixes).
<scope>: Optional. Describes the affected module or feature.
<subject>: A brief, imperative description (max 72 characters).
<body>: Detailed explanation (optional), wrapping at 72 characters.
<footer>: References issues (e.g., Closes: #123) or breaking changes.

Example Usage:

feat(auth): add user login functionality

This commit introduces user login via email and password.

Closes: #42

Additional context I'm talking about this git config --global commit.template ~/.gitmessage.txt. either we setup this automatically for user or the user can do this manually through daytona while adding git providers (advanced settings) or we can setup elsewhere

Tpuljak commented 3 hours ago

@bryans-go you basically described https://www.conventionalcommits.org/en/v1.0.0/ which we are already following 😅

What does this issue propose that we do in Daytona exactly?

bryans-go commented 3 hours ago

I'm talking about this git config --global commit.template ~/.gitmessage.txt. either we setup this automatically for user or the user can do this manually through daytona while adding git providers (advanced settings) or we can setup elsewhere

Tpuljak commented 3 hours ago

Ah, I see what you're getting at.

Automatically setting this up would be too intrusive but it's something that user can set up for themselves using dotfiles which we plan to support with https://github.com/daytonaio/daytona/issues/963.

I'll close this as not planned since the functionality is covered by another issue.

daytonaio / daytona