🧱 Automatos Commit & Branch Naming Standards

Version: 1.0
Applies to: All Automatos projects (web + mobile)
Effective Date: October 2025

⚙️ Overview

This document defines how branches and commits are named across all Automatos repositories.
Our goals:

• Maintain consistent project history

• Enable future CI/CD automation and changelog generation

• Make PR reviews and issue tracking effortless

• Keep commit history readable by both humans and tools

Automatos follows GitFlow as the branching strategy and Semantic Commits for message formatting.

🌿 Branch Naming Convention

Branches must follow this format:

<type>/<project-prefix>-<issue-number>-<short-description>

Examples

Branch Type Meanings

💬 Commit Message Convention

Automatos uses Semantic Commit Messages with Issue linkage.

<type>(<scope>): <short summary> [<emoji>] [<issue-ref>]

Required Fields

Commit Types

Examples

feat(auth): add Google sign-in support (#31)
fix(navbar): correct alignment on mobile (#42)
chore(ci): integrate EAS build step in pipeline (#55)
docs(api): document user endpoints (#66)

🧩 Optional: GitMoji for Visual Context

GitMoji can be used sparingly for readability, or if you want to make things a little more boujee. They must be placed after the colon, before the message, and should not replace semantic types.

🔗 Linking to GitHub Issues

Every commit must reference its issue number using the (#issueNumber) format.

• ✅ Correct: feat(auth): add token refresh support (#12)

• 🚫 Incorrect: feat(auth): add token refresh support FW-12

• 🚫 Incorrect: feat(auth): add token refresh support (12)

This ensures automated tools like changelog generators, release notes, and issue auto-closing work correctly.

🚀 Example Workflow

1. Create an issue on GitHub.
   Example: “Setup CI/CD Pipeline” (#31)

2. Create a branch:

    git checkout -b feature/FW-31-setup-ci-cd
       
   

3. Make commits:

    git commit -m "feat(ci): add EAS build step to pipeline (#31)"
    git commit -m "chore(ci): configure cache for dependencies (#31)"
       
   

4. Push & open a PR:
   PR title:

    FW-31 | Setup CI/CD Pipeline (#31)
       
   

5. On merge:

   • The issue closes automatically.

   • The commit contributes to the changelog.

🧠 Why This Matters

✅ Quick Reference

Example in Context

Branch

feature/FW-31-setup-ci-cd

Commit

feat(ci): add EAS build step to pipeline (#31)

PR Title

FW-31 | Setup CI/CD Pipeline (#31)

🚫 Common Mistakes to Avoid

🤓👆 Conclusion

This is the first edition of how we’ll we be writing commits with potentially many updates to come as we scale insha’Allah. I’ve chosen this particular style for 2 main reasons:

1. Integration with automated project management tools as we create a fully automated system that self-enforces standards upon us. No more yelling at someone k bhai ye kardo ya iss tara karna tha and so on.
2. The ability to trace screw-ups so we can revert back quickly.

I’ll be following this with another standardization on our entire dev process. For now, please follow this 🤗

📘 References

• Conventional Commits 1.0.0

• GitFlow Workflow

• GitMoji Guide

In short:
Every branch and commit should be machine-readable, human-understandable, and automation-friendly.
A perfect commit history tells the story of the product — clean, contextual, and consistent.