---
tags: v3, blacksmiths, show & tell
---

# v3 Blacksmiths Show & Tell (4/15/22)

## Git Workflow

- How do we want to work?
- `develop` as base branch
- merges into `master` have CI/CD
- small feature and bug branches off `develop`
- PR into `develop` for each feature
- `feature/feature-name`
- `hotfix/fix-name`
- PR would include the link to the issue/card
- Rebase & Squashing Process
- What do we want to do with this?
- Squash and merge process and delete the branch after merge
- Rebasing `develop` while working on feature branch to help keep up to date
- Keeping branches up to date
- Commit often and merge in where we can
- How do we tie this all in to our Review process?

## Review Process

- How many reviewers do we want?
- Start with 1
- Every branch has CI on it so that each branch is fully linted and fully tested
- This would run and then the review would be about the code
- Deluxe Review: have folks sync on specific topics where requested by the author
- Pattern PRs
- More substantial PRs -- share knowledge and establish our patterns
- Code reviews in meetings
- Schedule these as they come up for these types of reviews
- Can we set up notifications in the Discord? Set up a **code-review** channel?
- CI & Review Enforcement:
- Enforce this via GitHub Actions
- Prevent merging unless CI passes
- Require at least 1 Review
- SLA for Review:
- Goal to get a review within 24 hours as a goal we aim toward

## Versioning

- In libraries, when we push to master we should bump our version
- Can we enforce this with linting?
- Can we automate this via GH Actions?
- We'd have a failed build on npm if we don't

## Questions

- Having the checks in CI, but what do we do if the deploy breaks on a different library (as opposed to one directly impacted in the PR)
- Can we have the CI only check impacted or changed packages?
- Tests and checks:
- These should also exist locally
- What do we do when things break?
- Can keep pushing to the branch even if the CI fails -- we'd not *merge* things with failed builds
- Process:
- Ping an ops person or a 'lead' for each package
- How would we handle multiple PRs per day?
- Balance of feature branch PR approach with review speed
- CI for hotfixes:
- We won't be worrying as much about a QA/prod environment as we're pre-release, but what do we want to do if we have a hotfix in prod?
- If it goes to master, we'd want to see how we re-merge back to `develop`?
- Would we want to do a promotion process instead?
- Depends on policies for how long things hang out in develop?
- Longer standing feature branches -- everyone works on this for larger features
- Every branch creates a QA environment -- anything merged into staging is then ready for prod
- How often do we want to merge `develop` into `prod`?
- Code style guide / contributor guide
- https://daohaus.club/docs/devs/goals-and-ideals
- Rage vs. Sage
- We should probably revisit our `.gitignore` and review