Branching and Pull Requests
Why branches
A branch isolates work on a single change from the stable main. This lets several
people work in parallel, and an unfinished feature does not block production.
At ProfessNet, main is always "deployable" — it is what ships to Vercel.
The ProfessNet branching strategy
We use a lightweight trunk-based approach with short-lived feature branches.
| Prefix | Purpose | Example |
|---|---|---|
feature/ | New functionality | feature/widget-mfa |
fix/ | Bug fix | fix/login-redirect |
hotfix/ | Urgent production patch | hotfix/csrf |
chore/ | Cleanup, dependencies | chore/bump-next-15 |
Branches should live short — the longer they drift from main, the harder the
merge and the more conflicts.
git switch main
git pull
git switch -c feature/widget-mfa
The workflow
- Update
main(git pull). - Create a
feature/...branch. - Work in small, logical commits.
- Push the branch to GitHub.
- Open a Pull Request to
main. - Pass review + a green CI.
- Merge and delete the branch.
git push -u origin feature/widget-mfa
# then create the PR via gh CLI or on GitHub
gh pr create --base main --title "feat: widżet MFA" --body "Dodaje widżet MFA na dashboardzie."
What is a Pull Request
A PR is a request to merge your branch into main, plus a place for review,
comments, and CI results. It is the quality gate — at ProfessNet nothing reaches
main without a PR. A PR triggers GitHub Actions and generates a Vercel preview.
Tip: Keep PRs small (ideally < 400 changed lines). A small PR is reviewed faster and more reliably than a giant one that nobody wants to read. Split large tasks into a series of PRs.
Keeping a branch up to date with main
When main has moved ahead, pull in the changes to avoid drift:
git switch feature/widget-mfa
git fetch origin
git merge origin/main # or: git rebase origin/main
Merge keeps history as it is; rebase replays your commits "on top of"
main (a cleaner, linear history). The choice depends on the repo's conventions — the key
point is never to rebase a branch that someone else shares.
Protecting the main branch
On main we enable branch protection: required review, green status
checks, and no direct pushes. This guarantees that every change went through
review and CI.
Summary
A short feature/... branch → a small PR → review → green CI → merge into main.
Keep branches fresh against main, split work into small PRs, and never push
directly to the protected main. This is the core of the ProfessNet workflow.