For new associates

Git at BizzNEST

How we branch, commit, open pull requests, review code, and track work. Read it once top to bottom; keep the cheat sheet at the end open while you work.

02Branches03Commits04Pull requests07Common mistakes09Cheat sheet
01

How work flows

Every piece of work follows the same six steps. Scroll through them once; each one has its own section further down.

1
Issue

Every task starts as a GitHub issue with a description and labels. Add it to the project board and assign it to yourself when you start.

Issues → New issue → add to Projects → Backlog
Project board →
2
Branch

Branch off development. Name it with your initials, the issue number, and a short description.

git checkout -b ar-111-fix-uploader
Branches →
3
Commit

Small commits, one scope each. Type, scope, and an imperative subject with no period.

git commit -m "fix(uploader): handle empty files"
Commits →
4
Pull request

Open a PR into development. Fill out every section of the template, link the issue, and assign two reviewers including a lead or admin.

Closes #111 · card → In Review
Pull requests →
5
Review

Reviewers respond within 24 hours. Address every comment, push new commits, and re-request review.

git push → Re-request review
Code review →
6
Merge & close

Merge after approval. Move the card to Done and close the issue.

Merge pull request · card → Done
Project board →
One rule underneath all of it: always have a GitHub issue for the work you are doing, and keep its card on the project board in the correct column.
02

Branches

We follow Gitflow. Three long-lived branches, and short-lived task branches off development.

How branches relate
mainstagingdevelopmentar-111-…production-readydemo-readyyour working basetask branchgit checkout -bcommitsPR → developmentdemodeploy

Hotfixes are the one exception: they branch off main and merge back into both main (tagged) and development.

Naming

<initials>-<issue#>-<small-description>
  • initials: yours, so everyone can see who owns the branch
  • issue#: the GitHub issue number the branch relates to
  • small-description: usually no more than 3 words

Alex fixing a bug on issue 111: ar-111-fix-uploader

Where PRs go

  • Task branch → development, reviewed by another developer
  • development → staging when code is locked in for a demo
  • development → main when code is ready to deploy
  • Hotfixes branch off main, then merge back into main (tagged) and development
Feature branch → PR → development
1
Branch off development
git checkout -b ar-111-fix-uploader
2
Commit your work
git commit -m "fix(uploader):…"
3
Push
git push
4
Open PR → development
card → In Review
5
Review, approve, merge
card → Done, close issue
Keeping your branch up to date

Pull the latest development, then merge it into your branch.

1
Check out development
git checkout development
2
Pull
git pull
3
Back to your branch
git checkout your-branch-name
4
Merge development in
git merge development
03

Commits

Our convention is based on the Karma Runner project. Small commits, one scope each, so they are easy to find, reason about, and revert.

Format

type(scope):subject
(blank line)
body — optional
  • scope: one or two words in parentheses narrowing what changed
  • subject: imperative mood, present tense, starts with a verb, no period at the end. Think newspaper headline.
  • body: only when it helps — a new package, a build change, context a future developer needs, or a note to your senior developer on the last commit of a PR.
Examples
refactor(app-component): import user service and add routes
feat(login): create/setup
fix(uploader): handle empty files. resolves #111

The 8 types

These are your only options.

feat
A new feature for the application user: a new module, new functionality.
fix
Bug fix to production code. GitHub issues, fixing a bug.
docs
Documentation changes: comments, README files.
style
Code formatting only. Not CSS. Reformatting, adding semicolons.
refactor
Refactor of production code: upgrading a package and adapting to it, renaming a let or const.
test
Unit testing only. Creating or refactoring tests, no production code changes.
chore
Updating gulp, webpack, package.json. Developer-facing only.
workaround
Temporary fix until a more robust solution is found.
One scope per commit

You changed app.component.ts, app.router.ts, login.component.ts, and login.component.scss. That is two scopes, so it is two commits:

git add the app.component files
git commit -m "refactor(app-component): import user service and add routes"
git add the login files
git commit -m "feat(login): create/setup"
04

Pull requests & reviews

Every pull request goes through a review. No exceptions.

  1. 01
    Open a PR
    Follow the PR template and fill out every section.
  2. 02
    Assign two reviewers
    One must be a team lead or admin.
  3. 03
    Reviewers reply in 24h
    If you are assigned, make time to review promptly.
  4. 04
    Address all feedback
    Make the changes, push new commits, re-request review.
  5. 05
    Merge after approval
    Merge into development per the branching guidelines.
Steps 03 and 04 repeat until every reviewer approves. Not approved yet? Push fixes and re-request review.

What reviewers look for

Code does what the linked issue describes
Variable and function names are clear and descriptive
No console.log statements left in the code
No hardcoded values that should be in environment variables
Follows the project’s existing code style and patterns
Commit messages follow the commit conventions
Branch name follows the naming convention
No commented-out code left behind
Changes are tested and working

Giving feedback

  • Be specific: say what needs to change and why.
  • Suggest alternatives instead of just saying “this is wrong.”
  • Use GitHub’s suggestion feature to propose exact code changes.
  • Keep it constructive and professional.
  • Prefix optional suggestions with nit: so the author knows it is not blocking.

Receiving feedback

  • Reviews are about the code, not you.
  • Ask clarifying questions if you do not understand a comment.
  • Treat every review as a learning opportunity.
  • Thank your reviewers.
05

Project board

GitHub Projects is how we track tasks, bugs, and progress. Your lead checks the board during standups and weekly meetings, so keep it accurate.

Backlog
Planned, not started.
New issues land here.
In Progress
Actively being worked on.
Move here when you assign yourself and start.
In Review
Open PR waiting for review.
Move here when you open the PR.
Done
Merged and complete.
Move here when the PR merges, then close the issue.

Issues first

  • Every task starts as a GitHub issue, with a description of the work and labels for the type of task.
  • Use the matching issue template: feature request, bug report, or epic.
  • Add it to the board from the issue sidebar under Projects.
  • Assign it to yourself when you start.

Daily habits

  • Update your cards every day.
  • Link PRs to issues with keywords like Closes #12 in the PR description.
  • Finish tasks before starting new ones.
  • Blocked? Comment on the issue explaining why and mention your lead.
06

Repo setup & tooling

Creating a repository

  • Create it under the BizzNEST organization using the BizzNEST/.github template. Leave "Include all branches" unselected.
  • Name it for the topic and scope, lowercase with hyphens: tesla-map, cool-app-api.
  • Write a description that defines the repo's scope.
  • Visibility is Private. Always.

Local environment

# clone with the HTTPS or SSH URL
git clone https://github.com/BizzNEST/your-repo.git
# install dependencies
npm i
# create .env in root for secrets
# run the dev server
npm start

VS Code extensions: Prettier for formatting, Live Server for preview. Mac setup: Homebrew, nvm, VS Code.

Never push .env or credentials.json to GitHub.
Run npm i every time you pull from origin so your dependencies match.
Keep repo visibility Private.
07

Common mistakes

The things reviewers send back most often.

Avoid
fix-bug
Do
ar-111-fix-uploader
Avoid
Fixed the uploader.
Do
fix(uploader): handle empty files
Avoid
One commit touching login and app routing
Do
Two commits, one per scope
Avoid
update(uploader): tweak
Do
Only the 8 types: feat fix docs style refactor test chore workaround
Avoid
console.log left in, commented-out code left behind
Do
Clean it up before you push
Avoid
API key hardcoded in source
Do
Put it in .env and never commit that file
Avoid
Pulling from origin, then running the old node_modules
Do
Run npm i every time you pull
Avoid
Three cards sitting in In Progress
Do
Finish before starting; update cards daily
08

Before you open a PR

Run through this yourself. It is the same list your reviewers use.

0 of 12 checked
09

Cheat sheet

Click any command to copy it.

Start a task
Save work
Stay current
Set up a repo
Branch
<initials>-<issue#>-<desc>
Commit
type(scope):subject
Types
feat fix docs style refactor test chore workaround

Blocked for more than 45 minutes? Post in your team channel. Want to improve these standards? Open an issue in the Standards & Practices repo.