Skip to content

🚀 Git Best Practices

This document outlines industry-standard best practices for using Git, a distributed version control system widely used for software development. Following these guidelines will help ensure your codebase remains clean, maintainable, and collaborative.

Table of Contents

  1. Branching Strategy
  2. Commit Messages
  3. Pull Requests
  4. Code Quality
  5. Documentation
  6. Automation

Branching Strategy

Main Branch

  • The main (or master) branch should always be in a deployable state.
  • Direct commits to main should be avoided; all changes should come through pull requests.
  • Use branch protection rules to enforce this policy.

Feature Branches

  • Create a new branch for each feature or bugfix.
  • Use descriptive names for feature branches (e.g., feature/add-login, bugfix/fix-authentication).
  • Regularly rebase feature branches against main to keep them up-to-date.

Release Branches

  • Use release branches to prepare for a new production release.
  • Name release branches using the release version (e.g., release/1.0.0).
  • Perform final testing on the release branch before merging into main.

Hotfix Branches

  • Hotfix branches are used to quickly patch production issues.
  • Name hotfix branches with the issue or bug number (e.g., hotfix/issue-123).
  • After the hotfix is applied, merge the branch into both main and the current release branch.

Commit Messages

Commit Message Format

  • Use a standard format for commit messages: 
    <type>(<scope>): <subject>

<body>

<footer>
  • The <type> can be feat, fix, docs, style, refactor, test, or chore. Example: 
    feat(auth): add login functionality

- Added login form
- Implemented authentication logic

Closes #123

Imperative Mood

  • Write commit messages in the imperative mood (e.g., "Add feature" not "Added feature").
  • This style aligns with automated tools that use commit messages to generate changelogs.
  • Footer reference issues or pull request if any, example natindonesia/repo/issues/38 the footer should be Closes #38

Atomic Commits

  • Make each commit a logical unit of work.
  • Avoid committing unrelated changes in a single commit.

Pull Requests

Small and Focused

  • Keep pull requests small and focused on a single change or feature.
  • This makes them easier to review and understand.

Description and Context

  • Provide a clear description and context for the changes in the pull request.
  • Include screenshots, if applicable, to demonstrate UI changes.

Code Reviews

  • Ensure all pull requests undergo code review before merging.
  • Use the review process to maintain code quality and share knowledge within the team.

Code Quality

Linting and Formatting

  • Use linting tools to enforce coding standards and catch potential issues.
  • Format code consistently using tools like Prettier or Black.

Testing

  • Write tests for all new features and bug fixes.
  • Ensure the test suite passes before merging changes into main.

Documentation

README.md

  • Maintain an up-to-date README.md file at the root of the repository.
  • Include setup instructions, usage examples, and contribution guidelines.

Code Comments

  • Use comments to explain complex or non-obvious code.
  • Avoid redundant comments that state the obvious.

Automation

Continuous Integration

  • Set up a Continuous Integration (CI) system to automatically run tests and checks on each pull request.
  • Common CI tools include GitHub Actions, CircleCI, and Travis CI.

Continuous Deployment

  • Implement Continuous Deployment (CD) to automatically deploy changes to production.
  • Ensure deployments are tested and reliable before enabling automatic deployments.

Following these best practices will help maintain a high standard of code quality and collaboration within your team.