Sürüm tarihi gerçekten kutsal mı yoksa yeniden inşası daha mı iyi?

Mercurial'ın mantra ^1'i ile her zaman aynı fikirdeyim , ancak, şimdi Mercurial rebase eklentisi ile birlikte geliyor ve artık popüler bir uygulama. Acaba gerçekten "kötü bir uygulama" olarak mı görülebilir, yoksa en azından kullanmaktan kaçınmak için yeterince kötü. Her halükarda, bastırdıktan sonra tehlikeli olabileceğinin farkındayım.

OTOH, 5 şirketi bir arada tutmaya çalıştığını (özellikle bir üretim dalında) daha sıkı görünmesi için tek bir pakette tutmaya çalıştığımı görüyorum. Bu kadar şık olmasa bile, "X'e göre denemeye çalışıyorum ama Y kadar optimal değil, Z'yi Y alarak üs olarak yapmak" gibi bir şey görmek deneme yapmaktaydı. Kod temeli ve geliştiricilerin düşünce trenini takip edin.

Benim düşünceme göre (aptal, visseral, yanlı) bakış açım, programcıların hataları gizlemek için yeniden yapılanma gibi olduğunu ... ve bunun proje için iyi olduğunu sanmıyorum.

Öyleyse sorum şu: pratikte bu tür "organik taahhütler" (yani tarihi geçmişsiz) olduğu için gerçekten değerli bulmuş muydunuz ya da tam tersi, iyi düzenlenmiş taahhütlere girmeyi ve programcıların deneme sürecini göz ardı etmeyi mi tercih edersiniz ?; Hangisini seçerseniz seçin, neden sizin için çalışıyor? (diğer ekip üyelerinin geçmişi sürdürmesi veya alternatif olarak yeniden düzenlemesi gerekir).

Google DVCS analizi başına ^{1 adet} , Mercurial "Tarih Kutsaldır".

Tarih , kutsaldır Mevcut değil. DVCS "ağaç" ınızı iki bölüme ayırabilirsiniz:

• Geçtiğimiz kod mevcut durumunu nasıl ulaştığını doğru bir görünümü içeren / tarih. Tarihin bu kısmı zamanla büyüyor

• Mevcut şu anda üzerinde çalıştıkları bölüm size kod gelişmeye yapmak. Tarihin çoğu bölümünde bu ipucu her zaman aynı boyutta.

Bıraktığınız veya bir şekilde kullandığınız her kod geçmişte kaldı . Geçmiş kutsaldır, çünkü bir düzeni yeniden oluşturabilmeniz veya bir regresyonun neyi getirdiğini anlamanız gerekir. Asla geçmişi asla yeniden yazmayacaksın . Git'te genellikle bir kez usta olunca hiçbir şeyi tekrar yazmazsınız: Usta tarihin geçmiş kısmıdır. Mercurial'da “ağacınızın” geçmiş kısmını takip eden ve değişmezliğini uygulayan bu genel aşama konseptine sahipsiniz .

Mevcut kod parçası şu anda üzerinde çalışıyoruz değişiklik kümesi vardır. Kullanılabilir, hatasız ve uygun şekilde düzeltilmiş hale getirmeye çalıştığınız özellik dalı. Geçmişini daha güzel, basit ve kullanışlı hale getirdiği için yeniden yazmak bile iyi bir fikirdir . Mercurial bunu taslak aşamasında takip ediyor .

Öyleyse evet, lütfen geçmişinizi iyileştirirse yeniden fiyatlandırın. Mercurial, yapmamanız gereken şeyleri yeniden doğuracaksanız kendinizi ayağınıza vurmanızı engelleyecektir .

Tüm hatalar gizlemeniz gereken türden değildir - örneğin, bir keresinde yanlışlıkla repoma ikili bir dosya işledim. Geçmişe müdahale etmek, yalnızca hata kendisinin değil, tarihin kendisinde olmadığında, olması gerekmeyen dosyalarda olduğu gibi kötüdür.

Kod incelemesi, çok sayıda küçük bağımlı olanın aksine büyük bir uyumlu değişiklik olduğunda çok daha kolaydır.

Yeni bir özellik üzerinde çalışırken, şubemde çok küçük değişiklikler yapmayı seviyorum. Düzeltme ekini göndermeye hazır olduğumda, bu küçük taahhütleri o özellik için gereken tüm yeni kodu temsil eden büyük bir taahhütte çökertirim. İşte rebase kullanışlı geliyor.

Öte yandan, komisyonların birbirleriyle hiçbir ilgisi yoksa yeniden yapılanma tavsiye edilmez. Birden fazla özellik ilavesi ayrı taahhütler olmalıdır (ve ideal olarak ayrı dallardan gelir).

Sorunuz, tarihi bir sıralı kod değişikliği kümesi olarak açıklar ve organiklerin gelecekteki okuyucuları geliştirme süreci için ipucu haline getirip getirmediğini sorar. Yine de bir serbest bırakma / entegrasyon mühendisi olarak, tarihi çoğunlukla kod olarak düşünmüyorum. Tarihimin anlattığı hikâyeye, sahip olduğu kurumsal bilgiyi ve sorunları çabucak hata ayıklamama izin verip vermediğime daha çok ilgi duyuyorum.

Organik iş akışlarının bunu kendi başlarına bile iyi yaptıklarını sanmıyorum. Kodlama yaparken DVCS için değer verdiğim nitelikler - ucuz şubeler, hızlı taahhütler, uzaktan kumandaya erken ve sık tasarruf - şirketimin entegrasyon yöneticisi olarak değer verdiğim şey değil . Ben sorunu git rebase, git merge, git diff, ve git applyçok daha sık bu rolü git addveya git commit. Gibi araçlar rebase, çalışan bir şeyden verdiğim kodu, korunabilecek bir şeye dönüştürmeme izin veriyor.

Mantıksız veya belirsiz taahhütler işe yaramaz, ancak asıl mesele kodu başkalarına vermeyecek şekilde kodlarken, organik olarak yazmaları günahkârdır. Kesinleştirmeler gibi Case 15: Fixed a problemveya Refactored <cranky legacy feature>bunları yazar bile benim bakım öz yalakalık yapmak. Ancak, hiçbiri "artımlı" taahhütlerde olduğu gibi karartma öfkesini uyarmaz. Bir geliştiricinin geçen gün bana verdiği bu konu dalını göz önünde bulundurun:

$ git log production..topic --oneline
f9a1184 incremental update
156d299 incremental commits
e8d50b0 new incremental updates
511c18c incremental updates, refactor
1b46217 incremental upgrade
9e2b3b8 incremental update
fa68a87 incremental update

Bu şeyler Evil. Faustus için tasarlanmış DVCS gibi. Size hızlı ve kolay kaynak kontrolü vereceğim. Bana verdiğin kod koruyucunun ruhu. Bütün tembel taahhütler bencilce davranışlardır. Birçoğumuz onları yazıyoruz, ancak geleceğimizi kendimize mantıklı, tekrarlanabilir, hata ayıklanabilir bir tarih borçluyuz. Bunu bir yol olmadan yapamayız rebase.

Başarısız deneylere gelince, neden onları (yeni bozulmamış) taahhüt mesajlarımızda tarif etmiyorsunuz? Bir yıl sonra yarı bitmiş bir snippet'e ihtiyacım yok. Sadece iptal edilen girişimin bir kaydını istiyorum ve tekrar denemek için yeterince aptal olduğumu düşünüyorsanız, belki de kısa bir açıklama istiyorum. Dünyada birçok başarılı iş akışı var, ama bilerek bir üretim kod tabanına bilerek bozuk kod işlemek için herhangi bir neden düşünmek için mücadele ediyorum.

Hiçbir şey kutsal olmamalı, fakat yaptığınız şey için iyi sebepler olduğundan emin olun. Yeniden yapılanma, doğru kullanıldığında son derece güçlüdür, ancak herhangi bir güçlü alette olduğu gibi, kafa karıştırıcı olabilir ve dikkatsizce kullanılırsa sorunlara neden olabilir.

Şahsen, son testleri yapmadan ve özelliği ana dalda birleştirmeden önce yerel bir özellik dalının ana gövdeye (veya ana gelişim dalına) karşı yeniden inşa edilmesini çok faydalı buluyorum. Bu şekilde, birleşmeden önce herhangi bir birleşme çatışmasıyla başa çıkabiliyorum.

IMHO, deneyler genellikle bazeline değil raflara veya geçici dallara aittir. Bunu izlerseniz, tüm taahhütlerin mantıksal olarak sağlam olacağı ve bir miktar değer katacağı için bir sorun olmamalıdır.