Git - Doğrudan ustada çalışmaktan kaynaklanan sorunlar?

25

Git dallanma modelleri hakkında birçok tavsiye gördüm ve en yaygın fikir, doğrudan ana dalda değişiklik yapmanın kötü bir fikir olduğu görünüyor.

İş arkadaşlarımızdan biri doğrudan ana dalda değişiklik yapmaktan oldukça mutlu ve birkaç sohbete rağmen, bunu değiştirebilecek gibi görünmüyor.

Bu zamanda, doğrudan usta üzerinde çalışmak için kötü bir uygulama olan bir iş arkadaşını ikna edemiyorum, ancak çalışma biçimiyle çelişecek şeyleri anlamak, ne zaman tekrar gözden geçirmem gerektiğini bilmek istiyorum. bu konu.

— linuxunil
kaynak

2

"Doğrudan çalışmayı" tanımlayın. Efendi var, çünkü kullanılması gerekiyordu. Sence ne için, ne için değil?

— candied_orange

3

Efendiden çalışmak senin için mi çalışıyor? Öyleyse, neden şu anda değişme gereğini hissediyorsunuz? Çalışmıyorsa, hangi sorunları yaşıyorsunuz? İnsanlardan sizi diğer insanların tartışmalarına yönlendirmelerini istemek yerine, sorunlarınızı çözmenize yardımcı olabiliriz.

— Thomas Owens

1

Sürekli bir entegrasyonla birlikte Çevik bir ekipte oldukça normal olan gövde gelişimi yapıyor gibi görünüyor. Böyle çalışmak istiyorsa, bir kerede bir üründe hiçbir zaman çok fazla çalışma yapılmadığından emin olmak için WIP'i zorlamanız gerekir - ayrıca, ustanın eksik özellikler kapalıyken serbest bırakılmasını sağlamak için özellik değiştirme özelliğini kullanın.

— Bay Cochese,

... takım ne kadar büyük?

— ZJR

@ MrCochese Ben burada "normal" anlamda gövde gelişimi demezdim. Elbette Git'i kullandığım pek çok yerden hiçbiri bu şekilde çalışmamıştı ve ben bunu caydırırım. Özellik dalları sadece daha iyi çalışır.

— Marnen Laibow-Koser

57

Taahhütler doğrudan ustaya itildiğinde birkaç sorun var

Devam eden bir çalışma durumunu uzaktan kumandaya zorlarsanız, master potansiyel olarak bozuluyor
Başka bir geliştirici master'dan yeni bir özellik için çalışmaya başlarsa, potansiyel olarak bozuk bir durumla başlar. Bu gelişme yavaşlıyor
Farklı özellikler / hata düzeltmeleri yalıtılmaz, böylece devam eden tüm geliştirme görevlerinin karmaşıklığı tek bir dalda birleştirilir. Bu, tüm geliştiriciler arasında gerekli iletişim miktarını artırır.
Kod incelemeleri için çok iyi bir mekanizma olan istekleri çekemezsiniz
Diğer geliştiriciler bu arada ana şubeyi çoktan çekmiş olabileceğinden, genel olarak git tarihini taahhüt edemez / değiştiremezsiniz.

— Gernot
kaynak

11

Hey, bak! Aslında, aslında herkesin aksine soruyu cevapladınız. ++ SE.SE'ye Hoşgeldiniz!

— RubberDuck,

Bunların çoğu, doğrudan efendide doğrudan çalışmaktan değil, doğrudan efendide çalışmaktan kaynaklanan problemlerdir .

— Ant P

1

@AntP sizin açınızdan hangi sorunları önleyebilir?

— Gernot

10

Ona, yeni özelliklerin , üretime itilmeden önce bir test ortamına yerleştirilebilecek kendi geliştirme kollarına ihtiyaç duyduklarını açıklayın .

Aksi takdirde, yarı yarıya tamamlanmış özelliklerin sürekli bir durumundasınız demektir. Yarı tamamlanmış özellikleri üretime dağıtamazsınız, bu nedenle doğrudan ana dalda çalışıyorsanız, hata düzeltmeleri de dahil olmak üzere başka birinin değişikliklerinin üretime geçebilmesi için herkesin özelliklerinizi bitirmesini beklemesi gerekir.

Özellikler için bağımsız dallar kullanmak, her yeni özelliğin diğerlerinden bağımsız olarak test edilip dağıtılabileceği anlamına gelir.

— Robert Harvey
kaynak

"Yarı tamamlanmış özellikleri üretime dağıtamazsınız" - bu kesinlikle doğru değil - doğrudan ana şubede çalışmak, kodları teslim etmek, sık sık "yarı tamamlanmış özellikleri dağıtmak" ve hiçbir şeyi bozmamak tamamen mümkün . Sürekli teslimat, tam olarak bunu yapmakla ilgilidir: yayılmasından dağıtımın ayrılması. Bu aynı zamanda insanların normalde yarı-kırık teknik çözümlerle ele aldıkları birçok başka örgütsel problemi de çözmektedir. Bu bazen özellik geçişlerini içerir, ancak genellikle herhangi bir özelliğin% 90'ını görünür davranış değişikliği olmadan oluşturmak ve uygulamak mümkündür.

— Ant P,

@AntP: Tanımladığınız işlem benim "yarı tamamlanmış özellikler" dediğim şey değil. Bu tür özellikler ya üretime hazır ve kullanılabilir, test edilir, ya da bir özellik anahtar veya bunlar gibi zamana kadar benzer bir şey tarafından Gizlendiklerinde edilir , üretime hazır ve kullanılabilir test etti. İşe yaramayan özellikler göndermiyorsunuz.

— Robert Harvey,

Master olmayan branşlarda yeni özelliklerin geliştirilmesi gerektiğini iddia ettiniz, çünkü yarı mamulleri dağıtamazsınız: durum böyle değil. Yeni özellikleri doğrudan ana cihaz üzerinde geliştirebilir ve bu özelliklerle ilgili tüm kodları, özellik tamamlanmadan ve başka bir geliştirme yapmadan üretime alabilirsiniz.

— Ant P,

1

@AntP: Branşlarda özellik taşıyan tek şey tekniğinizin sağlayamadığı şey, belirli bir özellik üzerinde yapılan işlerin eksiksiz bir şekilde hesaplanmasıdır. Bazı dükkanlarda (özellikle benimki) bu tür bir hesap verebilirlik lüks değil, bir gerekliliktir.

— Robert Harvey

1

@AntP Sizi doğru anlarsam, bunun geriye doğru bir adım olduğunu düşünürdüm. İyi sorun izleyicilere bayılıyorum ve bunları yoğun bir şekilde kullanıyorum, ancak VCS'nin bana herhangi bir özelliğin veya kod satırının gelişim tarihini anlatmasını istiyorum . Sorun izci bir değişimin iş tarafının hikayesini anlatabilir , ancak VCS kodu kendi başıma izlememe ve denetlememe yardımcı olamıyorsa , bu işini yapmıyor. Bu, gövde temelli gelişime itiraz etmemin bir nedenidir: VCS'yi aptallaştırıyor, görebildiğim hiçbir telafi edici avantaj yok. (? Ayrıca: kırılgan birleştirme bir özelliği olan bir kod değişimi.)

— Marnen Laibow-Koser

2

Master potansiyel olarak serbest bırakılabilir olmalıdır. Dönemi. Master'da hiç bitmemiş iş olmamalıdır (bir özellik işaretiyle engellenmediği sürece)

Bununla birlikte bazı ekiplerin akışlarını zorlaştırdığını gördüm.

Master'a entegrasyon sırasında PR kullanmamak bir hatadır çünkü geliştiricilerin entegrasyon gerçekleştiğinde seçme gücü yoktur.

Tek bir geliştirme dalı çok az değer getiriyor. Genellikle sadece işleri karmaşıklaştırır. Birçok özellik dalı çok değer katıyor.

Her çevre için dallar oluşturmak (dev, test, prod) bir hatadır. Bu, git için kapsam dışıdır ve serbest bırakma boru hattı tarafından ele alınmalıdır. Kesin aynı yapı, her bir ortam için dallar varsa mümkün olmayan tüm ortamlara dağıtılmalıdır.

Bir özellik çok büyükse, bir veya iki gün içinde yapılamaz, bir özellik dalına yapılan tüm çalışmaların ayrı dallarda olması ve PR ile bütünleştirilmesi gerekir.

— Esben Skov Pedersen
kaynak

Söylediklerinizin çoğuna katılıyorum, bunun dışında: "Aynı bina tüm ortamlara dağıtılmalıdır". Aslında, bir serbest bırakma boru hattı genellikle farklı binaları farklı ortamlara dağıtabilir ve daha sonra testler geçerken bunları teşvik edebilir. Farklı dallarla (veya en azından farklı etiketlerle) değilse, bununla nasıl başa çıkıyorsunuz?

— Marnen Laibow-Koser

Belki de tamamen net değildim. Bir derleme bir çevreye dağıtıldığında. Aynı eserler, yeniden inşa edilmeden bir sonraki ortama konuşlandırılmalıdır.

— Esben Skov Pedersen,

Eğer tekrarlanabilir yapılarınız varsa, yeniden inşa edip etmemeniz önemli değildir. Tekrarlanabilir yapıların yoksa, daha büyük sorunların var. :)

— Marnen Laibow-Koser

... ama evet, konuşlandırılmış taahhütlerinizi etiketlemeniz gerektiğini düşünüyorum, böylece aynı kodu tanıtabilirsiniz (yeniden kurulup kurulmadığına bakılmaksızın).

— Marnen Laibow-Koser

Evet, ancak çoğu CI sunucusu, kurulumları takip etmeyi kolaylaştırarak kutudan çıkan yayınlara bağlayabilir. Kurulum doğru yapıldığında, git'teki dağıtımları izlemek gerçekten gerekli değildir. Git bir scm. Dağıtım aracı değil.

— Esben Skov Pedersen,

2

Master, bir üretim dalını, çalışan bir son versiyonu yansıtmalıdır.
Doğrudan master'da çalışmak, hatalar oluşturduğunuzda "geri dönme" için başka bir seçeneğinizin olmadığı anlamına gelir; bu, temiz bir çalışma yöntemi olmayan ve yeni kodun parçalarını kaybetmenize neden olabileceği anlamına gelir. iyiydi.
Tabii ki, geliştirmenin ilk aşamalarında, belki doğrudan usta üzerinde çalışmaya başlayabilirsiniz, ancak bir şeyleri teslim ettikten sonra, yayınlanan, eksiksiz, çalışan versiyona dokunmamak için geliştirme, test veya deneme dalları kullanmalısınız.

— Tulains Cordova
kaynak

2

Birincisi, git'de her pullşeyin tam anlamıyla bir dallanma işlemi olduğunu ve her pushbirinin bir birleşme olduğunu belirtmek isterim . masterBir geliştiricinin makinede gelen tamamen ayrı bir dalıdır masterteknik açıdan eşit ayakta ile, paylaşmak merkezi repo. upstreamAmaçlarıma daha uygunsa , zaman zaman yerel sürümümü veya başka bir şeyi yeniden adlandırırım .

Bunu işaret ediyorum, çünkü birçok kurum şubeleri meslektaşınızdan daha etkili kullandıklarını düşünüyor, gerçekten de bir şube için ek bir isim oluşturmaktan başka bir şey yapmıyorlardı. Eğer meslektaşınız bir atomik taahhütte özellikler taahhüt ediyorsa, bir özellik dalının birleştirme taahhüdü kadar geri çekilmek kolaydır. Özellik dallarının büyük çoğunluğu çok kısa ömürlü olmalı ve yine de sık sık birleştirilmelidir.

Olduğu söyleniyor, çalışma tarzının ana dezavantajları iki yönlüdür. İlk olarak, bitmemiş bir özellik üzerinde işbirliği yapmayı çok zorlaştırır. Bununla birlikte, işbirliğinin gerekli olduğu zamanlarda şube oluşturmak zor olmaz.

İkincisi, birleşmeden önce incelemeyi çok zorlaştırır. Bu noktada, onu gerçekten ikna etmeniz gerekmez. Github, gerrit veya gitlab gibi bir araç benimseyebilir ve tüm istekleri kapsayan çekme isteği kodu incelemeleri ve otomatikleştirilmiş testlerden geçebilirsiniz. Böyle bir şey yapmıyorsanız, açıkçası git'i tam potansiyeli için kullanmıyorsunuzdur ve meslektaşınızın bu potansiyeli görmemesi şaşırtıcı değildir.

— Karl Bielefeldt
kaynak

1

Ayrıca geliştiricilere her gün şube makinesini zorlamak iyi bir yedek.

— Ian

İlk senini anlamıyorum. Nasıl pullyeni bir şube yaratacağını ya pushda bir birleşme operasyonunun nasıl olacağını göremiyorum . Aksine, bir pullolduğunu tam anlamıyla bir fetchbir takip merge!

— mkrieger1

@ mkrieger1 Yerelden masterfarklı bir dal olarak nasıl değerlendirilebileceğini kolayca görebiliyorum origin master. Teknik olarak, her biri kendi geçmişi olan iki farklı uzaktan kumandadaki farklı dallar.

— RubberDuck 17:16

@RubberDuck Evet, kesinlikle. İle pull: Önce: potansiyel olarak farklı komisyonlara işaret eden iki şube - Sonra: eşdeğer komisyonlara işaret eden iki şube - Hiçbir dal oluşturulmadı, bu yüzden "dallanma işlemi" olarak adlandırmazdım. İki komuttan herhangi biri varsa, ben bunu söyleyeceğim push, çünkü uzaktan kumandada potansiyel olarak yeni bir dal oluşturur. O neyi değil yapmak, bir birleştirme olduğunu.

— mkrieger 1

@ mkrieger1 birleştirme yönünü de göz önünde bulundurmanız gerekir .

— RubberDuck

2

Diğer cevaplar, doğrudan master üzerinde çalışmaz için çeşitli avantajlardan (izole edilmiş özellikler, her zaman master üzerinde taşınabilir kod vb.) Bahsetti.

Benim için farklı bir sorunun var gibi gözüküyor. Açıkçası, tüm geliştiricileriniz (veya söz konusu geliştiriciniz tarafından tamamen kabul edilmeyen) tarafından kabul edilen veya kullanılan bir geliştirme süreciniz yok.

Master ile birleştirilmiş özellik dallarınız var mı, yoksa farklı yayın dallarınız da var mı yoksa tamamen farklı bir süreç mi kullanıyorsunuz?

"Ana şubeyi kullanma" yeterli değil.

— Simon
kaynak

2

İş arkadaşlarımızdan biri doğrudan ana dalda değişiklik yapmaktan oldukça mutlu ve birkaç sohbete rağmen, bunu değiştirebilecek gibi görünmüyor.

Bu daha fazla sorun olduğuna inanmamı sağlıyor. Usta olsun ya da olmasın, çoğunlukla ürünleri nasıl, ne ve ne zaman piyasaya sürdüğünüzle ilgili daha büyük bir felsefenin bir parçasıdır.

Yani "asla usta üzerinde çalışmamalısınız" ile paralel olarak, özellik testleriniz var mı, birbirinizin testini yapıyor musunuz, başkalarının kodunu gözden geçiriyor musunuz. Kabul ve entegrasyon testleri.

Yukarıdakilerin hiçbirine sahip değilseniz ve sadece "git" yapmak için yapıyorsanız, ustalıkta da çalışabilirsiniz.

— Pieter B
kaynak

1

Doğrudan şubede çalışmakla ilgili "kötü uygulama" yoktur. Ancak, sürecinizi en iyi neyin desteklediğine karar vermelisiniz:

Soru 1: Master'ınız, yazılımınızın geçerli yayınlanma durumunu temsil etmeli mi? O zaman küresel bir kalkınma dalı tanıtmalı ve sürüm geliştirme sonunda geliştirmeyi birleştirmelisiniz.

Soru 2: Bir kod inceleme sürecine sahip olmak ister misiniz? Öyleyse, çekme istekleri yoluyla ana (veya varsa bir geliştirme) ile birleştirilecek "özellik dallarına" sahip olmalısınız.

Soru 3: Ara kod durumunu, henüz üretimde (veya testte) yayınlanmaması gereken diğer geliştiricilerle paylaşmanız gerekiyor mu? Bu durum birden fazla geliştiricinin bir özellik geliştirmesi durumunda ortaya çıkar. O zaman "özellik dalları" tanıtmalısınız.

— oopexpert
kaynak

Etiketler, sürümdeki bir kod tabanının durumunu göstermek için çok uygun bir yoldur. Git, belirli bir etiketi kontrol etmeyi çok kolaylaştırıyor. Dev bir dal tür tartışma yapar.

— RubberDuck 17:16