Main Branch Stability with Fast-Moving Features

[Litis-Trion250]

Discussion Type

Question

Discussion Content

Problem Body

Let’s say I have a team that uses GitHub with Fast-Forward Merge only policy for all PRs into master. A developer develops on a long living feature branch feature/massive-refactor for two weeks. These 100+ smaller, stable changes get merged into main while working on this. The developer frequently rebase their feature branch onto the newest main in order to remain updated.

The heart of the problem: Silent conflict and a cut history

The Failed Merge: The last rebase looks good locally. The developer opens the PR and Squashes their commits (to cleanup history) at the time the PR is merged.
But when the developer practice of rebasing locally and testing only tested the feature branch, a subtle non-syntax clash was vanquished – maybe some role in a system-wide configuration file was overwritten or perhaps he didn't see an update to a signature in main in his rebase resolution.

result: The net result ends up being that we are breaking the build/tests on main right after this merged commit lands.

The Dilemma of the Recovery: The team now confronts a tricky recovery situation:

Option 1: Revert Since the big, squashed merge is all but unaware of the history it came from, reverting it would be quite difficult and incurs a loss of the entire refactoring history up to this point as that work must also be done over again.
Option 2: Fix-Forward: Creating a new fix-forward commit is perilous and usually difficult, as the local context of the original author will not easily replicate the failure that now appears in the primary codebase.

The issue with the root cause is that the Fast-Forward/Rebase method prioritizes clean history at the cost of safety in merging and traceability. That single squash commit that was committed to main is now difficult to isolate and revert.

[Rocky-Dewan]

The resolution is a philosophical shift from liking only clean, linear history to liking branch stability and easy rollback.

Step 1: Alter the Merge Strategy (Use Merge Commits)Instead of forcing Fast-Forward or Squash, the team can employ Standard Merge Commits (or a local "Rebase-and-Merge" convention with a single merge commit). This creates a non-linear but recoverable history with a Merge Commit M linking the feature branch to main's history M1 and M2. Why it works: A merge commit can safely be reverted using
git revert -m 1 <merge-commit-sha>
This successfully undoes all the modifications out of the feature branch without affecting subsequent commits to main and without destroying the initial history of the feature branch (that can again be merged subsequently after resolution).
Step 2: Apply Necessary Branch Protection
Apply GitHub's Branch Protection Rules to the main branch to mandatorily enforce quality checks.
GitHub Settings Steps:

• Go to Settings -> Branches -> Branch protection rules for main.
• Require passing status checks before merging: Enable check for CI/CD and Unit Test checks.
• Require linear history: Turn off this rule. This enables merge commits, making it safe to revert.
• Allow explicit merge techniques: Enable Merge commit and Rebase and merge.

3. Recovery Process (The Safe Revert)If the merged PR still breaks main, recovery is simple and non-destructive.
   Code Steps (The Fix):Identify the Merge Commit: Find the SHA of the faulty merge commit M.Revert Safely: Use the m-1 flag to specify the parent side of the merge that should be preserved untouched .

git revert -m 1 <SHA-of-Broken-Merge-Commit>

# Example: git revert -m 1 1a2b3c4d5e6f7g8h9i0j

then push the revert:
git push origin main
Fix and Re-Merge: The initial developer pulls the initial branch, fixes the root bug, pushes the fix, and opens a new PR, which may now be re-merged safely.Thus, main remains stable while offering a clean, rapid route to undo complex changes.

This process maintains the stability of main while providing a clean, fast way to undo complex changes.