Question 1

What is trunk-based development?

Accepted Answer

A branching strategy where everyone commits to a **single shared branch** frequently — at least daily — with short-lived branches lasting hours rather than weeks. It is the practice most strongly associated with high-performing engineering teams in the research on software delivery.

**What it replaces.** Long-lived feature branches, where work is isolated for weeks and merged at the end. Isolation feels safe and produces the opposite: **the longer a branch lives, the more the trunk diverges from it**, and the merge becomes large, conflict-ridden and risky. Integration problems are discovered at the worst possible moment, all at once.

**Why frequent integration is safer.** Small merges rarely conflict. Problems surface within hours, when the change is small and the author remembers it. The build is continuously verified against what everyone else has done.

**The obvious objection: how do you commit unfinished work?** Through techniques that separate **deploying** from **releasing**:

**Feature flags**, so incomplete code is present and inactive. This is the central enabling practice.

**Branch by abstraction**, introducing an interface and migrating implementations behind it gradually rather than in one large change.

**Expand and contract** for schema changes — add the new column, write to both, migrate, then remove the old one — so each step is independently safe.

**Keeping changes small**, which is a discipline rather than a tool.

**What it requires:** a **fast, trustworthy automated test suite**, since the trunk must always be releasable; quick code review, measured in hours; and a culture where breaking the build is fixed immediately rather than left.

**Where it fits badly:** open-source projects accepting contributions from untrusted parties, where pull requests from forks are the appropriate model; teams with slow or unreliable test suites, where merging frequently is genuinely dangerous; and regulated environments requiring pre-merge sign-off — though those usually indicate a review-speed problem rather than a branching one.

**Release branches** are compatible with it: cut a branch at release time, fix on trunk, cherry-pick backwards.

Question 2

What is CI/CD actually doing?

Accepted Answer

Continuous integration verifies that changes work together, continuously; continuous delivery keeps the software always in a releasable state; continuous deployment goes further and releases

Question 3

What is a feature flag?

Accepted Answer

A feature flag (or feature toggle) is a conditional in code allowing behaviour to be changed without deploying new code. The feature exists in the deployed application, and a configuration value

Question 4

When should I use git rebase instead of git merge?

Accepted Answer

Both commands integrate work from one branch into another, and they differ in what happens to history. Merge records that two lines of development came together, creating a merge commit with two

Question 5

What is the difference between git fetch and git pull?

Accepted Answer

Fetching downloads new commits from the remote and updates your remote-tracking references. It changes nothing about your working tree or your local branches. After fetching you know what has

Question 6

What is a merge conflict and how do I resolve it?

Accepted Answer

A conflict occurs when two branches changed the same region of a file and Git cannot determine which version is correct. It is not an error, and it does not mean anyone did anything wrong. Git

Question 7

Why does documentation always go out of date?

Accepted Answer

Because documentation and the code it describes are coupled in meaning but decoupled in enforcement — nothing breaks when they diverge, so they diverge. The core mechanism. Code has a merciless

Related Questions