I follow this guide to ensure that all my work in Git is clear, consistent, and traceable, supporting collaboration and long-term maintainability of Fossil Logic projects.

1. Commit Messages

• I write commit messages that clearly describe what I did and why.
• I use the following structure:

<type>(<scope>): <short summary>

[optional detailed description]

<type>(<scope>): <short summary>

[optional detailed description]

[optional references, e.g., issue numbers]

• Type examples: feat (new feature), fix (bug fix), docs (documentation), refactor, test, chore.
• I keep the short summary under 50 characters.
• I separate the subject line from the body with a blank line.
• I wrap body text at 72 characters.
• I avoid vague messages like “update” or “fix stuff.”

2. Branching

• I follow a clear branching strategy:
  • main – stable, production-ready code.
  • develop – integration branch for ongoing work.
  • Feature branches – named feature/<description>.
  • Bugfix branches – named bugfix/<description>.
  • Hotfix branches – named hotfix/<description> for urgent fixes.
• I merge only tested and reviewed code into develop or main.

3. Commit Practices

• I commit small, logical units of work rather than large unrelated changes.
• I stage changes carefully to include only relevant files.
• I write one commit per logical change whenever possible.
• I avoid committing generated files or secrets.

4. Merging

• I prefer merge requests (pull requests) over direct merges to main or develop.
• I rebase feature branches before merging to maintain a clean history.
• I resolve conflicts locally and clearly explain conflict resolution in the commit message.

5. Tags and Releases

• I use annotated tags for releases, following semantic versioning: v<major>.<minor>.<patch>.
• I include a short description in the tag message when relevant.

6. Review and Collaboration

• I request reviews for all significant changes.
• I respond constructively to review feedback and make necessary updates.
• I review pull requests thoroughly before merging to maintain code quality.

7. Documentation

• I maintain clear README updates for features or workflow changes.
• I document branch purposes, Git workflows, and any custom hooks or scripts.

8. Best Practices

• I pull the latest changes before starting work.
• I avoid force-pushing to shared branches unless absolutely necessary and communicated.
• I use .gitignore appropriately to keep repositories clean.
• I maintain a consistent commit and branch style for the whole team.