A team is choosing how to lay out dev, staging and prod in one Terraform repository. One proposal uses a long-lived Git branch per environment with the same file layout on each, and the other uses a directory per environment on a single main branch, each calling shared modules. Which assessment is accurate?
Select an answer to reveal the explanation.
Short Explanation
Long-lived environment branches start as twins and end up as distant cousins: hotfixes land in one, cherry-picks get missed, and merges get painful. Directories on one branch keep every environment's differences out in the open, right where your reviewers can see them.
Full Explanation
With a directory per environment on one branch, each environment is a small root configuration that calls versioned shared modules and sets its own inputs and backend. Differences between environments are visible in the same commit, reviewers can compare them directly, and promotion is a pull request that changes a module version or variable in the next environment's directory. Long-lived environment branches tend to diverge: urgent fixes land in one branch, merges between branches carry unrelated changes, and the true difference between environments is hidden in branch history rather than stated in code. Branches do not provide state separation by themselves; state location comes from backend configuration, and separate directories can each use their own backend or workspace just as easily. Merging the same commit through each branch does not guarantee identical code once branches have diverged, and conflicts make that worse over time. Terraform has no knowledge of Git branches and does not restrict which branch a configuration comes from; VCS-connected HCP Terraform workspaces track whichever branch they are configured to use. Exam caveat: HCP Terraform workspaces can each point at a directory in the same repository. Operational check: compare environments by diffing their directories in one commit.