Neden isteklerini yerine getirdiğim her ciddi Github deposu, taahhütlerimi tek bir taahhütte ezmemi istiyor?

Git günlüğünün orada olduğunu düşündüm, böylece tüm geçmişinizi kontrol edebiliyor ve tam olarak hangi değişikliklerin gerçekleştiğini görebiliyorsunuz. Amaç ne?

Bu aynı zamanda “erken ve sık işlenen” mantralarına aykırı görünüyor.

Böylece yapılan değişiklikleri ve nedenlerini açık ve kolay bir şekilde belgeleyen açık ve öz bir git geçmişine sahip olursunuz.

Örneğin, benim için tipik bir 'unquashed' git günlüğü aşağıdaki gibi görünebilir:

7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
787g8fgf78... hotfix for #5849564648
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Ne dağınıklık!

Daha dikkatli bir şekilde yönetilen ve birleştirilmiş bir git günlüğü ile ilgili olarak, mesajlara biraz odaklanarak şöyle görünebilir:

7hgf8978g9... 8483948393 Added new slideshow feature
787g8fgf78... 5849564648 Hotfix for android display issue
9080gf6567... 6589685988 Implemented pop-up to select language

Bence genel olarak squashing işinin amacını görebiliyorsunuz ve aynı prensip çekme talepleri için de geçerli - Tarihin Okunabilirliği. Ayrıca zaten yüzlerce hatta binlerce taahhüt olan bir işlem günlüğüne ekliyor olabilirsiniz ve bu, büyüyen tarihin kısa ve özlü kalmasına yardımcı olacaktır.

Erken ve sık taahhüt etmek istiyorsun. Birçok nedenden ötürü en iyi uygulamadır. Bunun beni sık sık "silme" (devam etmekte olan çalışma) veya "bölüm A" veya "yazım hatası, küçük düzeltmeler" gibi işler yapmamda ve çalışmamda bana yardımcı olmak için git kullanıyorum İşlerin yürümesi için ilerlerken aşağıdaki kod çalışmıyorsa geri dönebilirim. Bununla birlikte, bu tarihe son git tarihinin bir parçası olarak ihtiyacım yok ya da istemiyorum, bu yüzden taahhütlerimi bastırabilirim - ancak bunun bir kalkınma dalındaki usta ile ne anlama geldiğiyle ilgili notları görün.

Farklı çalışma aşamalarını temsil eden önemli kilometre taşları varsa, özellik / görev / hata başına birden fazla işlem yapmak hâlâ tamam. Bununla birlikte, bu genellikle geliştirilmekte olan biletin 'çok büyük' ​​olduğu gerçeğini vurgulayabilir ve örneğin bağımsız olabilen daha küçük parçalara bölünmesi gerekir.

8754390gf87... Implement feature switches

"1 iş parçası" gibi görünüyor. Ya varlar ya da yoklar! Onu parçalamak mantıklı gelmiyor. Bununla birlikte, deneyim bana (örgütsel büyüklüğe ve karmaşıklığa bağlı olarak) daha ayrıntılı bir yol olabileceğini göstermiştir:

fgfd7897899... Add field to database, add indexes and a trigger for the dw group
9458947548g... Add 'backend' code in controller for when id is passed in url.
6256ac24426... Add 'backend' code to make field available for views.
402c476edf6... Add feature to UI

Küçük parçalar daha kolay kod incelemeleri, daha kolay birim testleri, qa için daha iyi fırsat, Tek Sorumluluk İlkesine daha iyi uyum, vb. Anlamına gelir.

Bu tür squashların ne zaman yapılacağına dair pratikler için, temel olarak kendi iş akışına sahip iki farklı aşama vardır.

• gelişiminiz, örneğin çekme istekleri
• işiniz ana dalına eklendi, örneğin ana

Gelişiminiz sırasında 'erken ve sıklıkla' ve hızlı 'tek kullanımlık' mesajlar atarsınız. Bazen burada ezmek isteyebilirsiniz, örneğin silme ve silme mesajı gönderme. Şube içinde, gelişimde attığınız farklı adımları temsil eden birden fazla taahhüt tutmak iyidir. Seçtiğiniz kabakların çoğu, bu özellik dallarında, geliştirilirken ve bir araya gelmeden önce ustalaşmadan önce olmalıdır.
Ana hat dalına eklerken, varolan ana hat geçmişine göre özlü ve doğru bir şekilde biçimlendirilmesini taahhüt eder. Bu, Ticket Tracker sistem kimliğini içerebilir, örn. Örneklerde gösterildiği gibi JIRA. Usta üzerine birkaç farklı komisyonu 'almak' istemediğiniz sürece, squashing gerçekten de geçerli değil. Normalde yapmazsın.

--no-ffMaster ile birleştirme yaparken kullanmak birleştirme için bir taahhüt kullanacak ve aynı zamanda (dalda) tarihi koruyacaktır. Bazı kuruluşlar bunun en iyi uygulama olduğunu düşünüyor. Daha fazla gör https://stackoverflow.com/q/9069061/631619 Ayrıca pratik etkisini göreceksiniz git logbir yerde --no-ff(sadece yapıldığında) olmadan oysa BAŞ üstündeki son taahhüt olacaktır taahhüt --no-ffolması olabilir Tarihlere ve diğer taahhütlere bağlı olarak tarihte daha da ileri.

Sık sık PR çeken kişi, "temel şablonlar, hata düzeltme işlevi X, Y işlevi ekle, yorumlarda sabit yazım hataları, düzeltilmiş veri ölçekleme parametreleri" değil, daha iyi bir performans sergileyen "X özelliği eklenmiş" özelliklerinin taahhütlerinin net etkisini önemser. liste "... ayrıntı düzeyi

16 taahhüdünüzün en iyi 1 "Eklenen özellik X, Z'yi X kullanarak yeniden adlandırmak" yerine 2 komisyonla temsil edildiğini düşünüyorsanız, o zaman muhtemelen 2 komisyon ile bir pr önermek iyi olur, ancak sonra önermek en iyisi olabilir Bu durumda 2 ayrı pr (repo hala tek taahhüt pr'lerde ısrar ederse)

Bu, "erken işlem yapın ve sık davranın" mantığına karşı gelmez, repo'nuzda olduğu gibi, hala ayrıntılı ayrıntılara sahip olursunuz, bu nedenle işinizi kaybetme şansınız çok azdır ve diğer insanlar gözden geçirebilir / çekebilir / teklif edebilir Yeni pr geliştirilirken pr, işinize karşı.

Görebildiğim şeyin asıl nedeni şöyle:

• Çekme isteklerini şu anda birleştirmek için GitHub UI (Ekim 2015) taahhüt iletisinin ilk satırını düzenlemenize izin vermez, Merge pull request #123 from joebloggs/fix-snafoo
• Taahhüt Tarama geçmişini için GitHub UI şu anda gelen şube geçmişini görüntülemek için izin vermez --first-parentbakış açısından
• Şu anda bir dosyadaki suçlamaya bakmak için GitHub UI, dosyanın suçunu bakış açısıyla görüntülemenize izin vermiyor --first-parent(bunun yalnızca Git 2.6.2'de düzeltildiğini unutmayın; mevcut)

Dolayısıyla yukarıdaki bu üç durumun hepsini birleştirdiğinizde, birleştirilmemiş taahhütlerin birleştirilmesinin GitHub UI'den çirkin göründüğü bir durum elde edersiniz.

Sıkıştırılmış taahhütler ile geçmişiniz gibi görünecek

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... Hotfix for android display issue
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... Implemented pop-up to select language

Oysa squashed olmadan tarih gibi bir şey görünecek

1256556316... Merge pull request #423 from jrandom/add-slideshows
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... Merge pull request #324 from ahacker/fix-android-display
787g8fgf78... hotfix for #5849564648
f56556316e... Merge pull request #28 from somwhere/select-lang-popup
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

GitHub UI'yı kullanmakla sınırlandırırsanız , bir değişimin gerçekleştiği PR izlemesinde çok fazla taahhütte bulunduğunuzda, biraz kabusa dönüşebilir .

Örneğin, bir dosyada bir yerde de-referans olarak gösterilen boş bir işaretçi buluyorsunuz ... bu yüzden "bunu kim yaptı ve ne zaman? Hangi sürümleri etkilenir?" Diyorsunuz. Sonra GitHub UI'deki suçlama görünümüne doğru ilerlersiniz ve çizginin değişmiş olduğunu görürsünüz.789fdfffdf... "ah, ama bir saniye bekle, bu satır sadece kodun geri kalanına uyacak şekilde girintisini değiştiriyordu", bu yüzden şimdi üst taahhütte bulunan dosya için ağaç durumuna gitmeli ve tekrar ziyaret etmelisin. suçlama sayfası ... sonunda bir taahhüt buluyorsun ... bu 6 ay öncesinden bir taahhüt ... "oh **** bu kullanıcıları 6 ay boyunca etkileyebilir" diyorsun ... ah ama bekle, bu taahhüt aslında bir Çekme İsteği’ndeydi ve yalnızca dün birleşti ve henüz kimse serbest bırakmadı ... “Tarihinizi ezmeksizin işlerinizi birleştiren insanları lanetliyorsunuz”, genellikle 2 veya 3 kod arkeoloji seferinden sonra duyulabilecek bir çığlık GitHub UI

Şimdi (için düzeltme vardır ve süper müthiş 2.6.2 Git komut satırını kullanın varsa bize bunun nasıl çalıştığını düşünelim git blame --first-parent)

• Git komut satırını kullanıyor olsaydınız, birleştirme işlemi iletisini tamamen denetleyebilirsiniz ve böylece birleştirme işlemi güzel bir özet çizgisine sahip olabilirdi.

Bu yüzden bizim taahhüt tarihimiz benzeyecek

$ git log
1256556316... #423 Added new slideshow feature
7hgf8978g9... Added new slideshow feature, JIRA # 848394839
85493g2458... Fixed slideshow display issue in ie
gh354354gh... wip, done for the week
789fdfffdf... minor alignment issue
56556316ad... #324 Hotfix for android display issue
787g8fgf78... hotfix for #5849564648
f56556316e... #28 Implemented pop-up to select language
9080gf6567... implemented feature # 65896859
gh34839843... minor fix (typo) for 3rd test

Ama biz de yapabiliriz

$ git log --first-parent
1256556316... #423 Added new slideshow feature
56556316ad... #324 Hotfix for android display issue
f56556316e... #28 Implemented pop-up to select language

(Başka bir deyişle: Git CLI pastanı almanı ve yemeni sağlar)

Şimdi boş gösterici sorununa çarptığımızda ... sadece kullandık git blame --first-parent -w dodgy-file.cve derhal boş gösterici referansının ana boşluk ile görüldüğü yerde basit beyaz boşlukları görmezden geldiğince kesin bir şekilde verildi.

Elbette GitHub UI kullanarak birleştirme yapıyorsanız, GitHub git log --first-parentbirleştirme işlem iletisinin ilk satırını zorladığınız için gerçekten berbat olur:

1256556316... Merge pull request #423 from jrandom/add-slideshows
56556316ad... Merge pull request #324 from ahacker/fix-android-display
f56556316e... Merge pull request #28 from somwhere/select-lang-popup

Böylece uzun lafın kısası:

GitHub UI (Ekim 2015), çekme taleplerini nasıl birleştirdiği, taahhüt tarihini nasıl sunacağı ve suçlama bilgilerini nasıl atfettiği konusunda bazı eksiklikler var. GitHub Kullanıcı Arabiriminde bu kusurların üstesinden gelmenin en iyi yolu, birleşme öncesinde insanlardan taahhütlerini ezmelerini talep etmektir.

Git CLI bu sorunlara sahip değil ve hangi görünümü görmek istediğinizi kolayca seçebiliyor, böylece hem belirli bir değişikliğin neden bu şekilde yapıldığını (hem de taahhüt edilmemiş taahhütlerin geçmişine bakarak) hem de nedenini keşfedebiliyorsunuz. etkili bir şekilde ezilmiş taahhütleri görün.

Komut Dosyası Gönder

Sıkıştırma taahhütleri için sıkça atıfta bulunulmasının son sebebi, sırt limanına yalnızca bir tane karar vermeniz durumunda (yani ezilmiş ürün işleme), vişnenin seçilmesi kolaydır ...

Git tarihine bakıyorsanız git log --first-parent, birleştirme işlemlerini sadece kirazdan alabilirsiniz. Çoğu insan Belirtmek zorunda çünkü karıştı kiraz toplama birleştirme taahhüt almak -m Nseçeneği ancak aralarından taahhüt var ise git log --first-parento zaman bu kadar öyle olacak takip etmek istediğiniz ilk ebeveyn olduğunu biliyoruzgit cherry-pick -m 1 ...

Bu konudaki diğer cevaplarda dile getirilen duyguları, eklenen özelliklerin ve hataların düzeltildiği konusunda net ve kısa bir tarih gösterme konusunda hemfikirim. Bununla birlikte, sorunuzun reddettiği, ancak açıkça belirtmediği başka bir konuya değinmek istiyorum. Git'in çalışma yöntemlerinden bazılarıyla ilgili olarak sahip olabileceğiniz bir kısmı, git'in, bu tür eylemlerin imkansız olduğu diğer kaynak kontrol biçimlerini kullandıktan sonra git ile tanışırken garip görünen tarihçeyi yeniden yazmanıza izin vermesidir. Ayrıca, bu aynı zamanda, genel olarak kabul edilen bir kaynak kontrol ilkesine aykırıdır; kaynak kontrolüne bir şey yapıldığında / iade edildiğinde, bu taahhüdü takiben ne gibi değişiklikler yaparsanız yapın bu duruma geri dönmeniz gerekir. Sorunuzda ima ettiğiniz gibi, bu durumlardan biridir. Git harika bir sürüm kontrol sistemi olduğunu düşünüyorum; Ancak, bunu anlamak için uygulama detaylarından bazılarını anlamanız ve arkasındaki kararları tasarlamanız gerekir ve bunun sonucunda daha dik bir öğrenme eğrisi vardır. Git'in dağıtılmış bir sürüm kontrol sistemi olması gerektiğini ve tasarımcının neden git tarihinin squash taahhütleriyle yeniden yazılmasına izin verdiğini açıklamaya yardımcı olacağını unutmayın.

Bakış açısı nedeniyle ... En iyi uygulama, <<issue-management-system>>mümkünse her bir sorun için tek bir taahhütte bulunmaktır .

Kendi özellik branşınızda / reponuzda istediğiniz kadar taahhütte bulunabilirsiniz, ancak şu an yaptığınız şeyle ilgili tarihçenizdir, SİZİN bakış açınızla ... Bundan birkaç ay sonra saklanacak bakış açısı ...

Bu nedenle, ne zaman bir hata düzeltmesi yapmak veya ortak bir repoya özellik vermek istediğinizde (bu örnek, geliştirme branşındadır) aşağıdakileri yapabilirsiniz:

özellik dalınızı hızlı bir şekilde geliştirmek için yeniden nasıl

    # set your current branch , make a backup of it , caveat minute precision
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # squash all your changes at once 
    git reset $(git merge-base develop $curr_branch)

    # check the modified files to add 
    git status

    # add the modified files dir by dir, or file by file or all as shown
    git add --all 

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # add the single message of your commit for the stuff you did 
    git commit -m "<<MY-ISSUE-ID>>: add my very important feature"

    # check once again 
    git log --format='%h %ai %an %m%m %s'  | less

    # make a backup once again , use seconds precision if you were too fast ... 
    curr_branch=$(git rev-parse --abbrev-ref HEAD); git branch "$curr_branch"--$(date "+%Y%m%d_%H%M"); git branch -a | grep $curr_branch | sort -nr

    # compare the old backup with the new backup , should not have any differences 
    git diff <<old-backup>>..<<new-backup-branch>>


    # you would have to git push force to your feature branch 
    git push --force 

Kodun herkese açık olup olmadığını göreceğim.

Projeler özel kaldığında:

Squash yapmamayı ve sosis yapımını görmemi tavsiye ederim. Eğer iyi ve küçük taahhütler kullanıyorsanız, git bisect gibi araçlar çok kullanışlı ve insanlar hızlı bir şekilde gerileme kararlarını tam olarak belirleyebiliyorlar ve neden yaptığınızı (taahhüt mesajı nedeniyle) görebiliyorlar.

Projeler halka açıldığında:

Her şeyi ezin, çünkü bazı taahhütler güvenlik kaçağı içerebilir Örneğin, taahhüt edilen ve tekrar kaldırılan bir şifre.