Git workflows

We try to keep a simple, light-weight workflow across Git repositories. Here are some guidelines:

  • Always use your anonymized Dragon GitHub accounts for Levana-related commits. This includes both private Levana repositories, public Levana repositories, and interactions with other projects.
  • Similarly, when referring to team members, use their anonymized GitHub usernames, not their real names (even just first names).
  • Every project has a default branch which should be the target of pull requests, unless you have a reason to do something else. We're slightly inconsistent across repos on this, sometimes using any of develop, main, and master.
  • Feature branches should almost always be opened in response to a specific JIRA issue, and the branch name should be based on the JIRA issue number. For example, if you're working on JIRA issue PERP-1234 which implements support for Frobnication, a good branch name would be perp-1234/add-frobnication.
  • There are no specific rules on the project regarding clean/linear history. You're allowed to merge, squash commits, or rebase as desired.
  • Avoid changing unrelated files in a PR. As a common example, if you wanted to reformat the entire codebase, that should be its own dedicated PR that only performs the reformating, not including other semantic changes.
  • Once PR review has started, do not rebase the branch until the PR review has finished. Reason: rebasing during a review breaks the ability to see changes since the last review.
    • Again, clean history is not required on these projects. However, if you want to clean up a complex PR's history, do so after the pull request has been approved but before merging. Or, if appropriate, you could use GitHub's squash feature.