Skip to main content

Git Conventions

Commit Messages​

Each commit should have a task number prefix.

  • e.g. "GFENG-1234: Commit message"

It's also a good practice to use branch naming like "<Ticket number>/<a-description-about-the-code-changes>".

  • e.g. "GFENG-123/new-column-migration"

Branch​

We use main branch as default, and code is committed to prod from this branch only, after successful verification has taken place.

PRs​

When ready with the code changes:

  1. Create a new pr in https://github.com/GoodFit-io/
  2. (opt) Attach a note/sql snippet how you tested so it can be re-run by the reviewer

  1. (opt) Add summary note to prs
  2. Create a new msg in #eng-prs slack with pr link name you see in changed file

  1. When a conversation is opened, review them:

    • Use reaction where you just agree with the change
    • Add a comment if needed or not clear or don't agree
    • Maintainers should indicate whether a comment is blocking or a suggestion/question
    • Reviewers are responsible for resolving their own comment threads
      • Authors should leave threads open and add a brief note (e.g. "Updated here: 2dea449)") so reviewers can verify and close them.
    • We favour velocity over "process for process sake"

  2. (opt) After code changes are committed to the remote, paste the commit as comment to the message thread

    • Expect a reaction to it 💚 💛 👀

  1. When pr is approved check which one makes more sense to choose

Use squash or merge at your discretion

🧐 Why we follow this approach​

Clear, consistent handling of PR comments helps everyone move faster:

  • Reviewers get a clean signal when updates are ready for a second look
  • Authors avoid guessing whether something is "done" or still under discussion
  • Maintainers can more easily verify changes without re-reading the whole diff
  • The feedback loop stays tight, especially when multiple people are reviewing

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