Recommended Free Tools
iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Three developers can work in one monolith without making integration a recurring crisis: agree on a shared integration point, keep changes small, bring work together often, and use reviews and automated checks that fit the team. No branching model prevents every conflict. Git can combine edits in different parts of a file, but people must decide what to do when changes overlap.
Why merge conflicts become a team problem
Conflicts are most disruptive when separate changes diverge for a long time, particularly when contributors edit the same files or behavior. Git can bring together non-overlapping edits automatically; it cannot infer the intended result when two edits compete in the same area. The Git project’s merge documentation describes how Git presents those textual conflicts for resolution.
Frequent integration limits how much unseen change accumulates before work meets. It does not eliminate conflicts or replace communication about shared interfaces, schemas, build files, and broad refactors.
Agree on a lightweight operating model
- Choose one integration point. Usually this is the repository’s default branch. Make clear how work reaches it and who is responsible for merging.
- Keep each change focused. Split work into small logical steps that can be reviewed and tested independently. The Git project recommends splitting changes into small logical steps and committing each one in its workflow guidance.
- Flag shared areas early. Before changing a shared interface, schema, build configuration, or widely used component, tell the other developers what is changing. This gives anyone working nearby a chance to coordinate.
- Integrate regularly. Either merge small increments directly into the common branch or use short-lived branches and keep them current with the base branch. Avoid leaving a large, unintegrated change until the end.
- Review and test before merging. Agree on a practical review policy and run relevant automated checks. Require additional approvals or checks only where the risk justifies the added wait.
GitHub’s project coding guidance describes branches as a way to isolate work and pull requests as a place to discuss and evaluate it. It also recommends meaningful commits and keeping an open branch current. These practices make changes easier to inspect; they do not guarantee that a merge will be conflict-free.
Choose a workflow that fits your release and review needs
There is no documented test showing that one workflow is best specifically for a team of three. Choose based on how quickly changes need to reach the shared branch, how much review is needed, the confidence your tests provide, whether work depends on other work, and whether the team can tolerate a temporarily incomplete main line.
| Workflow | Integration and review | What it asks of the team | Good fit when |
|---|---|---|---|
| Trunk-based development | Developers integrate small updates into a common branch frequently; review can happen around those increments. | Reliable automated tests and CI must give prompt feedback. The team also needs a safe way to manage unfinished work. | Small changes can be integrated continuously and the team can keep the shared branch in a usable state. AWS describes these conditions in its trunk branching guidance. |
| Short-lived feature branches with pull requests | Each branch isolates a focused change until it is discussed, checked, and merged. | Developers need to update open branches from the base and respond to review and CI feedback. Branches that stay open too long can accumulate synchronization work. | The team wants an explicit review point before changes reach the shared branch. GitHub documents this approach in its project coding guidance. |
| Stacked pull requests | Dependent changes are split into reviewable layers, with each upper layer based on work below it. | Branches and review context must stay synchronized; CI results may depend on which parts of the stack are present. | Later work depends on a foundation that is not ready to merge yet, and splitting the work allows review to begin sooner. See GitHub’s guide to stacked pull requests. |
When to use trunk-based development
Prefer this when the team can make small increments, integrate them frequently, and trust automated tests and CI to surface problems quickly. It is not a shortcut around review or test quality. If unfinished work would make the shared branch unsafe, first decide how to keep that work from disrupting the rest of the team.
Rank #2
When to use feature branches and pull requests
Use short-lived branches when a focused change needs a clear discussion and review before merging. Keep the pull request small enough to evaluate, and update its branch from the base periodically so differences do not accumulate unseen.
When dependent work needs a stack
Suppose one change introduces an interface and another implements behavior that depends on it. A stack lets the interface change sit below the implementation in separate review layers. Make the dependency visible to reviewers and account for the extra branch management; a stack is useful only if its review and synchronization overhead is less costly than waiting for the foundation to merge.
Resolve a conflict without losing the intended change
When Git marks a conflict, pause long enough to understand both sides. If the correct combined behavior is unclear, ask the other contributor rather than resolving the text by guesswork.
- Make sure your work is safe. Commit or otherwise preserve local changes before attempting a complicated resolution.
- Inspect both versions and the intended behavior. Read the conflicting section in context; the right result may combine, replace, or restructure the edits.
- Coordinate if intent is unclear. Ask the person whose change overlaps yours what behavior they were aiming for.
- Edit a coherent result. Remove conflict markers and implement the agreed behavior, rather than merely choosing one side without checking its effect.
- Stage the resolved file and test it. After resolving the conflict, stage the result and run the relevant tests before continuing the merge.
- Back out if the merge is too confusing. Git documents
git merge --abortas a way to abort a merge and restart from a safer point.
Git’s merge documentation explains that Git records the common ancestor and both sides for conflict handling. A conflict is a request for a human decision about the result, not evidence that the repository structure has failed.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Keep review controls proportional to the risk
A three-person team can benefit from pull-request controls without making every change wait through a heavyweight approval process. Repository settings can require reviews or status checks and route sensitive files to designated code owners. Apply stricter rules to changes that warrant them, and keep routine work moving when the risk is low. GitHub covers these controls in its project coding guidance.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
