git-flow ve github ile kod incelemesi


43

Düzenli git ve github ile ana dalda üzerinde çalıştığım özellik dalının çekme talebini oluşturarak bir kod incelemesi yapabilirim. Git-flow ile kod incelemelerini nasıl yaparım? Git akışı özelliği bitirme gibi iş akışı ile kod incelemesinin gerçekte nerede gerçekleştiği ve git-flow veya git'in bu incelemeyi nasıl kolaylaştıracağı konusunda kafam karıştı.


Gerrit içine bakabilirsiniz, ancak git-flow ile nasıl iyi bir şekilde bütünleştiğinden emin değilim. Her neyse, takım akışınız nedir?
OnesimusUnbound

Yanıtlar:


29

Son zamanlarda tam olarak bu sorunu çözdük. Git akışını gerçekten seviyoruz, çünkü iyi bir anlambilim düzeyi kullanıyor (ekip tartışmasında kullandığınız seviyenin aynısını kullanıyorsanız: "A özelliğini" başlatacağım "," dal oluşturacağım, kontrol edeceğim "den daha fazla) git çok "uygulama" seviyesidir (bu aynı zamanda iyi ve faydalıdır, fakat farklıdır).

git feature finishŞubemiz gelişmesiyle birleştiğimizde ortaya çıkan sorun , bir çekme talebinin gönderilmesini ve (bu önemlidir) yorumlayıcı tarafından değil, birleştiricinin ekip sahipliğini vurgulaması için birleştirilmesidir .

Mevcut çözümümüz:

  1. Birisi bir özellik dalı oluşturmak için git akışını kullanıyor
  2. Bittiğinde bir çekme isteği yarattı (github kullanarak)
  3. Gözden geçirme, olası ek taahhütler ile gerçekleştirilir
  4. Çekme isteği, gözden geçiren tarafından GitHub kullanılarak birleştirilir .
  5. Git akış özelliği bitişi yok (dal zaten birleştirilmiş olduğundan)

Bu, şubemizin kendimizi silmeyi isteme dezavantajı olan uygulamamızla tutarlıdır (gitmeyi bitiremediğimiz için). Bir sonraki adımımız muhtemelen git bir akışının bazı kısımlarını (esas olarak git komutlarının zincirlenmesiyle ilgili olduğu gibi) bunu hesaba katmak (birleşmenin olmadan bitişin "temizleme" kısmına sahip olmak üzere) yeniden uygulamak olacaktır.


3
Bir yayın dalı oluşturmaya ne dersiniz? Etiketlere ne olacak?
E-Riddie

16

Çalıştığım ekibin bunun için kullandığı süreç şöyle:

  1. Bir özellik dalı oluşturun: git flow feature start module_1
  2. Kod, özellik dalında güncellenir
  3. Değişiklikler yapıldıkça GitHub'a gönderilir (veya tercih edilirse bir kez)
  4. Özellik tamamlandığında GitHub karşılaştırmasında developve özellik dalında bir çekme isteği açılır.module_1
  5. Ekip çekme isteğini inceler ve yorum yapar
  6. Çekme isteğindeki herhangi bir değişiklik, özellik dalında yapılır
  7. Tüm değişiklikler özellik dalına eklendikten sonra, özellik dalı tamamlanır: git flow feature finish module_1
  8. developDal (kapalı / birleşti olarak bu olduğunda GitHub otomatik çekme isteğini damgasını vuracak) GitHub'dan itilir

Normalde bu işlemin tamamı orijinal yazar tarafından yapılır, ancak bu gerekli değildir. Ekibimizdeki herkes bu süreci herhangi bir noktada devreye alabilir ve alabilir. Tek yapmaları gereken, özellik dalını kontrol etmek ve işleme devam etmek. Hiç koşmayanlar git flow feature finish module_1, yerel özellik branşlarının lüksünün silinmesine neden olacaklar, ancak şubeyi kontrol eden herhangi biri, eğer böyle bir şey kullanmak isterse bunu manuel olarak yapmak zorunda kalacak git branch -D feature/module_1.

Düzeltmeler için benzer bir yaklaşım kullanıyoruz ve düzeltmeyi bitirmeden önce GitHub'da çekme isteği oluşturuyoruz.


Bu cevap için teşekkürler. Git'in bir birleşme sonrasında PR'yi kapalı olarak işaretleyeceğini bilmiyordum.
vicTROLLA

3

Kod incelemeleri yapıyorsanız, "resmi" kodu içeren merkezi bir havuzunuz olduğunu varsayacağım. Geliştiriciler bu merkezi depoya girer ve onu zorlar.

Gerrit'i kullandığınızda , Gerrit'in kendisi merkezi bir depo haline gelir (kullanıcıların, temelde olduğu gibi etkileşime girmesini sağlayan yerleşik SSH ve HTTP sunucularına sahiptir). Gerrit kullanırken, iş akışı şu şekilde olur:

  1. Geliştirici hangi şube üzerinde değişiklik yaparsa, yerel olarak taahhüt eder.
  2. Geliştirici bu değişiklikleri Gerrit'e doğru iter.
  3. Gerrit başkalarının incelemesi için inceleme maddeleri oluşturur.
  4. Akranlar kodu gözden geçirir, yorum yapar ve taahhüdü kabul eder veya reddeder.
  5. Kabul taahhüt zaman sonra Gerrit diğerleri şubesinden çekmeye için olanlar kullanılabilir değişiklikleri yapar.

Merkezi bir depo kullanırken, diğer geliştiriciler 2. adımdan sonra gönderilen değişiklikleri görebilirler. Gerrit kod inceleme iş akışını tanıtır ve diğer geliştiriciler yalnızca 5. adımdan sonra gönderilen değişiklikleri görür.

Bu, git-flow (veya başka bir dallanma şeması) ile iyi çalışır çünkü Gerrit herhangi bir dalda yapılan değişiklikleri incelemeyi destekler.


3

İşte başka bir öneri.

  1. Bir özellik oluşturmak için normal git flow işlemini yapın , ancak bitirmeyin veya birleştirmeyin.
  2. Bir çekme isteği oluşturun , ancak birleştirme. Onaylayanın yorum bırakmasını bekleyin. Yorum onay işaretidir.
  3. Do git akış bitirmek . (Ekibinin kararlaştırdığı şeye bağlı olarak onaylayan veya geliştirici bunu yapabilir.) Çekme talebi, github'da birleştirilmiş olarak işaretlenecektir. Şubeyi menşei üzerinde silmeniz gerekir.
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.