Gitflow kullanırken temiz bir git geçmişi tutma - geliştirmede birleştirilmemiş taahhütler

Bir oluştururken, gitflow kullanarak release-1.0.0şube ve hem de birleştirme masterve developher iki dalları bir taahhüt eksik sahip olacaktır:

masterrelease-1.0.0birleşme yeri nerede olmayacakdevelop
developrelease-1.0.0birleşme yeri nerede olmayacakmaster

Bunun yerine, sonra hotfix-1.0.1yaratılır ve birleştirilmiş masterbunun için birleşti edilirken, develop, birleştirme için kaydedilmesini kesinleştirme nereye önceki içerecektir release-1.0.0çatısı altına girmiştir master; böylece şöyle görünecek:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Bu sesler kafa karıştırıcı, kolayca gördüğünüz bu everytie fark edebilirsiniz developgenellikle arkasında kaydedilmesini bir çift master(olsa bile geliştirmek, teorik olarak gereken sadece ana dal beri önde olmak. Bu hareketin kaydedilmesini gelen birleştirmeleri vardır release-x.x.xiçin master).

Temiz bir geçmişi korumak için bu nasıl ele alınmalıdır?

git gitflow

— Christopher Francisco
kaynak

Lütfen "temiz geçmişi" tanımlayın.

— Jace Browning

Temiz bir geçmiş ister misiniz? Gitflow kullanmayın. Tanımı gereği tarihinizi kirletir. Bunun yerine, gerçekten neye ihtiyacınız olduğunu düşünün ve bunun etrafında bir iş akışı oluşturun, böylece aslında nasıl çalışmak istediğinize uyuyor.

— FP

Master birleştirme bir "kopya" olacak, geliştirmek için birleştirmek gerek. Ana sürümden değil, önceki sürüm dalından düzeltmeler yapın ve her ikisinden de birleştirin, sorun yaşamayacaksınız. Master, modele fazla bir şey eklemiyor, bu yüzden onu tamamen bırakabilirsiniz, IMO.

— axl

@axl Ne demek istediğinizi anlıyorum, ama gitflow'u belgelerine olabildiğince yakın takip etmeye çalışıyorum. Herhangi bir "hackz" yapmamayı tercih ederim, çünkü gitflow birçok geliştirici tarafından zaten benimsendiğinden, bu basit şey için zaten bir çözümleri olmalı

— Christopher Francisco

GitHub ve diğer yerlerde GitFlow ile ilgili çeşitli sorunların nasıl çözüleceği hakkında birkaç tartışma var. Bazen gümüş bir kurşun yoktur.

— axl

Bence iyi bir yaklaşım, iki "ana" daldan kaçınmaktır. Bu iyice anlatılmış burada markalı, cactus-flowyazar tarafından.

Git akışının aksine bazı noktalar öne çıkıyor:

Sadece bir ana şube
Yalnızca ileri sarma birleştirmeleri

Benim için sonuncusu önemlidir, çünkü git-flow'u uzun süre kullandıktan sonra henüz --no-ffbirleşme hakkında neyin yararlı olduğunu göremiyorum .

Gitflow'u belgelerine mümkün olduğunca yakın takip etmeye çalışıyorum. Herhangi bir "hackz" yapmamayı tercih ederim çünkü gitflow birçok geliştirici tarafından zaten benimsendiğinden, bu basit şey için zaten bir çözümleri olmalı

IMHO bu senin büyük hatan. Mümkün olduğunca git-flow'a bağlı kalmanız için bir neden yok. Binlerce projede kullanılabilir, ancak bu sizinkini etkilemez, iyi yapmaz.

Git-flow iyi bir başlangıç noktasıdır, ancak onu tersine değil, araçlarınıza ve iş akışınıza uyarlamayı düşünmelisiniz.

— Sergio Basurco
kaynak