Git pull --rebase'i ne zaman kullanmalıyım?

git pull --rebaseVarsayılan olarak kullanan bazı insanlar ve asla kullanmamak için ısrar eden bazı insanlar biliyorum . Birleştirme ve yeniden basma arasındaki farkı anladığımı düşünüyorum, ama bunu bağlamına koymaya çalışıyorum git pull. Sadece birleştirme taahhüdü mesajlarını görmek istememekle mi ilgili, yoksa başka sorunlar var mı?

Ne git pull --rebasezaman kullanmalısınız?

• değişiklikleriniz ayrı bir dalı hak etmiyor

Gerçekten - neden o zaman olmasın? Daha açıktır ve taahhütlerinize mantıklı bir gruplama getirmez .

Tamam, sanırım biraz açıklığa ihtiyacı var. Git'te, muhtemelen bildiğiniz gibi, dallanıp birleştirilmeniz teşvik edilir. İçinde değişiklikler yaptığınız yerel dalınız ve uzak dal aslında farklı dallardır ve git pullbunları birleştirmekle ilgilidir. Çok sık itmediğiniz ve genellikle tamamlanmış bir özellik oluşturmadan önce bir dizi değişiklik biriktirdiğiniz için makul.

Ancak, bazen - ne sebeple olursa olsun - bu ikisinin - uzak ve yerel - bir dal olmasının daha iyi olacağını düşünüyorsunuz . SVN'de olduğu gibi. İşte burada git pull --rebasedevreye giriyor. Artık birleştirme yapmıyorsunuz - aslında uzak dalın üstündesiniz . Aslında bununla ilgili.

Tehlikeli olup olmadığı, yerel ve uzak şubeye ayrılmaz bir şey olarak davranıp davranmadığınız sorusudur. Bazen mantıklıdır (değişiklikleriniz küçük olduğunda veya güçlü bir gelişimin başlangıcındaysanız, önemli değişiklikler küçük taahhütler tarafından getirildiğinde). Bazen değildir (normalde başka bir şube oluşturduğunuzda, ancak bunu yapmak için çok tembelsiniz). Ama bu farklı bir soru.

Bazen "git pull --rebase" nin ne anlama geldiğine farklı bir bakış açısı sunmak istiyorum, çünkü bazen kayboluyor gibi görünüyor.

Subversion (veya CVS) kullandıysanız, "svn update" davranışına alışık olabilirsiniz. Değişikliklerin üst akışta yapıldığı için taahhütte değişiklikleriniz varsa ve taahhüt başarısız olursa, "svn update" (svn update). Subversion, yukarı akış değişikliklerini sizinkiyle birleştirerek, muhtemelen çatışmalara neden olarak ilerler.

Subversion'ın az önce yaptığı şey aslında "çekin - rebase" idi. Yerel değişikliklerinizi daha yeni sürüme göre yeniden formüle etme işlemi, bunun "yeniden temellendirme" bölümüdür. Başarısız tamamlama girişiminden önce "svn diff" işlemini gerçekleştirdiyseniz ve elde edilen farkı daha sonra "svn diff" çıktısıyla karşılaştırdıysanız, iki fark arasındaki fark yeniden bastırma işleminin yaptığıdır.

Bu durumda Git ve Subversion arasındaki en büyük fark, Subversion'da "sizin" değişikliklerinizin yalnızca çalışma kopyanızdaki taahhütlü olmayan değişiklikler olarak mevcut olması, Git'te ise yerel olarak gerçek taahhütlerinizin olmasıdır. Başka bir deyişle, Git'te geçmişi çatalladınız; geçmişiniz ve yukarı akış tarihiniz birbirinden ayrıldı, ancak ortak bir atalarınız var.

Benim düşünceme göre, yerel şubenizin sadece yukarı akış dalını yansıtması ve üzerinde sürekli gelişim yapması normal durumda, yapılacak doğru şey her zaman "- rebase" dir, çünkü anlamsal olarak gerçekte yaptığınız şey budur . Siz ve diğerleri, bir dalın amaçlanan doğrusal geçmişine saldırıyorsunuz. Denemenizden önce birisinin biraz itmeye başlamış olması önemsizdir ve bu tür zamanlama kazalarının her birinin tarihte birleşmelerle sonuçlanması için karşı üretken görünmektedir.

Herhangi bir nedenden ötürü bir şeyin şube olması gerektiğini düşünüyorsanız, bence bu farklı bir kaygıdır. Ancak değişikliklerinizi birleştirme biçiminde temsil etmek için özel ve aktif bir arzunuz yoksa, varsayılan davranış, bence, "git pull --rebase" olmalıdır.

Lütfen projenizin geçmişini gözlemlemesi ve anlaması gereken diğer insanları düşünün. Tarihin her yerde yüzlerce birleşmeyle dolmasını mı istiyorsunuz, yoksa sadece kasıtlı ıraksak gelişme çabalarının gerçek birleşimlerini temsil eden seçkin birkaç birleşmeyi mi istiyorsunuz?

Belki de bunu açıklamanın en iyi yolu bir örnektir:

1. Alice konu dalını A oluşturur ve üzerinde çalışır
2. Bob ilgisiz konu dalı B yaratır ve üzerinde çalışır
3. Alice yapar git checkout master && git pull. Master zaten güncel.
4. Bob biliyor git checkout master && git pull. Master zaten güncel.
5. Alice yapar git merge topic-branch-A
6. Bob yapar git merge topic-branch-B
7. Bob git push origin masterAlice'den önce yapar
8. Alice bunu git push origin masterreddediyor, çünkü bu hızlı ileri bir birleştirme değil.
9. Alice kökeni / ustanın kütüğüne bakar ve taahhüdün onunla alakasız olduğunu görür.
10. Alice yapar git pull --rebase origin master
11. Alice'in birleştirme taahhüdü çözülür, Bob'un taahhüdü çekilir ve Alice'in taahhüdü Bob'un taahhüdünden sonra uygulanır.
12. Alice yapar git push origin masterve herkes gelecekte günlüklere baktıklarında işe yaramaz birleştirme taahhüdü okumak zorunda olmadıkları için mutludur.

Birleştirilen belirli dalın örnekle alakasız olduğunu unutmayın. Bu örnekteki Master, aynı zamanda bir serbest bırakma dalı veya geliştirme dalı olabilir. Kilit nokta Alice & Bob'un yerel şubelerini aynı anda paylaşılan bir uzak şubeye birleştirmesidir.

git pull --rebaseAynı dalda başkalarıyla işbirliği yaparken kullanmanız gerektiğini düşünüyorum . İşinizde → taahhüt → iş → taahhüt döngüsünde bulunuyorsunuz ve çalışmanızı zorlamaya karar verdiğinizde, itişiniz reddediliyor, çünkü aynı dalda paralel çalışma var. Bu noktada hep bir pull --rebase. Squash kullanmıyorum (taahhütleri düzleştirmek için), ancak ekstra birleştirme taahhütlerinden kaçınmak için yeniden temellendiriyorum.

Git bilginiz arttıkça, geçmişte kullandığım diğer sürüm kontrol sistemlerinden çok daha fazla şey bulduğunuzu görüyorsunuz. Bir ton küçük birleştirme taahhüdünüz varsa, geçmişinizde gerçekleşen daha büyük resmin odağını kaybetmek kolaydır.

Bu aslında yeniden basma (*) yaptığım tek zaman ve iş akışımın geri kalanı birleştirme tabanlı. Ancak, en sık kullandığınız komisyonlar bunu yaptığı sürece, tarih sonunda çok daha iyi görünür.

(*) Bir Git kursunu öğretirken bir öğrenci beni bu konuda tutukladı. Ve bu cevabı okumuştu;) Böyle bir yeniden temellendirme de mümkündür, ancak her zaman önceden düzenlenmiş / üzerinde anlaşılmış bir sisteme göre olmalıdır ve bu nedenle "her zaman" uygulanmamalıdır. Ve o zaman genellikle ben de pull --rebaseyapmıyorum, bu da sorunun ne olduğudur;)

Bir sebebi orada hiç sanmıyorum değil kullanımına pull --rebase- Özellikle benim izin Git kod ekledik git pulldaima yukarı hareketin kaydedilmesini karşı rebase komutu.

Tarihe bakarken, özellik üzerinde çalışan adamın / gal'in senkronize etmek için ne zaman durduğunu bilmek asla ilginç değildir. Bunu yaparken adam / gal için yararlı olabilir, ama bunun reflogiçin var. Sadece herkes için gürültü katıyor.

Sadece hatırlıyorum:

• pull = getir + birleştir
• çekme - rebase = getir + rebase

Bu nedenle, şubenizi ne şekilde ele almak istediğinizi seçin.

Birleştirme ve rebase arasındaki farkı daha iyi bilirseniz :)

Bence kişisel bir tercihe bağlı.

Değişikliklerinizi zorlamadan önce saçma hatalarınızı gizlemek ister misiniz? Eğer öyleyse, git pull --rebasemükemmel. Daha sonra taahhütlerinizi birkaç (veya bir) taahhütte ezmenize izin verir. (Bilinmeyen) geçmişinizde birleşmeleriniz varsa, git rebasedaha sonra yapmak kolay değildir .

Şahsen tüm aptalca hatalarımı yayınlamam umrumda değil, bu yüzden rebase yerine birleşme eğilimindeyim.

git pull --rebasebir ortak çalışandan geçmiş yeniden yazmayı gizleyebilir git push --force. git pull --rebase Sadece bir başkasının aynısını yapmadan önce taahhütlerinizi zorlamayı unuttuğunuzu biliyorsanız kullanmanızı tavsiye ederim .

Hiçbir şey yapmadıysanız, ancak çalışma alanınız hemen git stashönce temiz değil git pull. Bu şekilde geçmişinizi sessizce yeniden yazmazsınız (bu da işlerinizin bir kısmını sessizce bırakabilir).