rebase ile merge arasındaki fark nedir?

Question

Accepted Answer

Hem **merge** hem de **rebase** bir daldan diğerine değişiklikleri entegre eder, ancak farklı şekillerde yaparlar: merge **geçmişi korur** ve bir merge commit'i oluşturur, rebase ise **geçmişi yeniden yazar** ve doğrusal bir sıra oluşturur. Her birinin ne zaman kullanılacağını anlamak önemlidir.

## Merge — geçmişi korur (birleştirir)

```text
main:     A───B───C───────M     ← M is a MERGE COMMIT (two parents)
                  \       /
feature:           D───E
→ git merge feature: creates M combining the branches
  ✓ Preserves the actual history (shows the branch existed, when it merged)
  ✗ History has merge commits (can look cluttered with many merges)
```

## Rebase — doğrusal geçmiş için yeniden yazar (replay'ler)

```text
BEFORE:  main: A───B───C    feature: A───B───D───E
AFTER rebase feature onto main:
         main: A───B───C    feature: A───B───C───D'───E'
→ git rebase main (on feature): REPLAYS feature's commits (D,E) ON TOP of main's latest (C)
  ✓ LINEAR, clean history (no merge commits) — as if feature was built on current main
  ✗ REWRITES commits (D→D', E→E' are NEW commits with new hashes)
```

Rebase **taşır** dalınızın commit'lerini başka bir dalın ucundan başlayacak şekilde, yeni commit'ler oluşturarak — temiz, doğrusal bir geçmiş üretir.

## Rebase'in altın kuralı

```text
⚠️ NEVER rebase commits that have been PUSHED/SHARED (public history):
  → rebasing rewrites commits (new hashes) → diverges from what others have
  → causes serious confusion and conflicts for collaborators
→ Rebase only LOCAL, unpushed commits. Merge for integrating shared/public branches.
```

## Her birini ne zaman kullanacağınız

```text
MERGE  → integrating shared branches; preserving true history; team default for merging
  features to main (often via pull requests). Safe, non-destructive.
REBASE → cleaning up LOCAL commits before sharing; keeping a feature branch up-to-date
  with main (linear); achieving clean linear history. On local/private commits only.
→ Common workflow: rebase locally to tidy up, then merge (or PR) into main.
```

## Neden önemli

Rebase ile merge arasındaki farkı anlamak önemlidir çünkü her ikisi de değişiklikleri entegre eder ancak geçmiş üzerinde temelden farklı etkileri vardır ve doğru seçim (ve güvenli şekilde) yapmak önemlidir, bu nedenle yaygın olarak tartışılan değerli Git bilgisidir.

Temel ayrım — **merge geçmişi korur** (dalların birleştirildiğini kaydeden bir merge commit'i oluşturarak, gerçek geliştirme geçmişini tutarak) **rebase ise geçmişi yeniden yazar** (commit'leri başka bir dalın ucuna replay ederek, sanki çalışma en son kod üzerinde yapılmışsa diye temiz, doğrusal bir sıra oluşturmak için) — proje geçmişinin nasıl göründüğünü ve okunduğunu etkiler.

Dengeleri anlamak (merge: doğru ancak potansiyel olarak merge commit'leriyle karışık; rebase: temiz ve doğrusal ancak commit'leri yeniden yazarak) size değeri gerçek geçmiş mi yoksa doğrusal temizlik mi olduğunun tercihine göre seçim yapmanızda yardımcı olur.

En kritik olarak, **rebase'in altın kuralını** anlamak — **asla push'lanmış/paylaşılmış commit'leri rebase etmeyin** — önemlidir çünkü rebase commit'leri yeniden yazar (onlara yeni hash'ler vererek), bu nedenle paylaşılan geçmişi rebase etmek işbirlikçilerin sahip olduğu durumdan farklılaşır, ciddi kafa karışıklığı ve çatışmalara neden olur; rebase yalnızca yerel, push'lanmamış commit'ler için güvenlidir.

Bu güvenlik kuralı hayati önem taşır ve ihlal edildiğinde yaygın sorunların kaynağıdır.

**Her birini ne zaman kullanacağınızı** anlamak (merge paylaşılan dalları entegre etmek ve geçmişi korumak için, genellikle pull request'ler aracılığıyla özellikleri merge etmek için takım varsayılanı; rebase paylaşmadan önce yerel commit'leri temizlemek veya bir feature dalını doğrusal olarak güncel tutmak için — yalnızca yerel commit'ler) sağlam Git uygulamasını yansıtır.

Değişiklikleri entegre etmek temel olduğundan ve merge-vs-rebase seçimi (geçmiş ve güvenlik etkileriyle birlikte) sık bir karar ve mülakat konusu olduğundan, farkı anlamak — bunların geçmiş üzerindeki etkileri, kritik altın kural ve her birinin ne zaman kullanılacağı — temiz geçmişi güvenli bir şekilde korumak için merkezi ve yaygın olarak tartışılan bir ayrım olan ve her geliştirici tarafından anlaşılması gereken değerli, pratik olarak önemli Git bilgisidir.