Git Workflow

作者 mindrally97184105b5da無授權條款269 個星標收錄於 2026年10月8日更新於 2026年10月8日儲存庫5 週前更新

Git conventions and workflow guidelines using Conventional Commits, branching strategies, and best practices for version control

AI 產生的概覽

Git 規範與工作流程指南,涵蓋約定式提交、分支策略與版本控制最佳實務。

功能
此技能提供有紀律地使用 Git 的參考指引。它定義了約定式提交的訊息格式、提交類型與範例,分支命名前綴與逐步分支工作流程,建議的 Git 設定與別名,程式碼審查與合併策略,衝突解決步驟,安全實務,以及提交類型與語意化版本的對應關係。它產出的是書面規範與範例,而非指令碼或檔案。
適用情境
適用於撰寫提交訊息、命名或管理分支、設定 Git、選擇合併策略或解決衝突時。也適合希望統一版本控制規範,並將其與語意化版本及變更日誌產生結合的團隊。
執行需求
除代理程式外無需任何工具、套件或憑證;僅為指示性內容,不附帶指令碼。其範例指令假定使用者已安裝 Git。

Git Workflow Best Practices

You are an expert in Git version control, following industry best practices for commits, branching, and collaboration workflows.

Core Principles

  • Write clear, atomic commits that address single logical changes
  • Follow Conventional Commits specification for all commit messages
  • Use feature branches to isolate changes and enable easier code review
  • Keep branches short-lived and regularly sync with main branch
  • Never commit directly to main/master branch

Conventional Commits Format

Use the following format for all commit messages:

<type>[optional scope]: <description>
[optional body]
[optional footer(s)]

Commit Types

  • feat: A new feature (correlates with MINOR in SemVer)
  • fix: A bug fix (correlates with PATCH in SemVer)
  • docs: Documentation only changes
  • style: Changes that do not affect the meaning of the code (white-space, formatting)
  • refactor: A code change that neither fixes a bug nor adds a feature
  • perf: A code change that improves performance
  • test: Adding missing tests or correcting existing tests
  • build: Changes that affect the build system or external dependencies
  • ci: Changes to CI configuration files and scripts
  • chore: Other changes that don't modify src or test files
  • revert: Reverts a previous commit

Commit Message Guidelines

  • Use lowercase letters in the entire body of the commit message
  • Keep the commit message title under 60 characters
  • Use imperative mood: "Add feature" not "Added feature"
  • Explain the why behind the change, not just what was changed
  • Reference related issues or tickets in the footer

Examples

feat(auth): add OAuth2 authentication support
Implement OAuth2 flow for Google and GitHub providers.This allows users to sign in with their existing accounts.
Closes #123
fix(api): handle null response from external service
The external API sometimes returns null instead of an empty array.Added null check to prevent TypeError in downstream processing.
Fixes #456

Branching Strategy

Branch Naming Conventions

Use descriptive, kebab-case branch names with prefixes:

  • feature/ - New features (e.g., feature/user-authentication)
  • bugfix/ - Bug fixes (e.g., bugfix/login-redirect-loop)
  • hotfix/ - Urgent production fixes (e.g., hotfix/security-patch)
  • release/ - Release preparation (e.g., release/v2.1.0)
  • docs/ - Documentation updates (e.g., docs/api-reference)
  • refactor/ - Code refactoring (e.g., refactor/database-layer)

Workflow Guidelines

  1. Create feature branches from main/develop

    bash
    git checkout maingit pull origin maingit checkout -b feature/new-feature
  2. Keep branches up-to-date

    bash
    git fetch origingit rebase origin/main
  3. Make atomic commits

    • Each commit should be a single, logical change
    • Commit early and often when code is in a stable state
    • Avoid mixing unrelated changes in a single commit
  4. Before merging

    • Ensure all tests pass
    • Squash fixup commits if needed
    • Rebase onto latest main to resolve conflicts
  5. Clean up after merge

    bash
    git branch -d feature/new-featuregit push origin --delete feature/new-feature

Git Configuration Best Practices

Useful Aliases

bash
git config --global alias.co checkoutgit config --global alias.br branchgit config --global alias.ci commitgit config --global alias.st statusgit config --global alias.lg "log --oneline --graph --decorate"

Recommended Settings

bash
git config --global pull.rebase truegit config --global fetch.prune truegit config --global diff.colorMoved zebra

Collaboration Guidelines

Code Review Process

  1. Create small, focused pull requests
  2. Write clear PR descriptions explaining the changes
  3. Link related issues and documentation
  4. Request reviews from appropriate team members
  5. Address feedback promptly and professionally
  6. Squash commits when merging if history is messy

Merge Strategies

  • Merge commit: Preserves full history, good for feature branches
  • Squash and merge: Combines all commits into one, cleaner main history
  • Rebase and merge: Linear history, requires clean commit history

Conflict Resolution

  1. Pull latest changes from target branch
  2. Resolve conflicts locally
  3. Test thoroughly after resolution
  4. Commit with clear message explaining resolution

Security Best Practices

  • Never commit sensitive data (passwords, API keys, tokens)
  • Use .gitignore to exclude sensitive files
  • Review diffs before committing
  • Use signed commits for verified authorship
  • Rotate any accidentally committed secrets immediately

Integration with Semantic Versioning

Conventional Commits integrate well with semantic versioning:

  • feat: triggers a MINOR version bump
  • fix: triggers a PATCH version bump
  • BREAKING CHANGE: triggers a MAJOR version bump

This enables automated version determination and changelog generation.

來源與署名

來源:mindrally/skills位於git-workflow提交9718410

授權條款: 無授權條款

內容歸原作者所有。SourceWeft 從公開儲存庫中收錄這些內容。

檢舉或申請下架