Git: Merging vs. Rebasing

İki branch'den oluşan örnek başlangıç durumu

Merge, iki farklı bir branch arasında değişiklikleri aktarmak için en güvenli ve en sık kullanılan yöntemdir. Neden güvenli çünkü merge işleminde tarihcesinde görünmektedir ve zaman çizelgesinde herhangi bir değisiklik yapmamaktadır. Merge yapıldığında da ayrı bir commit olarak görünmektedir. Ancak bu durumun bir dezavantajıda bulumaktadır. Kalabalık ekiplerde commit mesajlarının sayısının artmasına neden olmaktadır.

Merge işlemi yapıldıktan sonraki durum

Rebase'de ise bu durum farklıdır. birleştirme işlemlerinde ayrı bir commit oluşmaz ve timeline içinde de değişiklik olmuş olur. Bu nedenle rebase yaparken merge'e göre daha dikkatli olmak gerekmektedir.  Ekibin çalıştıgı mevcuttaki projede değişiklikleri yönetmek zor olacaktır. Aşağıdaki görselde şematik olarak rebase işlemi gösterilmiştir. Merge ile arasındaki fark gösterilmiştir.

Merge yerine Rebase işlemi sonrasındaki durum

Kullanımı daha iyi anlaşılması için örnek vermek gerekirse, proje üzerindeki çalışmamızı feature ismindeki bir branch de yapıyor olalım ve main branch'den türetmiş olalım. Biz çalışmaya devam ederken diğer developer arkadaş kendi branch'lerinde çalışmasını tamamlamış olup Pull Request (PR) ile main branch'e merge yapmış olsun. Bu durumda bizde conflictleri önlemek için main projesinin son halini çekmek isteyelim bu işlemi merge ile alabiliriz ancak bu sefer merge commiti oluşacaktır. Bu durum yanlış değildir sadece tercih meselesidir. Bu durumda Rebase de kullanabilirdik. Böylece merge commit mesaji tarihçede görülmeyecektir. Rebase işlemi sonucunda conflict giderildikten sonra main branch'e PR açılabilir. Projede sadece PR işlemlerinde merge commitleri tarihçede görülmüş olur.


Merge ve Rebase için daha ayrıntılı bir kaynak paylaşıyorum.

Merging vs. Rebasing | Atlassian Git Tutorial
Compare git rebase with the related git merge command and identify all of the potential opportunities to incorporate rebasing into the typical Git workflow