City automation teams struggle with painful merges after weeks of isolated work. Which branching practice reduces that merge pain?
Select an answer to reveal the explanation.
Short Explanation
Think of short-lived feature branches as express buses: you fix a stop, get review, and merge back to the transit hub frequently. When you keep private feature branches for months, they become traffic jams that are much harder to untangle at merge time.
Full Explanation
City automation teams facing painful merges after weeks of isolation need to reduce divergence. Preferring short-lived feature branches that merge back to main frequently after review keeps each change small, surfaces conflicts early, and keeps main close to the code developers use as the base for new work. This cadence is the key practice for lowering merge pain. Maintaining private feature branches for months and postponing integration until the annual release review maximizes drift and leads to large, difficult conflicts. Forbidding merges until every department finishes unrelated projects serializes delivery and guarantees large, risky integrations. Maintaining one shared branch where force-pushes rewrite history hourly creates instability, not disciplined integration. Exam caveat: short-lived branches still require review; moving quickly does not mean committing straight to main. Practical check: track branch age and open merge-request duration, set a team norm to merge or rebase within days, and measure whether conflict-heavy merges decline in municipal automation repos. Short-lived branches also support incident response: hotfixes can start from recent main rather than month-old private branches, helping city automation recover faster when production scripts fail.