Skip to content

Latest commit

 

History

History
44 lines (32 loc) · 2.82 KB

git_flow.md

File metadata and controls

44 lines (32 loc) · 2.82 KB

Developing Features / Committing Work

Goals

These processes should make it as easy as possible:

  1. for multiple developers to collaborate on a project
  2. to deploy reliably and frequently
  3. to review each other's code
  4. to document our intention with commit messages

Tools Used

  • Git or (optionally) jj
  • GitHub
  • ep pair (ep unpair, ep who)

Procedures

  • We work on topic branches so that we may create pull requests for every change.
    • Never commit directly to main*
    • Pull main* before creating a branch
    • Rebase topic branches off of main* when main* changes


    * Newer projects default to using main as the default branch to match updated tooling. When a project has a beta environment, we've also had a branch off of main named beta. In this case, hotfixes are always based off main and new features are based off of beta.

  • We make our commits discrete, atomic, and succinct in order to better communicate their intention.
    • Break separate logical changes into separate commits
    • Don't commit partial work; no commit should knowingly leave the project in a broken state
    • Minimize commit noise (changes that aren't relevant to the commit)


    Rewriting Commits
    For a variety of reasons, we may not make discrete, atomic, and succinct commits while working on a branch — we may commit partial work, have a false start, or notice an oversight in a previous commit. We may then use tools like git commit --amend, git rebase and git cherry-pick to rewrite our branch's commits before requesting a review. Our goal is to make code review easier and git history more useful.

  • When pairing, we make commits jointly using ep pair
  • We label commits to help Houston create release notes and resolve alerts automatically.
    • Use [feature], [improvement] and [fix] on changes that should be mentioned in release notes
    • Use [skip] or [refactor] on changes that should not be mentioned in release notes
    • Other labels like [squash] and [wip] may be useful for work-in-progress but should never be merged to main. (see Rewriting Commits above)
  • We create a Pull Request as soon as we are ready to deploy our work to Staging for Testing, to request a review, or to share our work-in-progress with other developers.

Related Topics