2G

Development

The day-to-day workflow every developer follows from picking up a story to merging to main.

Developer protocols matter because most engineering failures are not caused by a complete lack of skill. They are caused by inconsistent execution: long-lived branches, skipped checks, unclear PRs, late conflict resolution, and merges that were never truly production-ready. A good delivery protocol reduces that inconsistency.

This guide turns the team’s default workflow into a single, readable path from story pickup to production-safe merge. The focus is simple: keep main releasable, keep changes easy to review, and make rollback straightforward when something still goes wrong.

The 11 Step Developer Workflow

This sequence is designed to reduce risk gradually rather than discovering problems all at once during PR review or after merge.

Key takeaway: The workflow is optimised for small, reviewable, reversible changes rather than large batches of risk.

Branch Naming

Branch naming is a small practice, but it improves traceability immediately. A branch should tell reviewers what kind of work it contains and how to map it back to a ticket.

feature/JIRA-123-add-discount-engine    # New feature
bugfix/JIRA-456-fix-null-order-total    # Bug fix
hotfix/JIRA-789-revert-bad-migration    # Production hotfix
chore/upgrade-spring-boot-3.2           # Non-functional work

Key takeaway: a good branch name reduces ambiguity for reviewers, release tracking, and future debugging.

Commit Message Format

Commit messages are part of the project history, not just a formality to get past Git. They should explain the intent clearly enough that someone reading the history later can understand why the change existed.

Use the imperative mood in the summary. Include the JIRA ticket.

[JIRA-123] Add order discount calculation for loyalty tier
Implements 10% discount for users with loyalty status GOLD.
Uses DiscountStrategy pattern to allow future tiers without
modifying OrderService.
Closes #JIRA-123

What to include in the body:

• What changed and why (not how the diff shows how)
• Any non-obvious decisions made
• Links to relevant tickets, docs, or discussions

Key takeaway: Commit messages should preserve decision context, not restate file-level edits.

PR Description Template

The pull request description is the reviewer’s briefing note. If it is vague, the review usually becomes slower and less effective.

## What
Short description of the change.
## Why
Business or technical motivation. Link to JIRA story: [JIRA-123]
## How
Key implementation decisions. What should the reviewer focus on?
## Testing
- ☐ Unit tests added/updated
- ☐ Integration tests pass
- ☐ UI automation green on local machine
- ☐ Desk check done in CI environment
## Checklist (PR Author Self-Review)
- ☐ No PII or secrets in code or logs
- ☐ Backward compatible (or feature toggle used)
- ☐ README updated if behaviour changed
- ☐ API spec updated if contract changed
- ☐ No new warnings in CI (sonar, PMD, checkstyle)

Key takeaway: a strong PR description shortens review time and surfaces risks before reviewers need to infer them from the diff.

Rebasing Strategy

Rebasing regularly keeps your branch close to the truth of main. That matters because the longer you wait, the more likely conflicts become harder to reason about.

# Daily: stay current with main
git fetch origin
git rebase origin/main
# Resolve conflicts during rebase (not at PR time)
# This keeps your commits clean and reduces merge surprises

Tip

Rebase early and often. A conflict resolved on day 3 is far smaller than one resolved on day 10.

Key takeaway: resolve drift continuously instead of turning rebase into a last-minute merge tax.

Squash Merge

Squash merging is mainly about operational simplicity. It keeps the main branch history clean and makes full-feature rollback much easier.

When the feature branch is reviewed and approved:

# From the GitHub PR UI: select "Squash and merge"
# Or manually:
git checkout main
git merge --squash feature/JIRA-123-add-discount-engine
git commit -m "[JIRA-123] Add order discount calculation for loyalty tier"

This collapses all WIP commits into one clean commit on main. Reverting the entire feature is then a single git revert.

Key takeaway: one clean merge commit is easier to review in history and safer to revert under pressure.

Rollback Procedure

Rollback is part of the protocol because failures still happen. A release workflow is only complete if it includes the fastest safe path back to a working state.

If a merge to main breaks the build or causes a regression:

# Find the commit to revert
git log --oneline main
# Revert the squashed commit
git revert <commit-hash>
git push origin main
# → CI builds and deploys the revert automatically

Warning

Long-lived feature branches defeat the purpose of continuous integration. If a branch lives longer than a sprint, the merge cost grows exponentially. Use feature toggles to merge incomplete work safely.

Key takeaway: the ability to revert quickly is one of the reasons the earlier steps are strict about branch flow, squash commits, and keeping main releasable.

Why These Steps Matter

Tip: Keep main releasable

The goal of this protocol is that main is always in a deployable state. Every step – desk checks, squash commits, UI automation gating exists to protect that invariant.

Danger: ANTI-PATTERN

Merging without running automation tests locally.

Skipping local automation to “save time” is how broken code reaches main. The desk check is the last safety net before PR review.

Danger: ANTI-PATTERN

Committing directly to main.

Even a “trivial one-line fix” needs a feature branch, desk check, and PR. The one-liner that bypasses the process is often the one that causes a production incident.

Final Takeaways

• Use feature branches, frequent rebasing, and small commits to keep change sets manageable.
• Treat testing, desk checks, and automation as merge prerequisites, not optional polish.
• Keep main production-ready by relying on feature toggles and backwards-compatible changes.
• Prefer squash merges so rollback stays fast and operationally simple.
• Use the protocol to reduce uncertainty, not to add ceremony.

Written by

Balaji G