Skip to content

Git Standards

This document outlines our Git workflow standards, commit conventions, and automation practices.

Overview

Our Git standards ensure:

  • Consistent commit history
  • Automated quality checks
  • Clean development workflow
  • Standardized PR process

Commit Message Standards

We use Conventional Commits specification with the following types:

Text Only
1
2
3
4
5
<type>[optional scope]: <description>

[optional body]

[optional footer(s)]

Commit Types

  • feat: New feature
  • fix: Bug fix
  • docs: Documentation changes
  • style: Code style changes (formatting, etc.)
  • refactor: Code changes that neither fix bugs nor add features
  • perf: Performance improvements
  • test: Adding or updating tests
  • build: Build system or dependency changes
  • ci: CI configuration changes
  • chore: Other changes that don't modify src or test files
  • revert: Reverting previous changes
  • security: Security-related changes

Examples

Bash
1
2
3
feat(auth): add OAuth2 authentication
fix(api): handle null response from user service
docs(readme): update deployment instructions

Branch Naming Convention

Format: <type>/<description>

Types

  • feature: New functionality
  • bugfix: Bug fixes
  • hotfix: Urgent fixes for production
  • release: Release preparation
  • chore: Maintenance tasks
  • docs: Documentation updates
  • test: Test-related changes
  • ci: CI/CD updates
  • security: Security-related changes

Examples

Bash
1
2
3
feature/user-authentication
bugfix/login-validation
hotfix/security-patch

Git Hooks

We use Husky to manage Git hooks for automated checks.

Pre-commit Hook

Runs before each commit:

  • Lint staged files
  • Run tests
  • Build verification
JavaScript
1
2
3
4
5
6
// .huskyrc.js
"pre-commit": [
  "lint-staged",
  "npm test",
  "npm run build"
]

Commit-msg Hook

Validates commit messages:

  • Conventional Commits format
  • Type validation
  • Description requirements

Pre-push Hook

Verifies before pushing:

  • Branch naming
  • Code quality checks
  • Test coverage

Post-merge Hook

Runs after merging:

  • Package updates check
  • Dependency installation
  • Clean-up tasks

Pull Request Process

  1. Create PR using template
  2. Fill required sections:
  3. Description
  4. Type of change
  5. Related issues
  6. Testing performed
  7. Checklist completion

PR Template Sections

Markdown
 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# Description
What changes does this PR introduce?

# Type of Change
- [ ] feat: New feature
- [ ] fix: Bug fix
...

# Testing
- [ ] Unit tests
- [ ] Integration tests
- [ ] Manual testing

Automation Scripts

Branch Name Verification

JavaScript
1
2
3
4
// verify-branch-name.js
- Validates against naming convention
- Checks for protected branches
- Ensures proper formatting

Package Updates Check

JavaScript
1
2
3
4
// check-package-updates.js
- Detects package.json changes
- Updates dependencies
- Runs installation

Post-checkout Cleanup

JavaScript
1
2
3
4
// post-checkout-cleanup.js
- Cleans build artifacts
- Updates dependencies
- Removes temporary files

Best Practices

  1. Commit Guidelines
  2. Write clear, concise messages
  3. Reference issues when applicable

  4. Keep commits focused and atomic

  5. Branch Management

  6. Regular rebasing with main
  7. Clean up merged branches

  8. Protect main/master branch

  9. Code Review

  10. Use PR templates
  11. Follow review checklist
  12. Provide constructive feedback

Tools and Configuration

  1. Commitlint
  2. Enforces commit message format
  3. Configurable rules

  4. Integration with CI/CD

  5. Husky

  6. Manages Git hooks
  7. Automated checks

  8. Custom scripts

  9. PR Templates

  10. Standardized format
  11. Required sections
  12. Checklist items