What is the expected commit message format?

Use Conventional Commits: ( ): with atomic commits and imperative mood.

How should branches be named and merged?

Prefix branches by task type (feat/, fix/, hotfix/, refactor/), create one branch per task, never push to main/develop directly, and prefer rebasing with PRs.

How are security and metadata handled?

Do not commit secrets; use .gitignore and git hooks (e.g., Husky) to enforce standards; tag releases with SemVer and update CHANGELOG.

Git & Collaboration Standards

Scanned

npx machina-cli add skill hoangnguyen0403/agent-skills-standard/git-collaboration --openclaw

Files (1)

SKILL.md

2.5 KB

Git & Collaboration - High-Density Standards

Universal standards for version control, branching, and team collaboration.

Priority: P0 (OPERATIONAL)

Universal standards for effective version control, branching strategies, and team collaboration.

📝 Commit Messages (Conventional Commits)

Format: <type>(<scope>): <description> (e.g., feat(auth): add login validation).
Types: feat (new feature), fix (bug fix), docs, style, refactor, perf, test, chore.
Atomic Commits: One commit = One logical change. Avoid "mega-commits".
Imperative Mood: Use "add feature" instead of "added feature" or "adds feature".

🌿 Branching & History Management

Naming: Use prefixes: feat/, fix/, hotfix/, refactor/, docs/.
Branch for Everything: Create a new branch for every task to keep the main branch stable and deployable.
Main Branch Protection: Never push directly to main or develop. Use Pull Requests.
Sync Early: "Pull Before You Push" to identify and resolve merge conflicts locally.
Prefer Rebase: Use git rebase (instead of merge) to keep a linear history when updating local branches from develop or main.
Interactive Rebase: Use git rebase -i to squash or fixup small, messy commits before pushing to a shared branch.
No Merge Commits: Avoid "Merge branch 'main' into..." commits in feature branches. Always rebase onto the latest upstream.

🤝 Pull Request (PR) Standards

Small PRs: Limit to < 300 lines of code for effective review.
Commit Atomicness: Each commit should represent a single, complete logical change.
Description: State what changed, why, and how to test. Link issues (Closes #123).
Self-Review: Review your own code for obvious errors/formatting before requesting peers.
CI/CD: PRs must pass all automated checks (lint, test, build) before merging.

🛡 Security & Metadata

No Secrets: Never commit .env, keys, or certificates. Use .gitignore strictly.
Git Hooks: Use tools like husky or lefthook to enforce standards locally.
Tags: Use SemVer (vX.Y.Z) for releases. Update CHANGELOG.md accordingly.

📚 References

Clean Linear History & Rebase Examples

Source

git clone https://github.com/hoangnguyen0403/agent-skills-standard/blob/develop/.github/skills/common/git-collaboration/SKILL.md

View on GitHub

Overview

Defines universal standards for version control, branching strategies, and team collaboration. It covers commit message conventions, branch naming, PR practices, and security hygiene to keep repos clean, auditable, and scalable.

How This Skill Works

Teams follow Conventional Commits for messages, atomic commits, and imperative mood. Branches use prefixes and task-per-branch discipline; main and develop are protected and rebasing is preferred to maintain a linear history. PRs trigger CI checks and require reviews before merging.

When to Use It

Starting a new project or onboarding a team to a shared workflow
Developing features collaboratively across multiple contributors
Preparing a release with a clean, linear history
Code review sessions and pull request-driven integrations
Enforcing security, hygiene, and metadata practices in a repo

Quick Start

Step 1: Start a task with a prefixed branch (e.g., feat/auth) and pull the latest main
Step 2: Commit changes using Conventional Commits (e.g., feat(auth): add login validation) and ensure atomicity
Step 3: Open a PR, ensure CI checks pass, then rebase if needed before merging

Best Practices

Write commits that are atomic and describe a single logical change using Conventional Commits
Use descriptive branch prefixes (feat/, fix/, hotfix/, refactor/, docs/), and create a branch per task
Never push directly to main or develop; use pull requests and rebase to integrate changes
Keep PRs small (<300 lines) with clear descriptions, tests, and rationale
Avoid committing secrets, use .gitignore, and apply pre-commit hooks (e.g., Husky) and SemVer tagging

Example Use Cases

feat(auth): add login validation
fix(payment): resolve flaky gateway timeout
docs(readme): update setup instructions
refactor(ui): simplify modal lifecycle
release: v1.2.0 — update CHANGELOG and tag

Frequently Asked Questions

Add this skill to your agents