Git “Yeniden Yapılanmanın Altın Kuralı” çok mu gerekli?

Geçtiğimiz günlerde GIT'deki özellik branşlarının yeniden yaratılması stratejisine kesinlikle karşı çıkan insanlarla bir tartışma yaptım. Rebase'ı yalnızca yerel, özel dallar için kullanmak kabul edilmiş bir kalıp gibi gözüküyor, ancak aynı özellik ve dalda çalışan birkaç kişi varken, "Sözde Yeniden Yapılanmanın Altın Kuralı" (buradaki gibi: https) : //www.atlassian.com/git/tutorials/merging-vs-rebasing/conceptual-overview )

Bu konuda bir fikir birliği olmasına şaşırdım. 3 yıl boyunca tam bir yeniden doğuş stratejisiyle çalıştım, yaklaşık 20 geliştirici birlikte çalıştı ve ne olduğunu tahmin etti, işe yaradı.

İşlem temelde:

• Özellik dalınızı oluşturursunuz, hadi buna "özellik" diyelim ve kökene / etki alanıma itelim
• Diğer insanlar kontrol edebilir ve üzerinde çalışabilir
• Bazen onu ustadan yeniden değerlendirebilirsiniz: "myfeature" den, git rebase origin / master ; ve sonra, evet, onu zorlaman gerekiyor.
• Diğer insanlar taahhütlerini zorlamak istediğinde ne olur? Onlar sadece yeniden rebase: git rebase kökenli / myfeature . Böylece şimdi hızlı ileri sarılıyorlar ve zorlamadan zorlayabilirler.

Saygı duyulan ilk prensip , özellik branşının birine ait olmasıdır . İcra edebilen tek kişi sahibidir.

Bu yüzden itiraf ediyorum: bir itme kuvveti olduğu anda hata yapma riski vardır. Bu doğru. Ancak hatalardan kurtulmanın birçok yolu var ve gerçekten, 3 yıllık gelişimde, çok fazla zorlayıcı hata görmedim ve bu gerçekleştiğinde, her zaman gerektiği gibi düzeltmenin bir yolunu bulduk.

Peki, neden bu "Rebase'ın Altın Kuralı" bu kadar yaygın kabul görüyor? Kaçırdığım başka bir şey var mı? Minimum organizasyon gerektiriyor (her strateji bazı organizasyonlar gerektiriyor) ama işe yarıyor.

Zorla zorlama ile ilgili sorun, özellik dalınız ve yöneticinizle ilgili değildir, ancak ustanızı başkasının ustasına zorlamakla ilgili - bu senkronizasyon, değişikliklerinizle ilgili ustalarının üzerine yazacak ve ipuçlarında ne olduğunu görmezden gelecek.

Bu tehlikeyi göz önünde bulundurarak, işler batırılmadıkça ve tamamen, tamiratı etkilemek için kesinlikle kullanmanız gerekmedikçe, hiç kullanmamanız için bir neden vardır. Bir SCM sisteminin böyle bir zorla yapılması gerekmemelidir, eğer bir şey çok yanlış gittiği için yaparsa (ve bu gibi durumlarda ilk yaklaşımım yedekleri geri yüklemek ve geçmişi sağlam tutmak için işlemleri tekrarlamak olacaktır).

Öyleyse belki de soru şu ki, neden hiç isyan ediyorsun? Özellikleri ustalığa geri getirirken 'temiz' geçmiş için? Öyleyse, tamamen stilsel nedenlerden dolayı dallanma ile ilgili tüm güzel geçmişi atıyorsunuz. IMHO hızlı ileri birleştirme de en iyi uygulama değil, tüm geçmişi saklamak zorundasınız, böylece gerçekte ne yaptığını görebilecek, daha sonra sterilize edilmiş bir versiyonunu görmeyeceksiniz.

Rebase çoğunlukla kozmetik olduğunu söylediğiniz gibi, zorunlu değil. Bazen bir birleşmeden sonra çok daha basittir. Bu yüzden bazı "gerçek" bir değere sahip olabilir, ancak sadece "bazen"

Rebase'in yanlış kullanımı pahalı olabilir. Kurtarma prosedürlerini paniklemeyip aramamaya yetecek kadar bilginiz varsa, verileri kaybetme ihtimaliniz yoktur, ancak "hey, bir süre düzeltmem gereken kimse ..." deme harika değildir. Ayrıca, özellikler eklerken ya da böcekleri ezerken (ya da ailesiyle birlikte evde) araştırma kurtarma ve test etme konusunda da zaman harcamıyor.

Bu takas ile "çok az insan bir yeniden fiyatlandırma ve zorla itme" nin sonuçları çok şaşırtıcı değil.

Bazı iş akışları riski azaltabilir, örneğin “hangi dalları zorladığınızı ve hangilerini yapamayacağınızı hatırladığınız sürece” sıfıra düşürür. Gerçekte riski haklı çıkaracak kadar güvenli olabilirler, ancak millet daha büyük folklorlara dayanan seçimler yapar. Sonra tekrar gerçekte faydalar oldukça küçüktür, peki riskin ne kadar küçük olması gerekir?

Farklı bir ses eklemek için:

Evet, tanımladığınız gibi çalışıyorsanız, kullanma rebaseve zorlama ile ilgili hiçbir sorun yoktur . Kritik nokta: Takımınızda bir anlaşmanız var.

rebaseÖzel anlaşmanın olmadığı durumlar için arkadaşlar ve arkadaşlar hakkında uyarılar var. Normalde, git, örneğin hızlı ileri almayan bir itmeye izin vermeyerek sizi otomatik olarak korur. Kullanmak rebaseve zorlamak bu güvenliği geçersiz kılar. Yerinde başka bir şey varsa sorun değil.

Ekibimde, bazen tarih dağınık hale gelmişse özellik dallarını yeniden oluştururuz. Eski şubeyi sileriz ve yeni bir isimle yeni bir tane yaparız ya da sadece gayrı resmi olarak koordine ederiz (bu mümkün çünkü küçük bir ekibiz ve havuzumuzda hiç kimse çalışmıyor).

Git projesinin kendisinin de benzer bir şey yaptığını unutmayın: Düzenli olarak yeniden oluşturulan, "pu" ("önerilen güncellemeler") adlı bir entegrasyon dalına sahiptir. Bu şubenin düzenli olarak yeniden yaratıldığı ve bunun üzerine yeni çalışmalar yapmamanız gerektiği belgelenmiştir.

Bu yüzden itiraf ediyorum: bir itme kuvveti olduğu anda hata yapma riski vardır. Bu doğru. Ancak hatalardan kurtulmanın birçok yolu var ve gerçekten, 3 yıllık gelişimde, çok fazla zorlayıcı hata görmedim ve bu gerçekleştiğinde, her zaman gerektiği gibi düzeltmenin bir yolunu bulduk.

Git kullanıcılarının paylaşılabilir değişken geçmişinden kaçınmasının nedeni, bu sorunların otomatik olarak önlenmemesi veya onarılmamasıdır. Ne yaptığınızı bilmek zorundasınız ve uyuşmazsanız her şeyi elle düzeltmek zorundasınız. Tam olarak bir kişinin zorla itme yapmasına izin vermek sezgisel değildir ve Git'in dağıtık tasarımına aykırıdır. O kişi tatile çıkarsa ne olur? Şubeden geçici olarak başka biri var mı? Asıl sahibinin yaptığı her şeyi yapamayacaklarını nereden biliyorsun? Açık kaynak dünyasında, şube sahibi resmen ayrılmadan kademeli olarak topluluktan uzaklaşırsa ne olur? Şube sahipliğini bir başkasına devretmeyi bekleyen çok zaman kaybedebilirsiniz.

Ancak asıl mesele şudur: Eğer karışırsanız ve hemen farketmezseniz, eski görevliler yeterli zaman geçtikten sonra kaybolacaktır . Bu noktada, sorun çözülemez olabilir (veya yedekleme hikayenizin neye benzediğine bağlı olarak, en azından potansiyel olarak kurtarılması çok zor olabilir - Git deponuzun eski kopyalarını yedekler misiniz, yani yalnızca klonları değil mi?).

Bu, Mercurial'ın Changeset evrim çalışmasına zıt (ki şunu da belirtmeliyim ki, henüz bitmedi veya sabit değil). Değişiklikler genel olarak işaretlenmemişse, herkes istediği tarihte istediği değişiklikleri yapabilir. Bu değişiklik ve yeniden indirim işlemleri bir şube sahibine ihtiyaç duyulmaksızın tamamen cezasızlıkla itilip çekilebilir. Hiçbir veri silinmez; tüm yerel veri havuzu sadece ekleme amaçlıdır. Artık ihtiyaç duyulmayan değişiklik kümeleri eski olarak işaretlendi, ancak süresiz tutuldu. Son olarak, tarihinizi mahvettiğinizde (günlük iş akışınızın normal bir parçası olarak kabul edilir), sizin için otomatik olarak temizlemek için şık bir komut vardır. Bu , UX çalışanlarının paylaşılan tarihi değiştirmeden önce bekledikleri tür.