Git tarihini ne zaman ve nasıl yeniden yazmalısınız?

Question

Accepted Answer

Git, commit'leri **tarih içinde yeniden yazmanız** — değiştirme, rebase yapma, squashing veya commit'leri silme — yapılmasını sağlar ve bu, commit'leri temizlemek veya sorunları düzeltmek için kullanılır. Güçlü bir özelliktir ancak dikkatli bir şekilde yapılmalıdır: **paylaşılan** tarih yeniden yazılması ciddi sorunlara neden olur, bu nedenle bunu çevreleyen kurallar kritiktir. ## Tarih yeniden yazmanın yolları ```text git commit --amend → modify the most recent commit (message or content) git rebase -i → squash, reword, reorder, edit, drop commits (interactive) git rebase → replay commits onto another base (linear history) git reset → move the branch pointer (discard/uncommit) git filter-repo → rewrite MANY commits (remove a file/secret from all history) → All of these change commit HASHES (rewriting = creating new, different commits). ``` ## Altın kural ```text ⚠️ NEVER rewrite history that has been PUSHED/SHARED (that others may have): → rewriting changes commit hashes → your history DIVERGES from collaborators' → they'll have the old commits; pulls create duplicates/conflicts; chaos ensues → forces everyone to painfully reconcile → a serious disruption ✓ Rewrite ONLY local, unpushed commits (cleanup before sharing). ✗ On shared branches → use REVERT (a new undoing commit) instead, which is safe. ``` ## Tarih yeniden yazmanın meşru kullanımları (lokal) ```text ✓ Clean up messy WIP commits before opening a PR (squash, reword) → clean history ✓ Fix a mistake in the last commit (amend) before pushing ✓ Keep a feature branch linear/up-to-date with main (rebase) before sharing ✓ Remove a SECRET accidentally committed (filter-repo) — though if it was PUSHED, the secret must be ROTATED (it's already exposed; rewriting alone isn't enough) ``` ## Eğer paylaşılan tarih yeniden yazmanız gerekirse (nadir) ```text → COORDINATE with the whole team (everyone stops, re-syncs) → Force-push carefully: git push --force-with-lease (safer than --force — checks first) → Everyone must reset/re-clone to the rewritten history → Do this only when truly necessary (e.g. purging a leaked secret) and with agreement. ``` ## Neden önemli Git tarihini ne zaman ve nasıl yeniden yazacağınızı anlamak, kıdemli seviyede önemli bir bilgidir çünkü tarih yeniden yazma **güçlü ancak tehlikelidir** ve kuralları — özellikle paylaşılan tarih etrafındaki kuralları — anlamak ciddi sorunları önlerken meşru temizlemeyi sağlar. **Yeniden yazmanın yollarını** (son commit için amend, squashing/rewording/reordering için interactive rebase, doğrusal tarih için rebase, reset, büyük ölçekli değişiklikler için filter-repo) bilmek ve bunların hepsinin **commit hash'lerini değiştirdiğini** (yeni commit'ler oluşturduğunu) anlamak temeldir. En kritik olanı, **altın kuralı — hiçbir zaman paylaşılan/push edilmiş tarih yeniden yazmayın** — anlamak gereklidir çünkü yeniden yazma hash'leri değiştirir, tarihçinizin işbirlikçilerininkinden (hala eski commit'leri olan) farklılaşmasına neden olur ve bu da kopyalanmış commit'ler, çakışmalar ve ağır uzlaştırmayla sonuçlanır; paylaşılan tarih yeniden yazılması bu kuralın engellediği ciddi bir aksamadır, **revert** ise (güvenli yeni bir geri alma commit'i) paylaşılan branch'ler için doğru yaklaşımdır. **Meşru lokal kullanımları** (push etmeden önce WIP commit'leri temizleme, push etmeden önce hataları düzeltme, paylaşmadan önce doğrusal kalmak için rebase — hepsi lokal, push edilmemiş commit'ler üzerinde) anlamak, yeniden yazmanın ne zaman uygun ve değerli olduğunu açıklığa kavuşturur. Ciddi bir güvenlik nüansı: bir **sır commit edilip push edilmişse**, tarihçi yeniden yazarak onu kaldırmak yetersizdir — sır zaten açığa çıkmıştır ve **döndürülmelidir** (önemli bir gerçek dünya güvenlik noktası). **Paylaşılan tarih yeniden yazmanın nadir gerekli durumunu** nasıl ele alacağınızı bilmek (takım koordinasyonu, `--force` yerine `--force-with-lease`, herkesin yeniden senkronize olması) olgun yargıyı yansıtır. Tarih yeniden yazma güçlü olduğundan ancak paylaşılan tarih üzerinde yanlış kullanıldığında ciddi sorunlara neden olduğundan ve altın kuralı, meşru kullanımları ve güvenli uygulamaları anlamak bunun sorumlu bir şekilde kullanılması için gerekli olduğundan, Git tarihini ne zaman ve nasıl yeniden yazacağınızı anlamak önemli kıdemli seviyede bir bilgidir — güvenlik kurallarını anlamak (özellikle hiçbir zaman paylaşılan tarih yeniden yazmamak) gerçek işbirliği felaketlerini önlediği ve takımla Git'le çalışan kıdemli roller için beklenen yargıyı yansıttığı bir konudur.