토론: Rebase or merge: integrating a branch

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

The article treats a linear history as the default preference, but for long-lived feature work merges preserve information that rebases destroy: which commits were developed together, and when integration actually happened. Bisect works fine on merge commits with `--first-parent`. I would frame the choice as 'linear for small, short-lived branches; merge for anything reviewed as a unit', rather than as a general preference for rebasing.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

번역이 없어 원문을 표시합니다. 원문

Worth adding for readers using GitHub or GitLab: the platform's 'squash and merge' button produces the linear history described here without any local rebasing, and the branch protection setting 'require linear history' enforces it. The trade-off is that the squashed commit's message is often the auto-generated list of commit titles unless someone edits it, so the guidance from the commit-message article still applies at merge time.