Instruction file imported from vkanta/copilot (.github/instructions/gitgerrit.instructions.md). Copyright stays with the author.

Commit Message Standards (Conventional Commits)

• Use the Conventional Commits specification for all commit messages.
• Structure each commit message as: <type>[optional scope]: <description> (blank line) [optional body] (blank line) [optional footer(s)]
• Common types: feat, fix, docs, style, refactor, test, chore, build, ci.
• Keep the subject line under 50 characters.
• Use the imperative mood in the subject line (e.g., "fix bug" not "fixed bug").
• Capitalize only the first word of the subject line.
• Leave a blank line between the subject and body.
• Use the body to explain what and why vs. how.
• Reference issues and PRs in the footer (e.g., Refs: #123).
• Indicate breaking changes with ! after type/scope or a BREAKING CHANGE: footer.
• Example:

  feat(parser): add ability to parse arrays
  
  This adds a new parseArray method to the parser module.
  
  BREAKING CHANGE: parseArray replaces parseList.
  Refs: #456
  

.gitignore Guidelines

• Always include a .gitignore file at the root of your project.
• For Node.js and webpack projects, use the official Node.gitignore template as a base.
• Always ignore:
  • node_modules/
  • dist/, build/, and other build output folders
  • .env, .env.*, except for .env.example
  • *.log, npm-debug.log*, yarn-debug.log*, yarn-error.log*
  • .DS_Store, *.swp, *~, and editor/OS temp files
  • Coverage and cache folders: coverage/, .nyc_output/, .cache/, .eslintcache, .stylelintcache
• Never commit dependencies or build outputs to version control.
• For custom rules, add comments to explain why a pattern is ignored.
• Example .gitignore:

  # Node modules
  node_modules/
  
  # Build output
  dist/
  build/
  
  # Environment files
  .env
  .env.*
  !.env.example
  
  # Logs
  *.log
  npm-debug.log*
  yarn-debug.log*
  yarn-error.log*
  
  # OS and editor files
  .DS_Store
  *.swp
  *~
  
  # Coverage and cache
  coverage/
  .nyc_output/
  .cache/
  .eslintcache
  .stylelintcache

name: Git Gerrit Workflow Guidelines applyTo: "**" description: Best practices for using Git with Gerrit code review

Git + Gerrit Workflow Standards

• Always squash your commits into a single, meaningful commit before submitting for review.
• Use interactive rebase (git rebase -i) to clean up your commit history.
• Write clear, descriptive commit messages that follow project and Conventional Commits guidelines.
• Reference relevant issues, tickets, or Change-Id in the commit footer.
• Rebase your branch onto the latest master/main before pushing for review.
• Push changes to Gerrit using the refs/for/master (or appropriate target branch):

  git push origin HEAD:refs/for/master

• Address all reviewer comments and update your change by amending the commit and pushing again (do not create new commits for the same review).
• Use git commit --amend to update your change and preserve a single commit per review.
• Ensure all tests and checks pass before submitting for review.
• Do not force-push to shared branches; use review refs only.
• Use Gerrit’s web UI to review, comment, and approve changes.
• Only submit changes after all required approvals are received.