Skip to main content
Hashnode
Powsi's BlogPowsi's Blog

Git Development Workflow Standards

Updated 3 min readMarkdown
P
Powsihan
Git Development Workflow Standards

This document defines a standardized naming convention for branches, commit messages, and pull requests (PRs). The goal is to

  • Improve clarity and traceability
  • Link work clearly to task IDs (Azure/Asana)
  • Make code reviews faster
  • Keep Git history clean and professional

Branch Naming Convention

General Format

<type>/<task-id>-<short-description>

Allowed Branch Types

Type Usage
feature New features
bugfix Bug fixes (non-production)
hotfix Critical production fixes
refactor Code restructuring without behavior change
chore Maintenance tasks (dependencies, configs)
test Test-related work

example

feature/p-777-admin-layout

Branch Naming Rules

  • Use lowercase only
  • Use hyphens (-), never underscores
  • Keep description short and meaningful
  • No spaces

Commit Message Convention

Commit Format

<task-id> <type>: <short description>

Allowed Commit Types

Type Meaning
feat New feature
fix Bug fix
hotfix Critical production fix
refactor Code refactor
test Tests
chore Maintenance

example

p-777 feat: admin layout created

p-777 fix: build issue fixes

p-985 refactor: simplify auth middleware

Commit Rules

  • One logical change per commit
  • Use present tense (add, fix, update)
  • No capital letters at the beginning of description
  • No period at the end

Pull Request (PR) Naming Convention

PR Title Format

  • dev PR

[<stack-tag>] <task-id> <type>: <clear summary>

example

[FE] P-1007 feat : implement admin layout

  • production or staging PR

[<tag>] <date>: [<stack-tag>] [<task ids>]

example

[PRODUCTION] 07/01/26: [FE] [p-1005,p-1002,p-979]

Tag format

Tag Meaning
FE frontend releated PR
BE backend releated PR
FS fullstack releated PR
PRODUCTION production PR
STAGING staging PR

Tags are used to classify Pull Requests in GitHub based on their status, scope, type, priority, and deployment stage.
They help teams track progress, streamline reviews, and manage releases efficiently without relying on PR titles or commit messages.

Tag Format

Tag Purpose
released this pr already released in production or staging
pending this pr some commit not released in production or staging
staging Intended for staging deployment
production Intended for production deployment
FE Frontend-related PR
BE Backend-related PR
FS Fullstack-related PR

10 views

About the author

  • Powsihan
    I'm a Software Engineer with a strong interest in frontend engineering, software architecture, and building reliable applications. My work has given me opportunities to explore different parts of software development, from React and Next.js applications to backend services, CI/CD pipelines, and production deployments. I enjoy understanding why things are built a certain way, solving technical problems, and finding ways to make systems easier to maintain.

Comments

Join the discussion

No comments yet. Be the first to comment.

More from this blog