Git dallanma modelleri sizin için ne işe yarıyor?

Firmamız şu anda basit bir gövde / sürüm / düzeltmeler dallanma modeli kullanıyor ve şirket veya geliştirme süreci için hangi dallanma modellerinin en iyi çalıştığı konusunda tavsiye istiyor.

1. İş akışları / dallanma modelleri

   Aşağıda gördüğüm üç ana açıklama var, ancak bunlar kısmen birbirleriyle çelişiyor veya karşılaştığımız sonraki sorunları (aşağıda açıklandığı gibi) çözmek için yeterince ilerlemiyorlar. Böylece ekibimiz şimdiye kadar o kadar da iyi çözümler üretmemektedir. Daha iyi bir şey mi yapıyorsun?

   • gitworkflows (7) Kılavuz Sayfası
   • (nvie) Başarılı bir Git dallanma modeli
   • (reinh) Agile Teams için Git İş Akışı

2. Yeniden birleştirme ve yeniden birleştirme (sıralı geçmişe karşı karışık)

   Meli bir pull --rebaseveya görevin kadar ana hat için geri birleştirilmesi ile bekleme işlemi tamamlandıktan? Şahsen, bir görevin hangi temelde başlatıldığı ve bittiğini görsel bir şekilde koruduğu için birleşmeye eğilimliyim ve hatta merge --no-ffbu amaç için tercih ederim . Ancak başka dezavantajları var. Ayrıca birçoğu birleşmenin yararlı özelliğini fark etmedi - değişmeli değil (bir konu dalını master ile birleştirmek, master'ı konu dalıyla birleştirmek anlamına gelmez).

3. Doğal bir iş akışı arıyorum

   Bazen hatalar olur, çünkü prosedürlerimiz basit kurallarla belirli bir durumu yakalamaz. Örneğin, daha önceki sürümler için gerekli olan bir düzeltme, elbette, gerekli tüm branşların yukarı akış yönünde birleştirilebilmesi için yeterince aşağı akışa dayandırılmalıdır (bu terimlerin kullanımı yeterince açık mı?). Bununla birlikte, bir düzeltme, geliştiricinin daha aşağı akışa yerleştirilmesi gerektiğini fark etmeden önce ana hale getirir ve bu zaten itilmişse (daha da kötüsü, birleştirilmiş veya buna dayalı bir şey), kalan seçenek kiraz toplamadır. ilişkili tehlikeleri. Bunun gibi hangi basit kuralları kullanıyorsunuz?Ayrıca bu, bir konu dalının diğer konu dallarını hariç tutmaya yönelik garipliğini de içerir (ortak bir taban çizgisinden dallanmış oldukları varsayılarak). Geliştiriciler, yeni yazdıkları kodun artık orada olmadığı gibi bir duyguya başlamak için bir özelliği bitirmek istemiyorlar

4. Birleştirme çakışmaları (kiraz toplama nedeniyle) oluşturmaktan nasıl kaçınılır?

   Birleştirme çatışması oluşturmanın kesin bir yolu, dallar arasında kiraz toplamaktır, bir daha asla birleştirilemez mi? Her iki branşta da aynı taahhüdü geri döndürmek (nasıl yapılır?) Uygulamak muhtemelen bu durumu çözebilir mi? Bu, büyük ölçüde birleştirme tabanlı iş akışı için zorlamaya cesaret etmememin bir nedenidir.

5. Topikal dallara nasıl ayrılır?

   Konu dallarından tamamlanmış bir entegrasyon oluşturmanın harika olacağını biliyoruz, ancak genellikle geliştiricilerimiz tarafından çalışmak açıkça tanımlanmadı (bazen "etrafta alay etmek" kadar basit) ve bazı kodlar zaten "çeşitli" bir konuya girmişse, yukarıdaki soruya göre oradan tekrar çıkartılamaz mı? Konu dallarınızı tanımlamak / onaylamak / mezun etmek / serbest bırakmak için nasıl çalışıyorsunuz?

6. Kod inceleme ve mezuniyet gibi uygun prosedürler elbette güzel olurdu.

   Ama biz bunu idare edecek kadar karışık olan şeyleri tutamayız - herhangi bir öneriniz var mı? entegrasyon dalları, çizimler?

İlgili soruların listesi aşağıdadır:

• Dağıtılan uygulamaların düzeltilebilir olmasına izin vermek için bazı iyi stratejiler nelerdir?
• Şirket içi geliştirme için Git kullanımı için iş akışı açıklaması
• Kurumsal Linux çekirdek gelişimi için Git iş akışı
• Geliştirme kodunu ve üretim kodunu nasıl koruyorsunuz? ( bu PDF için teşekkürler !)
• git yönetimi serbest bırakır
• Git Cherry-pick ve Birleştirme İş Akışı
• Birden fazla taahhüt kiraz nasıl seçilir
• Seçmeli dosyaları git-merge ile nasıl birleştirirsiniz?
• Kiraz bir dizi taahhüt nasıl seçilir ve başka bir dalda nasıl birleştirilir
• ReinH Git İş Akışı
• Değişiklik yapmak için git iş akışı, hiçbir zaman başlangıç ​​noktasına geri itmeyeceksiniz
• Kiraz toplama birleştirme
• Birleşik işletim sistemi ve özel kod için uygun Git iş akışı?
• Git ile Projeyi Koruma
• Git neden dosya değişikliklerini değiştirilmiş bir üst öğe / ana öğe ile birleştiremiyor?
• Git Dallanma / Yeniden Temel Oluşturma İyi Uygulamaları
• "Git pull --rebase" beni ne zaman belaya sokacak?
• DVCS büyük ekiplerde nasıl kullanılır?

Ayrıca , Plastik SCM'nin görev odaklı geliştirme hakkında ne yazdığını kontrol edin ve Plastik sizin seçiminiz değilse, nvie'nin dallanma modelini ve destekleyici komut dosyalarını inceleyin .

DVCS'nin yeni geliştiricilerin gerçekleştirmesi gereken en rahatsız edici özellik yayın süreci hakkında :

• İhtiyacınız olan uzak repo'yu içe aktarabilirsiniz (getirme / çekme)
• istediğiniz herhangi bir (çıplak) repoda yayınlayabilirsiniz

Bundan sonra, sorularınızı kolaylaştırmak için birkaç kurala saygı duyabilirsiniz:

• bir şubeyi yalnızca itilmemişse yeniden sonlandırın (son rebase'den beri itilmemiş)
• sadece çıplak bir repoya git (Git1.7'den beri zorunlu)
• Linus'un rebase ve merges hakkındaki önerilerini takip edin

Şimdi:

İş akışları / dallanma modelleri :

her iş akışı bir sürüm yönetimi sürecini desteklemek için oradadır ve bu her proje için uyarlanmıştır.
Bahsettiğiniz iş akışına ekleyebileceğim şey: her geliştirici bir özellik dalı oluşturmamalı, sadece bir "şu anki geliştirici" dal, çünkü gerçek şu ki: geliştirici genellikle dalının tam olarak ne üreteceğini bilmiyor: özellik, birkaç (çok karmaşık bir özellik olduğu için sona erdi), hiçbiri (serbest bırakılma için zamanında hazır olmadığı için), başka bir özellik (orijinal olanın "morphed" olduğu için), ...

Sadece bir "bütünleştirici", "merkezi" bir repo üzerinde resmi özellik dalları oluşturmalıdır, bu da geliştiriciler tarafından çalışmalarının bu özelliğe uyan kısmını yeniden oluşturmak / birleştirmek için getirilebilir.

Yeniden birleştirme ve yeniden birleştirme (sıralı geçmişe karşı karışık) :

Bahsettiğiniz cevabımı beğendim ("Şirket içi geliştirme için git kullanımı için iş akışı açıklaması ")

Doğal bir iş akışı arıyorum :

düzeltmeler için, her düzeltmenin bir hata izlemeden alınan bir biletle ilişkilendirilmesine yardımcı olabilir, bu da geliştiricinin nerede (yani hangi dalda, yani düzeltmeler için özel bir dalda) söz konusu değişiklikleri yapması gerektiğini hatırlamasına yardımcı olur.
Ardından kancalar, merkezi bir repoyu onaylanmamış hata düzeltmelerinden veya itilmemesi gereken dallardan gelen itmelere karşı korumaya yardımcı olabilir. (burada özel bir çözüm yok, tüm bunların ortamınıza uyarlanması gerekiyor)

Birleştirme çakışmaları (kiraz toplama nedeniyle) oluşturmaktan nasıl kaçınılır?

Tarafından belirtildiği gibi Jakub Narębski içinde onun cevabı , kiraz toplama gerekli olan nadir durumlar için ayrılmalıdır.
Kurulumunuz çok fazla kiraz toplama içeriyorsa (yani "nadir değildir"), bir şey kapalıdır.

Geri dönüşte aynı taahhüdü uygulamak ister misiniz (bunu nasıl yapabilirim?)

git revert bununla ilgilenmeli, ama bu ideal değil.

Topikal dallara nasıl ayrılır?

Bir dal henüz her yere itilmediği sürece, bir geliştirici taahhüt tarihini yeniden düzenlemelidir (nihayet gelişimin daha kesin ve istikrarlı bir şekil aldığını gördükten sonra):

• gerekirse birkaç şube (açık bir şekilde belirlenen özelliğe göre)
• bir dalda tutarlı bir işlem kümesi (bkz. Git Checkin'i Düzeltme )

Kod inceleme ve mezuniyet gibi doğru prosedürler?

Entegrasyon dalları (özel bir entegrasyonda) repo, geliştiricinin şunları yapmasına yardımcı olabilir:

• gelişimini bu uzaktan entegrasyon şubesinin üstüne yeniden çekmek (pull --rebase)
• yerel olarak çöz
• gelişimi bu repoya itmek
• karmaşa ile sonuçlanmayan entegratör ile kontrol edin;)

Bence, ve yanlış olabilirim ki, git hakkında en çok yanlış anlaşılan şeylerden biri dağıtılmış doğasıdır. İsterseniz SVN davranışını taklit edebilmenize rağmen, yıkımın çalışabileceğiniz şekillerde söylenmesini çok farklı kılar. Sorun, hemen hemen her iş akışının yapacağı, ki bu harika ama aynı zamanda yanıltıcı.

Eğer çekirdek gelişimi hakkında bir fikrim varsa (buna odaklanacağım), herkesin çekirdeği geliştirmek için kendi git deposu vardır. Torvalds tarafından bakılan ve sürüm deposu görevi gören bir linux-2.6.git deposu var. İnsanlar "serbest bırakma" dalına karşı bir özellik geliştirmeye başlamak istiyorlarsa buradan klonlarlar.

Diğer depolar biraz gelişir. Fikir linux-2.6'dan klonlamak, çalışan "yeni" bir özelliğe sahip olduğunuza kadar istediğiniz kadar dallamaktır. Daha sonra, bu hazır olduğunda, güvenilir olarak kabul edilen, bu dalı depodan kendi alanlarına çekecek ve ana akımla birleştirecek birisine sunabilirsiniz. Linux çekirdeğinde bu, linux-2.6.git'e ulaşana kadar birkaç seviyede (güvenilir teğmenler) gerçekleşir ve bu noktada "çekirdek" haline gelir.

Şimdi burada kafa karıştırıcı oluyor. Şube adlarının depolar arasında tutarlı olması gerekmez. Ben böylece git pull origin master:vanilla-codeve bir şube olsun origindenilen benim deposunda bir dalda 'ın usta vanilla-code. Neler olduğunu bildiğim sürece, gerçekten önemli değil - tüm depoların birbirine akran olması ve sadece SVN gibi birkaç bilgisayarda paylaşılmaması anlamında dağıtılır.

Yani, tüm bunları göz önünde bulundurarak:

1. Bence her bir programcı kendi dallanmalarını nasıl yaptıklarına bağlı. Tek ihtiyacınız olan sürümleri yönetmek için merkezi bir depo vb. Gövde olabilir head. Sürümler etiketler veya dallar olabilir ve düzeltmeler muhtemelen kendi başlarına dallardır. Aslında, onları yama olarak tutabilmeniz için muhtemelen şube olarak yayınlar yapardım.
2. Ben birleştiririm ve geri dönerdim. Örneğin bazı dev bir depo, klon o dalı alıp yaparsanız, o zaman senin dan çekin originsiz, depoda, muhtemelen başka bir şube yapmalıdır ve en son birleştirme masteriçine yourbranchbaşka birisi kadar az çaba olarak ile değişiklikleri çekin böylece mümkün. Deneyimlerime göre gerçekten nadiren yeniden taban kurma ihtiyacı var.
3. Bence Git'in nasıl çalıştığını ve neler yapabileceğini anlamanın bir örneği. Bu biraz zaman alır ve çok iyi iletişim kurar - Git'i diğer geliştiricilerle kullanmaya başladığımda neler olduğunu gerçekten anlamaya başladım ve şimdi bile emin olmadığım bazı şeyler var.
4. Birleştirme çakışmaları faydalıdır. Biliyorum, biliyorum, hepsinin çalışmasını istiyorsun, ama gerçekte kod değişiklikleri ve sonuçları işe yarayan bir şeyle birleştirmen gerekiyor. Birleşme çatışmaları aslında daha fazla programlamadır. Onlar hakkında ne yapacağım için kolay bir açıklama bulamadım, işte burada: birleşme çatışmaları olan dosyaları not edin, gidin ve olması gerektiği gibi değiştirin git add .ve sonra git commit.
5. Ancak uygun. Söylediğim gibi, her kullanıcı git deposu oynamak için kendi ve şube isimlerinin aynı olması gerekmez . Örneğin, bir hazırlama havuzunuz varsa, bir adlandırma şeması uygulayabilirsiniz, ancak her bir geliştirici için, yalnızca yayın deposunda gerek yoktur.
6. Bu birleştirme aşamasıdır. Yalnızca kodun gözden geçirilmesini / kalite testinin geçmesini düşündüğünüzde sürüm dallarıyla vb.

Umarım bu yardımcı olur. VonC'nin çok benzer bir açıklama yayınladığını anlıyorum ... Yeterince hızlı yazamıyorum!

Düzen bu yorumlardan OP alakalı göründüğü gibi, ticari bir ortamda budala nasıl kullanılacağına ilişkin bazı başka düşünceler:

• Biz buna adlandıracağımız sürüm deposuna, product.gitürünün kendisine gerçekten bakmaktan sorumlu birkaç üst düzey programcı / teknik kişi tarafından erişilebilir. OSS'de koruyucuların rolüne benzerler.
• Bu programcılar muhtemelen kısmen yeni sürümlerin geliştirilmesine de öncülük ederler, bu yüzden kendilerini kodlayabilir ve varios havuzlarını koruyabilirler. Gerçekten yeni özellikler için hazırlama depolarını yönetebilirler ve kendi depolarına da sahip olabilirler.
• Aşağıda, bireysel bitleri geliştirmekten sorumlu programcılar bulunmaktadır. Örneğin, kullanıcı arayüzü çalışmasından birisi sorumlu olabilir. Bu nedenle UI.git deposunu yönetirler.
• Aşağıda, tam günlük işleri olarak özellikleri geliştiren gerçek programcılar bulunmaktadır.

Peki ne olacak? Peki, herkes her günün başında "yukarı akış" kaynağından yani serbest bırakma havuzundan (muhtemelen önceki günlerin gelişiminden en son malzemeleri içerecektir) çeker. Herkes bunu doğrudan yapar. Bu, büyük olasılıkla "master" olarak adlandırılan, belki de "en son" olarak adlandırıldığınızda, deposundaki bir dalda devam eder. Programcı daha sonra biraz iş yapacak. Bu iş emin olmadıkları bir şey olabilir, bu yüzden bir dal yaparlar, işi yaparlar. Çalışmazsa, dalı silebilir ve geri dönebilirler. Varsa, üzerinde çalıştıkları ana dalda birleşmek zorunda kalacaklar. Bunun üzerinde çalışan bir UI programcısı söylerim latest-uidiye bu yüzden git checkout latest-uitakipgit merge abc-ui-mywhizzynewfeature. Daha sonra teknik liderine (UI lideri) hey, böyle bir görevi tamamladım, benden çekin. Bu yüzden UI lideri yapar git pull user-repo lastest-ui:lastest-ui-suchafeature-abc. Daha sonra UI lideri o dalda ona bakar ve aslında, bu çok iyi, onu birleştireceğim der ui-latest. Daha sonra, altındaki herkesten ui-latestdallarından veya onlara verdikleri herhangi bir addan çekmesini söyleyebilir ve böylece özellik geliştiriciler tarafından araştırılır. Eğer takım mutlu ise, UI lideri test liderinden ondan çekilmesini ve değişiklikleri birleştirmesini isteyebilir. Bu, onu test eden ve hata raporları vb. Gönderen herkese (değişikliğin akış aşağısında) yayılır. Son olarak, özellik testten geçerse vb. daha sonra tüm değişiklikler geriye doğru yayılır. Ve bunun gibi.

Bu "geleneksel" bir çalışma şekli değildir ve SVN / CVS gibi "hiyerarşik" değil "akran güdümlü" olarak tasarlanmıştır. Özünde, herkesin sadece yerel olarak erişimi vardır. Bu depoya erişim ve hiyerarşiyi kullanmanıza izin veren yayın deposu olarak atadığınız depo.

İyi sonuçlarla kullandığım bir model şöyledir:

Herkesin temelde bir istemci-sunucu topolojisi olan "mübarek" bir repo iter ve çeker.

Ana dal yoktur, böylece hiçbir geliştirici herhangi bir kodu "ana hatta" zorlayamaz.

Tüm gelişmeler konu dallarında gerçekleşir. Bundan kimin sorumlu olduğunu kolayca tespit etmek için adları adlandırdık: jn / newFeature veya jn / issue-1234

Ayrıca beyaz tahta üzerinde dallar ve kanban / scrum kartları arasında bire bir eşleme bulunmaktadır.

Bir dalı serbest bırakmak için kutsanmış repoya itilir ve kanban kartı incelemeye hazır hale getirilir.

Daha sonra, şube inceleme tarafından kabul edilirse, serbest bırakılmaya adaydır.

Bir sürüm, bir dizi kabul edilen dal bir araya getirildiğinde ve sürüm numarasıyla etiketlendiğinde gerçekleşir.

Yeni etiketi kutsanmış repoya iterek yeni özellikler için yeni bir olası temel var.

Birleştirme çakışmalarını önlemek için geliştiricilerin yayınlanmamış dallarını en son sürüm etiketine güncellemeleri (birleştirmeleri) rica olunur.

Şahsen, ana dalda sadece yayına hazır kodu tutmaya çalışıyorum.

Yeni bir özellik veya bugfix üzerinde çalıştığımda bunu bir dalda yapıyorum. Ayrıca branşta birim test yapıyorum. Eğer her şey yolunda giderse, ancak o zaman ustaya geri dönerim / yeniden birleştiririm.

Ben de denemek ve yaygın şube adlandırma kuralları gibi kullanmak:

• bugfix / recursive_loop
• bugfix / sql_timeout
• özellik / new_layout
• özellik / enhanced_search