>_SkillsHub▋

> common-git-collaboration

Universal standards for version control, branching, and team collaboration. Use when writing commits, creating branches, merging, or opening pull requests. (triggers: commit, branch, merge, pull-request, git)

fetch
$curl "https://skillshub.wtf/HoangNguyen0403/agent-skills-standard/common-git-collaboration?format=md"
SKILL.md•common-git-collaboration

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

🚫 Anti-Patterns

  • Do NOT use standard patterns if specific project rules exist.
  • Do NOT ignore error handling or edge cases.

> related_skills --same-repo

> typescript-tooling

Development tools, linting, and build config for TypeScript. Use when configuring ESLint, Prettier, Jest, Vitest, tsconfig, or any TS build tooling. (triggers: tsconfig.json, .eslintrc.*, jest.config.*, package.json, eslint, prettier, jest, vitest, build, compile, lint)

> typescript-security

Secure coding practices for TypeScript. Use when validating input, handling auth tokens, sanitizing data, or managing secrets and sensitive configuration. (triggers: **/*.ts, **/*.tsx, validate, sanitize, xss, injection, auth, password, secret, token)

> typescript-language

Modern TypeScript standards for type safety and maintainability. Use when working with types, interfaces, generics, enums, unions, or tsconfig settings. (triggers: **/*.ts, **/*.tsx, tsconfig.json, type, interface, generic, enum, union, intersection, readonly, const, namespace)

> typescript-best-practices

Idiomatic TypeScript patterns for clean, maintainable code. Use when writing or refactoring TypeScript classes, functions, modules, or async logic. (triggers: **/*.ts, **/*.tsx, class, function, module, import, export, async, promise)

┌ stats

installs/wk0
░░░░░░░░░░
github stars341
██████████
first seenMar 17, 2026
└────────────

┌ repo

HoangNguyen0403/agent-skills-standard
by HoangNguyen0403
└────────────

┌ tags

#git#writing
└────────────