Summary This source did not publish a separate summary. Review SKILL.md before using the skill.
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 featNew feature feat(user): add user export functionalityfixBug fix fix(login): fix captcha not refreshingdocsDocumentation update docs(api): update API documentationrefactorRefactoring refactor(utils): refactor utility functionsperfPerformance improvement perf(list): optimize list performancetestTest related test(user): add unit testschoreOther 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.
Branch Management Strategy
Branch Types Branch Type Naming Convention Description Lifecycle master masterMain branch, releasable state Permanent develop developDevelopment branch, latest integrated code Permanent feature feature/feature-nameFeature branch Delete after completion bugfix bugfix/issue-descriptionBug fix branch Delete after fix hotfix hotfix/issue-descriptionEmergency fix branch Delete after fix release release/version-numberRelease branch Delete after release
Branch Naming Examples feature/user-management # User management feature
feature/123-add-export # Issue-linked feature
bugfix/login-error # Login error fix
hotfix/security-vulnerability # Security vulnerability fix
release/v1.0.0 # Version release
Branch Protection Rules
No direct pushes allowed
Must merge via Pull Request
Must pass CI checks
Requires at least one Code Review approval
Direct pushes restricted
Pull Request merges recommended
Must pass CI checks
For detailed branch strategies and workflows, see references/branching-strategies.md.
Workflows
Daily Development Workflow # 1. Sync latest code
git checkout develop
git pull origin develop
# 2. Create feature branch
git checkout -b feature/user-management
# 3. Develop and commit
git add .
git commit -m "feat(user): add user list page"
# 4. Push to remote
git push -u origin feature/user-management
# 5. Create Pull Request and request Code Review
# 6. Merge to develop (via PR)
# 7. Delete feature branch
git branch -d feature/user-management
git push origin -d feature/user-management
Hotfix Workflow # 1. Create fix branch from master
git checkout master
git pull origin master
git checkout -b hotfix/critical-bug
# 2. Fix and commit
git add .
git commit -m "fix(auth): fix authentication bypass vulnerability"
# 3. Merge to master
git checkout master
git merge --no-ff hotfix/critical-bug
git tag -a v1.0.1 -m "hotfix: fix authentication bypass vulnerability"
git push origin master --tags
# 4. Sync to develop
git checkout develop
git merge --no-ff hotfix/critical-bug
git push origin develop
Release Workflow # 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 rebaseFeature branch merging to develop : Use merge --no-ffdevelop 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 daySmall commits - Commit small changes frequentlyModular features - Implement different features in different filesCommunication - 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
Common .gitignore node_modules/
dist/
build/
.idea/
.vscode/
.env
.env.local
logs/
*.log
.DS_Store
Thumbs.db
For detailed .gitignore patterns and project-specific configurations, see references/gitignore-guide.md.
Tag Management Uses Semantic Versioning :
MAJOR.MINOR.PATCH[-PRERELEASE]
Version Change Rules
MAJOR : Incompatible API changes (v1.0.0 → v2.0.0)MINOR : Backward-compatible new features (v1.0.0 → v1.1.0)PATCH : Backward-compatible bug fixes (v1.0.0 → v1.0.1)
Tag Operations # 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 ## 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
Code quality : Clear and readable, proper naming, no duplicate codeLogic correctness : Business logic correct, edge cases handledSecurity : No security vulnerabilities, sensitive information protectedPerformance : No obvious performance issues, resources properly released For detailed collaboration standards and best practices, see references/collaboration.md.
Common Issues
Amending the Last Commit # Amend commit content (not yet pushed)
git add forgotten-file.ts
git commit --amend --no-edit
# Amend commit message
git commit --amend -m "new commit message"
Push Rejected # Pull then push
git pull origin master
git push origin master
# Use rebase for cleaner history
git pull --rebase origin master
git push origin master
Rollback to Previous Version # Reset to specific commit (discards subsequent commits)
git reset --hard abc123
# Create reverse commit (recommended, preserves history)
git revert abc123
Stash Current Work git stash save "work in progress"
git stash list
git stash pop
View File Modification History git log -- <file> # Commit history
git log -p -- <file> # Detailed content
git blame <file> # Per-line author
Best Practices Summary
Commit Standards
Follow Conventional Commits specification
Write clear commit messages describing changes
One commit for one logical change
Run code checks before committing
Vague commit messages
Multiple unrelated changes in one commit
Committing sensitive information (passwords, keys)
Developing directly on main branch
Branch Management
Use feature branches for development
Regularly sync main branch code
Delete branches promptly after feature completion
Use --no-ff merge to preserve history
Developing directly on main branch
Long-lived unmerged feature branches
Non-standard branch naming
Rebasing on public branches
Code Review
All code goes through Pull Requests
At least one reviewer approval before merging
Provide constructive feedback
Merging without review
Reviewing your own code
Additional Resources
Reference Files For detailed guidance on specific topics:
references/commit-conventions.mdreferences/branching-strategies.mdreferences/merge-strategies.mdreferences/conflict-resolution.mdreferences/advanced-usage.mdreferences/collaboration.mdreferences/gitignore-guide.md
Example Files Working examples in examples/:
examples/commit-messages.txtexamples/workflow-commands.sh
Summary This document defines the project's Git standards:
Commit Messages - Follow Conventional Commits specificationBranch Management - master/develop/feature/bugfix/hotfix/release branch strategyWorkflows - Standard processes for daily development, hotfixes, and releasesMerge Strategy - Use rebase to sync feature branches, merge --no-ff to mergeTag Management - Semantic versioning, annotated tagsConflict Resolution - Regular syncing, small commits, team communication Following these standards improves collaboration efficiency, ensures code quality, and simplifies version management.
