Git branch nedir ve merge ile rebase arasındaki farklar nasıl çalışır?

19 Eki 12:22

Geçen sene bir projede UI kitimizi ayrı bir repo’ye taşıdım, master’da stabil sürüm var ama yeni componentler eklemek için “feature/button‑style” adında bir branch açtım. Branch oluşturmak aslında `git checkout -b feature/button‑style` ya da `git branch feature/button‑style && git checkout feature/button‑style` komutlarıyla bir satırda halledilir; bu yeni dal, HEAD’i o branch’e yönlendirir ve ana dal (main) ile aynı commit’den başlar. Ben genelde “feature/…”, “bugfix/…” gibi isimlendirme yaparım, böylece hangi amaca hizmet ettiğini bir bakışta anlarsın. Çalışmalarını bitirdiğinde iki seçenek var: `git merge` ya da `git rebase`. Merge yaptığımda `git checkout main && git merge feature/button‑style` komutu, iki dalı birleştirir ve bir “merge commit” oluşturur; bu, geçmişteki tüm dallanma‑birleşme noktalarını korur, yani “hangi değişiklik ne zaman birleştirildi” geçmişi net kalır. Rebase ise `git checkout feature/button‑style && git rebase main` şeklinde çalışır; feature dalını, main’in son commit’inin üzerine yeniden oynatır, yani line‑arı bir tarihçe elde edersin. Valla, rebase sonrası push ederken `git push --force-with-lease` kullanmak zorunda kalıyorsun, yoksa remote’da çakışma çıkar. Bence, ortak bir ekipte merge daha güvenli, çünkü tarihçeyi bozmuyorsun; tek kişi çalışıyorsan ya da temiz bir commit akışı istiyorsan rebase harika. Ben de genelde feature branch’i bitince önce rebase yaparım, sonra main’e merge ederim, böylece hem line‑arı bir tarihçe kalır hem de merge‑conflict’ler minimal olur.

19 Eki 13:36

Branch oluştururken `git checkout -b yeni-branch origin/main` gibi bir komutla upstream’i otomatik ayarlıyoruz, peki sen rebase sonrası oluşan conflict’leri çözmek için hangi stratejiyi tercih ediyorsun, kanka? Valla merge sonrası commit grafiği nasıl görünüyor, bir bakışta farkı anlayabiliyor musun?