Kodlama ilerlemesini çok fazla ek yük olmadan anlamlı taahhütlere bölmek

Bir düzeltme veya özellik üzerinde çalışırken, bazen birkaç saniye içerisinde anında iyileştirilebilecek diğer küçük sorunların üstesinden gelebilirim. Bunları hemen yapıp bitmiş özelliği / düzeltmeyi yerine getirdiğimde, taahhüt birden fazla şeyi içeriyor. Örneğin "add feature X and code clean up"veya "fix bug X and improved logging". Bunu ikiye bölmek daha iyi olur. İki değişikliğin aynı dosyada gerçekleşmesi durumunda, sadece bir dosya ekleyemem, işleme koyamam, diğerine ekleyemem ve sonra tekrar işleme koyamam. Bu yüzden aşağıdaki üç seçeneği görüyorum:

1. Bir şey üzerinde çalışırken kasıtlı olmayan şeyleri kasten göz ardı edin.

2. Dosyayı iki değişiklikle kopyalayın, geri alın, bir değişiklik ekleyin, kesinleştirin, diğer değişikliği ekleyin, tekrar kesinleştirin.

3. Küçük, ilgisiz şeyleri değiştirmeyin, bunları yapılacaklar listesine ekleyin ve daha sonra yapın.

Aşağıdaki nedenlerden dolayı bu üç seçeneğin hepsini gerçekten sevmiyorum:

1. Küçük problemleri çözmezse kod kalitesi düşebilir. Ve çok fazla çaba harcamadan bir şeyi geliştirme şansını bilinçli olarak kaçırırsam, kendimi kötü hissediyorum.

2. Bu manuel çalışmayı arttırır ve hataya açıktır.

3. Bu çok küçük olmayan todoslar için iyidir, ancak yapılacaklar listesine küçük bir öğe eklemek ve daha sonra tekrar ziyaret etmek, onu derhal düzeltmekten çok daha uzun sürer.

Bu gibi durumları nasıl ele alıyorsunuz?

Programlama yaparken çok pratik olman gerektiğini düşünüyorum. Mükemmel şemayı, iş akışını veya uygulamayı formüle etmek mümkün olsa bile, bazen sadece işinizi yapmanız gerekir. İşte yaptığım şey:

Git'in mümkünse ilişkisiz değişiklikleri ayırmak için münferit topakları ve çizgiler oluşturma / işleme kabiliyetini kullanıyorum, ancak zaman zaman bu ayrılık düzgün yapılmadığı takdirde geçici problemler doğurabilir. Değişiklikler bitişik olacağından, CI hattınızdaki her bir bireysel değişikliği test etme politikanız yoksa, genellikle büyük bir sorun değildir.

İlişkili olmayan değişiklik çok büyük olduğunda, yapılacaklar listesine koyacağım ve genellikle aklımda iken, hemen ardından devam ettireceğim. Bazen geri dönmeden önce bir iki gün alabilir, şu anki görevime ve düşünce trenime bağlı. Arada sırada bir TODO koyacağım: Hazırda iyi bir çözüm bulamıyorsam, suçlu kodun yanına.

Her şeyi ayırmanın pratik olmadığı ve orijinal düzenlemeyle birlikte küçük düzeltmeler yapacağım.

Değişimin boyutu genellikle gidilecek rotayı seçtiğimde belirleyici faktördür, fakat sonunda bir koku bırakmak yerine iş akışı kuralını görmezden gelirdim.

Editörümde, bir dosyanın tek tek bölümlerini sıralamayı son derece kolaylaştıran bir eklenti var. Diğer programcı editörlerinin benzer eklentilere sahip olduğunu hayal ediyorum, ancak bunu her zaman manuel olarak yapabilirsiniz git add --patch | -p. Sonra diğer küçük değişikliklerden kurtulmak için küçük değişiklikler yapmadan test etmek için git stash kullanıyorum . Sonra taahhütte bulunduktan sonra, sadece yaptığım git stash popyerde kaldığım yerden devam ediyorum. Tam da bu özellikler bunun için tasarlandı.

İşin püf noktası, değişimin hak ettiği kadar çaba göstermeye hazır olmadığınız sürece değişiklik yapmamaktır.

Yapma eğilimim bir yapılacaklar listesine ekleme yapmaktır (bazen koda yorum ekleyerek, bazen bir hata biletiyle ilgili bir notta ve bazen de düzeltmenin sonunda birleştirileceğini bilen ayrı bir branşta kod güncelleyerek). Küçük kalitedeki sorunların toplanmasına yönelik herhangi bir hata bileti yoksa, bunun için özel olarak bir tane yükseltirim, bu yüzden ben ve diğer herkes şube birleştirildiğinde bu kod değişikliklerinin nedeninin ne olduğunu söyleyebilirim. Ben sadece eğlencesi için hiçbir zaman değişiklik yapmam, her şey izlenebilirlik kazanır, böylece meslektaşlarım kod değiştiğinde çok şaşırmazlar.

Yani kısacası - evet, kodlama yaparken bunları görmezden gelin. Bir özellik ekliyorsanız, ne kadar küçük olursa olsun 2 özellik eklemek için cazip olmayın. Birisi şubenizi geri almaya karar verirse (özelliğiniz artık gerekli değil, çünkü), o zaman tüm mini hata düzeltmelerinizi de kaybedeceksiniz. Benzer şekilde, doğru çalışan bazı kritik kodlarda küçük bir 'düzeltme' yapmak istemezsiniz.

Biraz kullandığım bir seçenek, TODOyorum eklemek , ardından git add --patchdosyanın ilgili bölümlerini seçmek için çok sık sık "kısmi" taahhütte bulunmak . Ardından git rebase --interactive, kısmi taahhütleri yeniden sıralamak ve birleştirmek için kullanın ve bunları zorlamadan önce düzeltmeyi taahhüt edin.

Bu, ana bağlılığınızı temiz tutar ve hemen bulduğunuz diğer sorunları gidermenizi sağlar.

git rebaseBu bağlamda, yalnızca yerel taahhütleri yeniden yazdığınız için yanlış bir şey yoktur .

Diğer bir seçenek mevcut değişikliklerinizi "git stash" yapmak olabilir. İş akışı şöyle görünür:

1. A Özelliği ile ilgili değişiklikler yapmaya başlayın
2. Hata B'yi keşfedin ve hemen düzeltmeye karar verin
3. Repo'nuzdaki komut satırından gerçekleştirin git stash (Bundan sonra, A Özelliği üzerinde çalışmaya başlamadan önce kodunuz bulunduğu duruma geri döner )
4. Bu noktada A Özelliği için kabul edilmemiş değişiklikleriniz "stash" da saklanır
5. Hata B'yi düzeltmek için gereken kod değişikliklerini yapın ve depoya geri dönüş yapın
6. Komut satırından çalıştırma git stash pop
7. A Özelliği için henüz tamamlanmayan değişiklikleriniz artık depodan atıldı ve Bug B için (önceden belirlenmiş) düzeltmenin yanı sıra devam eden kodunuza geri yüklendi

Hata düzeltmeyle ilgili değişikliklerin ayrı ayrı aşamasını yapın (ve gerçekleştirin). Git Extensions'ta bunu yapmak çok kolaydır. Komut satırından yapmanız gerektiğini düşünüyorum git add -p.