Masterdan yeni bir dal oluşturulur, buna
test` adını veriyoruz.
Ya master
a commit yapan ya da başka dallar oluşturup daha sonra master
ile birleştiren birkaç geliştirici var.
Diyelim ki test
üzerinde çalışmak birkaç gün sürüyor ve test
i master
içindeki taahhütlerle sürekli güncel tutmak istiyorsunuz.
Ben olsam test
ten git pull origin master
yapardım.
Soru 1: Bu doğru bir yaklaşım mı? Diğer geliştiriciler de benim çalıştığım dosyalar üzerinde kolayca çalışabilirdi.
Testüzerindeki çalışmam bitti ve onu
master` ile birleştirmeye hazırım. İşte aklıma gelen iki yol:
A:
git checkout test
git pull origin master
git push origin test
git checkout master
git pull origin test
B:
git checkout test
git pull origin master
git checkout master
git merge test
Ben --rebase
kullanmıyorum çünkü anladığım kadarıyla rebase, master
dan değişiklikleri alacak ve benimkileri bunun üzerine yığacak, dolayısıyla diğer insanların yaptığı değişikliklerin üzerine yazabilir.
Soru 2: Bu iki yöntemden hangisi doğrudur? Aralarındaki fark nedir?
Tüm bunların amacı test
dalımı master
dalında olup bitenlerle güncel tutmak ve daha sonra zaman çizelgesini mümkün olduğunca doğrusal tutmayı umarak bunları master
dalına geri birleştirmektir.
Bunu nasıl yapardım
git checkout master
git pull origin master
git merge test
git push origin master
Eğer uzaktaki bir daldan yerel bir dala sahipsem, bu dal dışındaki diğer dalları uzaktaki dalla birleştirmek konusunda kendimi rahat hissetmiyorum. Ayrıca, göndermek istediklerimden memnun olana kadar değişikliklerimi göndermezdim ve ayrıca sadece kendim ve yerel depom için olan şeyleri hiç göndermezdim. Açıklamanıza göre, test
sadece sizin için mi? Yani yayınlamak için bir neden yok.
git her zaman sizin ve başkalarının değişikliklerine saygı göstermeye çalışır ve --rebase
de öyle yapacaktır. Bunu uygun bir şekilde açıklayabileceğimi sanmıyorum, bu nedenle küçük bir açıklama için Git kitabı - Rebasing veya git-ready: Rebasing'e giriş'e bir göz atın. Bu oldukça güzel bir özellik
Bu çok pratik bir soru, ancak yukarıdaki tüm cevaplar pratik değil.
Gibi
git checkout master
git pull origin master
git merge test
git push origin master
Bu yaklaşımın iki sorunu vardır:
Bu güvenli değildir, çünkü test dalı ile ana dal arasında herhangi bir çakışma olup olmadığını bilmiyoruz.
Tüm test taahhütlerini master üzerinde tek bir birleştirme taahhüdüne sıkıştırır; yani master dalında, test dalının tüm değişiklik günlüklerini göremeyiz.
Bu nedenle, bazı çakışmalar olabileceğinden şüphelendiğimizde, aşağıdaki git işlemlerini yapabiliriz:
git checkout test
git pull
git checkout master
git pull
git merge --no-ff --no-commit test
Committen önce
mergei test edin,
--no-ffile hızlı ileri commit
ten kaçının,
Çakışmayla karşılaşılırsa, çakışmalarla ilgili ayrıntıları kontrol etmek ve çözmeye çalışmak için git status
çalıştırabiliriz
git status
Çatışmaları çözdükten sonra veya herhangi bir çatışma yoksa, onları commit
ve push
ederiz
git commit -m 'merge test branch'
git push
Ancak bu yol, test dalında kaydedilen değişiklik geçmişini kaybedecek ve ana dalın diğer geliştiriciler için projenin geçmişini anlamasını zorlaştıracaktır.
Bu yüzden en iyi yöntem merge
yerine rebase
kullanmaktır (bu süre içinde dal çakışmalarını çözdüğümüzü varsayalım).
Aşağıda basit bir örnek verilmiştir, gelişmiş işlemler için lütfen http://git-scm.com/book/en/v2/Git-Branching-Rebasing adresine bakın
git checkout master
git pull
git checkout test
git pull
git rebase -i master
git checkout master
git merge test
Evet, üst kısımları tamamladığınızda, tüm Test dalı'nın taahhütleri Ana dalın başına taşınacaktır. Rebasing'in en büyük yararı, doğrusal ve çok daha temiz bir proje geçmişi elde etmenizdir.
Kaçınmanız gereken tek şey şudur: master branch gibi public branch üzerinde asla rebase
kullanmayın.
Aşağıdaki gibi işlemleri asla yapmayın:
git checkout master
git rebase -i test
Ayrıntılar için https://www.atlassian.com/git/tutorials/merging-vs-rebasing/the-golden-rule-of-rebasing
Ekler:
Ne rebase ne de merge herhangi birinin değişikliklerinin üzerine yazmamalıdır (bir çakışmayı çözerken bunu yapmayı seçmediğiniz sürece).
Geliştirme sırasında olağan yaklaşım şudur
git checkout master
git pull
git checkout test
git log master.. # if you're curious
git merge origin/test # to update your local test from the fetch in the pull earlier
Master ile tekrar birleştirmeye hazır olduğunuzda,
git checkout master
git log ..test # if you're curious
git merge test
git push
Birleştirme sırasında bir şeyleri kırmaktan endişe ediyorsanız, git merge --abort
sizin için var.
Birleştirme aracı olarak önce itme sonra çekme yöntemini kullanmak aptalcadır. Ayrıca testi neden origin'e ittiğinizden de emin değilim.