Git Workflow - HausDAO/daohaus-monorepo-deprecated GitHub Wiki

Purpose: Outline the current iteration of our git workflow.

Our git workflow is evolving as our team and processes change, so this will always be a living document. This captures the current workflow as of May 2022.

Before starting make sure that you have the most recent codebase running locally! Our default branch is develop regardless of which package you're working on in the monorepo!

• Create feature branches from develop -- this is our default branch in both the Sage and Rage monorepos
• Prefix feature branches such as feature/{name} where {name} is what you're working on:
  • Example: feature/haus-price-component
  • Try to scope feature branches to a single issue/feature as much as possible
• Prefix fix branches with fix/{name} where {name} is what is being fixed
• When working, try to keep your branch as up to date as possible by either:
  • Pull down develop when there are changes and rebase into your branch, fixing merges as they come up
  • Merge develop into your branch to keep it up to date
  • Check out this explanation for the difference: Atlassian Git tutorials: Merging vs. Rebasing

We don't have any set styleguide in place for commit messages, but we try to keep our commit messages descriptive and informative. We don't require any squashing prior to PR, but this is something that can help keep commit history cleaner.

• Try to keep your commits descriptive and informational while writing them when possible
• Optional: Squash your commits prior to PR
  • This is a solid writeup if you're interested: (Squash Commits into One)
• If you need to edit a git commit, you can use git commit --amend to rewrite with another message
  • Check out this explanation: Atlassian Git tutorials: git amend

• Generally, try to keep pull requests as small as possible. This helps with review and legibility
• Keeping your feature branch up to date and having clean, descriptive commits will help with review and legibility
• When ready to make a PR, fill out the PR template and please link the issue closed by the PR
  • One of the most important pieces of information in the template is if you've installed specific packages. Noting this (and any other instructions for reviewers) will help streamline our process!
  • Here is a link to our PR template.

• when merging from <branch-x> into develop, use Squash and merge. This allows changes to be represented in one commit.
• when merging from develop into master, use standard merge. This maintains the changes as one commit per change in the master branch.
  • make sure to run the CI Release workflow before merging into master so our libraries bump to the correct version

IMPORTANT NOTE our github wide settings on the UI are set to default to merge with Squash and Merge. In order to avoid this on master, make sure you use the dropdown arrow to switch to standard merge

merging <branch-x> into develop will deploy our v3 qa domains:

• https://hub.daohaus.fun
• https://summon.daohaus.fun

For an overview of our review process, check out our Wiki page on our Review process.

Ideally we're able to review and merge within 24 hours so that feature branches don't get too far behind. One way to help move this process a long is to keep PRs focused on a single issue/feature/fix. This way we'll be able to review and merge in much faster, and it also makes the reversion process smoother if we need to revert.