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 从公开仓库中收录这些内容。

举报或申请下架