A Healthy Team Git Workflow
Fast recall
Quick revision
Core answer
Whether you describe branch-per-feature, small commits, PR review, and 'main is always deployable', and know the commands.
Committing straight to main, or huge long-lived branches that become hard to merge.
Branch per feature, small focused commits, PR for review, merge to main after approval. main is always deployable; never commit straight to main.
Interview-ready guide
Interview answer
A team workflow turns an individual edit into a reviewable, recoverable change. I start from the latest agreed base branch, create a short-lived feature or fix branch, and keep its scope small enough that another developer can understand it without reconstructing several unrelated tasks.
While working, I inspect the diff and create focused commits whose messages explain the intent. Tests, migrations, documentation, and configuration needed by the behaviour travel with it. Local-only settings, logs, build output, and secrets belong in appropriate ignore rules and never in history.
For example, a payment validation branch can contain one commit for the rule and tests, followed by a small review fix. I push the branch and open a pull request describing the problem, the chosen behaviour, how it was verified, and any rollout or migration concern.
Continuous-integration checks and human review catch different risks. Before merge, I bring the current target branch into my work using the team's merge or rebase policy, resolve conflicts by understanding both intended changes, rerun tests, and let the author of the surrounding code review uncertain resolutions.
Teams may use merge commits, squash merges, or rebasing. A healthy policy is documented and consistently applied; the enduring goals are small changes, protected shared branches, clear review, passing checks, and history that can be traced or reverted safely.
A Healthy Team Git Workflow
Direct Answer
A healthy Git workflow starts from an updated shared branch, makes one focused change on a short-lived branch, records small tested commits, publishes the branch, and uses a pull request for automated checks and review before merge. The developer resolves conflicts with the latest target branch and removes temporary code or secrets before review. The exact merge policy can vary; consistency, recoverability, and reviewable change size matter more than choosing merge or rebase everywhere.
Deep Dive & Architecture
Branching isolates an unfinished line of work, but isolation is temporary. The longer and broader a branch becomes, the more assumptions diverge from the shared branch. Short-lived branches reduce conflict size and allow review while the reason for a change is still fresh.
A useful commit is an atomic explanation: the repository should remain coherent after it, and reverting it should remove one idea. Mechanical formatting mixed with behaviour changes hides review signals. Staging selected paths or hunks lets a developer separate work even when the working tree contains several experiments.
A pull request is a quality gate and a communication record. Automated checks can prove repeatable facts such as compilation, tests, formatting, and migrations. Reviewers examine design, missing cases, security, clarity, and fit with neighbouring changes. A good description gives them the context the diff cannot provide.
A conflict is not solved merely when marker lines disappear. Both branches changed a shared base, so the resolver must decide the combined intended result. After editing, stage the resolved file, inspect the final diff, and rerun affected checks. Never choose an entire side mechanically when both contributions matter.
Code Example
git switch main
git pull --ff-only origin main
git switch -c feature/order-validation
# edit and test the focused change
git add app/models/order.rb test/models/order_test.rb
git commit -m 'Validate positive order quantity'
git push -u origin feature/order-validation
# open a pull request, address review, then merge by team policy
Common Mistakes & Pitfalls
Committing straight to main, or huge long-lived branches that become hard to merge.
Check your understanding
Answer these without looking back at the article.
- What makes a commit atomic and easy to revert?
- Why should a merge conflict be followed by relevant tests?
- How do automated checks and human review complement each other?
Looking for a structured roadmap?
Every module on this page is also part of the full Java backend interview track.