This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides comprehensive Git workflow guidance for team collaboration.
This skill should be used when the user asks to "create git commit", "manage branches", "follow git workflow", "use Conventional Commits", "handle merge conflicts", or asks about git branching strategies, version control best practices, pull request workflows. Provides comprehensive Git workflow guidance for team collaboration.
version
1.2.0
Git Workflow Standards
This document defines the project's Git usage standards, including commit message format, branch management strategy, workflows, merge strategies, and more. Following these standards improves collaboration efficiency, enables traceability, supports automation, and reduces conflicts.
Commit Message Standards
The project follows the Conventional Commits specification:
<type>(<scope>): <subject>
<body>
<footer>
Type Reference
Type
Description
Example
feat
New feature
feat(user): add user export functionality
fix
Bug fix
fix(login): fix captcha not refreshing
docs
Documentation update
docs(api): update API documentation
refactor
Refactoring
refactor(utils): refactor utility functions
perf
Performance improvement
perf(list): optimize list performance
test
Test related
test(user): add unit tests
chore
Other changes
chore: update dependency versions
Subject Rules
Start with a verb: add, fix, update, remove, optimize
No more than 50 characters
No period at the end
For more detailed conventions and examples, see references/commit-conventions.md.
# 1. Create release branch
git checkout develop
git checkout -b release/v1.0.0
# 2. Update version numbers and documentation# 3. Commit version update
git add .
git commit -m "chore(release): prepare release v1.0.0"# 4. Merge to master
git checkout master
git merge --no-ff release/v1.0.0
git tag -a v1.0.0 -m "release: v1.0.0 official release"
git push origin master --tags
# 5. Sync to develop
git checkout develop
git merge --no-ff release/v1.0.0
git push origin develop
Merge Strategy
Merge vs Rebase
Feature
Merge
Rebase
History
Preserves complete history
Linear history
Use case
Public branches
Private branches
Recommended for
Merging to main branch
Syncing upstream code
Recommendations
Feature branch syncing develop: Use rebase
Feature branch merging to develop: Use merge --no-ff
develop merging to master: Use merge --no-ff
# ✅ Recommended: Feature branch syncing develop
git checkout feature/user-management
git rebase develop
# ✅ Recommended: Merge feature branch to develop
git checkout develop
git merge --no-ff feature/user-management
# ❌ Not recommended: Rebase on public branch
git checkout develop
git rebase feature/xxx # Dangerous operation
Project convention: Use --no-ff when merging feature branches to preserve branch history.
For detailed merge strategies and techniques, see references/merge-strategies.md.
Conflict Resolution
Identifying Conflicts
<<<<<<< HEAD
// Current branch code
const name = 'Alice'
=======
// Branch being merged
const name = 'Bob'
>>>>>>> feature/user-management
Resolving Conflicts
# 1. View conflicting files
git status
# 2. Manually edit files to resolve conflicts# 3. Mark as resolved
git add <file>
# 4. Complete the merge
git commit # merge conflict# or
git rebase --continue# rebase conflict
Conflict Resolution Strategies
# Keep current branch version
git checkout --ours <file>
# Keep incoming branch version
git checkout --theirs <file>
# Abort merge
git merge --abort
git rebase --abort
Preventing Conflicts
Sync code regularly - Pull latest code before starting work each day
Small commits - Commit small changes frequently
Modular features - Implement different features in different files
Communication - Avoid modifying the same file simultaneously
For detailed conflict handling and advanced techniques, see references/conflict-resolution.md.
.gitignore Standards
Basic Rules
# Ignore all .log files
*.log
# Ignore directories
node_modules/
# Ignore directory at root
/temp/
# Ignore files in all directories
**/.env
# Don't ignore specific files
!.gitkeep
# Create annotated tag (recommended)
git tag -a v1.0.0 -m "release: v1.0.0 official release"# Push tags
git push origin v1.0.0
git push origin --tags
# View tags
git tag
git show v1.0.0
# Delete tag
git tag -d v1.0.0
git push origin :refs/tags/v1.0.0
Team Collaboration Standards
Pull Request Standards
PRs should include:
## Change Description
<!-- Describe the content and purpose of this change -->
## Change Type- [ ] New feature (feat)
- [ ] Bug fix (fix)
- [ ] Code refactoring (refactor)
## Testing Method
<!-- Describe how to test -->
## Related Issue
Closes #xxx
## Checklist- [ ] Code has been self-tested
- [ ] Documentation has been updated
Code Review Standards
Review focus areas:
Code quality: Clear and readable, proper naming, no duplicate code
Logic correctness: Business logic correct, edge cases handled
Security: No security vulnerabilities, sensitive information protected
Performance: No obvious performance issues, resources properly released
For detailed collaboration standards and best practices, see references/collaboration.md.
