Skip to main content

Git Conventions

How we name branches, write commits, and run pull requests at GoodFit.

Branches​

  • Default branch: main. Feature branches are QAed on dev first, then merged into main via PR, which auto-deploys to stag for release QA. Production is then released by opening a main → prod PR once that QA passes. See Development Lifecycle for the full picture.
  • Naming: <ticket>/<short-description> — e.g. GFENG-123/new-column-migration.

For longer-lived work split across multiple PRs, see the Feature & Sub-branches guide.

Commit messages​

Prefix each commit with the ticket number:

GFENG-1234: Add migration for new column

Keep the subject short; add detail in the body if the change isn't self-evident from the diff.

Pull requests​

Opening a PR​

  1. Open the PR on GitHub.

  2. Add a summary describing what changed and why.

    • Summary
      • What changed and why. Link to ticket: GFENG-123.
    • Changes
      • [Bullet list of user-visible or system-visible changes]
    • (optional) test notes — e.g. a SQL snippet so reviewers can re-run your verification.

    Attaching a test snippet to a PR

  3. Post in #eng-prs with the PR link and the name shown in "Changed files".

    Sharing a PR in Slack

Handling review comments​

When a conversation is opened on your PR:

  • Reactions are fine when you just agree with a change — no need to reply.
  • Comments belong on anything unclear or anything you disagree with.
  • Maintainers should make it explicit whether a comment is blocking or just a suggestion/question.
  • Reviewers resolve their own threads. Authors leave threads open and reply with a quick note (e.g. "Updated here: 2dea449") so the reviewer can verify and close.
  • We favour velocity over process for process' sake.

(optional) After pushing follow-up commits, paste the commit hash as a thread reply. Expect a reaction (💚 💛 👀) when it's been seen.

Posting follow-up commits in the thread

Merging​

Once approved, choose Squash and merge or Merge commit at your discretion — pick whichever produces the more useful history for the change.

Choosing a merge strategy

Why we work this way​

A small amount of structure keeps the review loop tight:

  • Reviewers get a clean signal when updates are ready for another look.
  • Authors don't have to guess whether something is "done" or still under discussion.
  • Maintainers can verify follow-up changes without re-reading the entire diff.
  • Feedback stays fast, especially with multiple reviewers.

Tiny bit of structure → smoother reviews → fewer "wait, was this addressed?" moments.