GitHub new account

[Joshua-Dawkins]

When working on a long-lived feature branch, should I squash commits or rebase before merging, and how do I avoid breaking CI/CD?

[arthurrochamoreira]

For a long-lived feature branch, the best practice is to rebase frequently against the main branch to resolve conflicts in small increments and then squash your commits during the final merge to maintain a clean, linear history. To avoid breaking CI/CD, ensure your branch is fully updated with the latest production code and passes all automated pipelines before merging, while using feature flags to safely integrate large changes without prematurely exposing them to users.

[shreya180720]

For long-lived branches, the best practice is to rebase frequently against main to resolve conflicts incrementally, then squash messy "work-in-progress" commits into logical units before the final merge. To avoid breaking CI/CD, always use git push --force-with-lease after a rebase and ensure your final pipeline run occurs on the rebased head, as passing tests on an outdated base doesn't guarantee compatibility with the current main. Utilizing a non-fast-forward merge (--no-ff) at the end preserves the feature's history while maintaining a clean, linear timeline that is easy for teams to audit.

[MiguelToller]

For long-lived branches, the best practice is to rebase frequently against the main branch to stay up-to-date and resolve conflicts early.

[SatyamKaGithub]

rebase + (optionally) squash before merging, but do it in a controlled way to keep CI/CD stable.