it-swarm.asia

Yeni geliştirici şube birleşmelerine ayak uyduramıyor

Ben yeni geliştiriciyim - bu benim ilk programlama pozisyonum.

Benim sorunum şudur: git - develop şubemizden bir dalı kestim, sonra atanmış olduğum küçük görev üzerinde çalışmaya başladım. Çok yavaş, çünkü deneyimsizim. Şubemi yeniden develop ile birleştirmeye hazır olduğumda, diğerleri o kadar çok değişiklik yaptı ki, çatışmaların çözülmesi çok zor oldu (aslında işimi kazımak ve göreve başlamak daha kolay görünüyor. ders sürdürülebilir bir çözüm değildir).

Bunu nasıl yenebilirim? 'Kodlamada daha iyi olmak' dışında kullanabileceğim bir taktik var mı? Bunu önümüzdeki hafta amirimle birlikte büyütmeyi planlıyorum.

225
daisy

Şubenizde yaptığınız değişiklikler, iş arkadaşlarınızın bu arada develop dalında yaptığı değişikliklere yakınsa, yani siz ve meslektaşlarınız aynı kod satırlarını veya bitişik satırları değiştirdiyseniz aynı dosya.

Bu nedenle, birleşme çakışması olasılığını azaltmak için, daha önce birleştirmeye çalışabilirsiniz, böylece iş arkadaşlarınız bu arada daha az satır değiştirebilir veya daha az satırı kendiniz değiştirmeye çalışabilirsiniz.

Daha az satırı kendiniz değiştirmek için yalnızca görevinizle ilgili değişiklikler yaptığınızdan emin olun.

Hedefinize ulaşmak için farklı yollar denemeniz gerekiyorsa, bazı denemeniz gerçekten değiştirilmesi gerekmeyen satırları değiştirmiştir? Birleştirmeden önce bu değişiklikleri geri alın.

Mümkün olduğunca az satırı değiştirmenize yardımcı olabilecek bazı Git komutları da vardır:

  • git diff ve git diff --staged Hangi satırları değiştirdiğinizi görmek için.
  • git add -p değişikliklerinizi yalnızca bir dosyaya eklemek için.
  • git commit --amend ve git rebase -i to Tweak, diğer Git depolarına göndermeden önce yerel özellik dalınızda yapmış olduğunuz taahhütleri yerine getirir.

(Mümkün olduğunca az satırın değiştirilmesi, çalışmanızı gözden geçirmeyi veya _ gibi taahhütler arasındaki farklar üzerinde çalışan araçlar kullanmayı da kolaylaştırabilir git cherry-pick, git rebase, git bisect, ve git blame.)

Ancak, birleşme çatışması olasılığını azaltsanız bile, bazen birleştirme çatışmalarıyla karşılaşırsınız. Bu yüzden onlardan korkmayın, ancak çatışmaları nasıl çözeceğinizi öğrenin.

7
Toxaris

Git kullandığınızı varsayıyorum. Öyleyse, git rebase -i (-i etkileşimli anlamına gelir). Şubenizi geliştirme dalına karşı yeniden temellendirmeyi günlük bir görev yapın (gerekirse daha sık). Bu özellik branşınızı güncel tutmak için her gün kademeli olarak (en azından) değişiklikleri getirir. Günlük rebase sırasında çatışmalar varsa, ekibinizle kimin ne üzerinde çalıştığı hakkında konuşmanız gerekir.

Günlük olarak çalıştırırsanız, muhtemelen etkileşimli kısma ihtiyacınız olmayacaktır. Sadece kendi işini yapmasına izin ver.

Oldukça deneyimli bir geliştiriciyim ve yeni bir projede hızlanmam hala biraz zaman alıyor. Sizin durumunuzda, aynı projede aynı anda çalışan birkaç insanınız olduğu anlaşılıyor, bu yüzden çok büyük bir proje veya hızla gelişen yeni bir proje. Her iki durumda da, akışa girmeniz birkaç ay alırsa endişelenmeyin. Projeleri 2 veya 3 hafta değiştirir ve sonra geri dönersem,% 100 kendi başıma yazdığım bir projeye tamamen "geri dönmek" birkaç saatimi (hatta bir veya iki gün) alabilir!

Kısacası, şu anda yavaş olmaktan endişe etmeyin. Daha iyi olmanın yolu pratik yapmaya devam etmektir. Diğer geliştiricilere anlamadığınız projelerin yönleri hakkında soru sormaktan çekinmeyin.

DÜZENLE:

Veya merge kullanın. Bu da bir seçenek. Yani, yukarıdakiler şöyle olur: "git rebase -i (-i etkileşimli anlamına gelir) veya git merge ". Hangisini kullanacağınıza gelince, ekibinizin geri kalanıyla konuşun. Her iki şekilde de güçlü tercihleri ​​olabilir (veya olmayabilir). Bazı kişilerin yaptıkları açıktır güçlü tercihler var.

286
Jacob Robbins

Bu, şirketin kötü yazılım mühendisliğinin bir işareti olabilir. Çok fazla bağımlılık, üst üste binen özelliklerle ilgili farklı sorunlar, sorunları yanlış sırayla çözmeye çalışmak vb. Tanımladığınız duruma neden olabilir. Geliştirme sırasında develop dalını düzenli olarak birleştirmenizi öneririm

130
Ivan Anatolievich

Kabul edilen cevapların daha çok teknik bir "Git'i daha iyi kullanma" doğası olduğunu düşünüyorum, bence bu bir mühendislik veya takım probleminden çok bir takım problemi.

Çok sayıda birleştirme çatışması yaşıyorsanız, bu, siz ve takımdaki bir başkasının birbirlerinin ayak parmaklarına bastığınız anlamına gelir.
Siz veya onlar kodlarken kişisel alan geliştirmeyi ve zaten meşgul olan alanlarda çalışmaktan kaçınmayı hedeflemelisiniz.

Ekibimde yüksek derecede görev sahipliğine yöneliyoruz.
Genellikle bir seferde iki veya üç dosyanın tam ve eksiksiz sahipliğini alıp bir ya da iki gün boyunca bir şubede çalışacağım.
Genellikle bu dosyalara başkası dokunursa, yalnızca kendi görevleri için kesinlikle gerekliyse, genellikle aynı görev bloğunda birlikte çalışmaz!

Çok fazla birleştirmeniz gerektiğini fark ederseniz, tüm takım kodlarınız tek bir yerde (bu, kendi başına kaçınacak bir şeydir) veya tüm görevlerinizdir.

Tüm bunlar, yeni bir geliştirici olarak muhtemelen herhangi bir yeniden yapılandırmayı zorlama, talep etme veya hatta gerçekten önerme pozisyonunda değilsiniz.
Beklediğim şey, görevlerinizin sizi ekip içinde rahatlatmak için beceri seviyenizde makul şekilde ulaşılabilir olması gereken "ipleri öğren" olarak atanması. Muhtemelen hala aynı alanda çalışan bir iş arkadaşının görevlerinden çıkarıldılar, bu nedenle birleştirme çatışmalarınız.
O zaman bunun çözümü, onu takmak, sorunları çözmek, birleştirme çatışmalarıyla mümkün olan en iyi şekilde başa çıkmak ve çok fazla endişelenmeyin, elinizden gelenin en iyisini yaptığınız sürece yöneticiniz ilerlemeniz konusunda endişelenmenize yardımcı olur.
Gittikçe daha hızlı ve daha güvende olacaksınız ve iş arkadaşlarınız size daha fazla özerklik verecek ve sonuç olarak yolunuza daha az girecek.

97
Rowan

Birleştirme ile ilgili en önemli şey, ne kadar uzun süre beklerseniz, o kadar acı verici hale gelmesidir. Ve problem doğrusaldan daha fazla büyüyor. Üç kat fazla çatışma dokuz kat fazla iştir. Bazı stratejiler var:

Her değiştiğinde geliştirme dalıyla birleşin, böylece her zaman ona yakın olursunuz ve asla çok sayıda çatışma yaşarsınız.

Uzun zaman alırsanız, bunun nedeni çoğu zaman değişikliklerin ne olduğunu anlamaya ve daha sonra değişiklikleri uygulamak için az miktarda zaman harcamanıza neden olabilir. Bu durumda, gerçek kod değişikliklerine başlamadan önce geliştirme dalıyla birleştirin.

Çatışmalardan kaçınmak için stratejiler hakkında iş arkadaşlarınızla konuşun. İki kişi aynı kodu düzenlerse çakışmalar oluşur. Sadece aynı dosya değil, aynı kod. Bu yüzden yeni bir fonksiyon fonksiyonuna ihtiyacım var ve yeni bir fonksiyon fonksiyonunaB ihtiyacınız var ve ikimiz de aynı dosyanın sonuna ekliyoruz, bir çakışma var. Farklı yerlere eklersek, çatışma olmaz. Her ikisini de mantıksal olarak ait olduğu dosyaya bir yere eklersek, hiç bir çatışmamız yoktur.

Eğer çakışmalarınız varsa, iyi bir fark aracı edinin, böylece birleştirme işleminden önce geliştirme dalını, birleştirme öncesi kodunuzu, orijinal kodunuzu ve birleştirilmiş kodu karşılaştırabilir ve elle birleştirebilirsiniz.

En kötü durum: Çalışmanızı atmazsınız, ancak tam olarak hangi değişiklikleri yaptığınızı bulmak için iyi bir fark aracı kullanın, geliştirmeden tekrar dallayın ve yaptığınız tüm değişiklikleri yeniden yazmak yerine manuel olarak uygulayın.

29
gnasher729

Şimdiye kadar hazırım birleştirme Şubem yeniden gelişmeye başladı (benimkini vurgula)

git merge İle çakışmaları ele almak genellikle git rebase İle olduğundan daha kolaydır. Git birleştirme işleminde, bir defada değiştirilmiş olan dosyaların listesini görebilirsiniz. Diğer iş arkadaşları tarafından kaç taahhüt yapılırsa yapılsın, birleştirmeniz gerekecek bir kez. Rebase iş akışında, aynı çakışmaları tekrar tekrar elde edebilir ve bunları manuel olarak incelemeniz gerekebilir. Sonuç olarak 13. işi tamamlayabilir ve tünelden ışığı göremediğinizi hissedebilirsiniz .

Deneyimlerime göre, tekrarlanan rebase çatışmalarını saf bir şekilde çözmeye çalıştığımda, birinin değişikliklerini veya derlemeyen bir uygulamayı kaybettim. Genellikle ben ve iş arkadaşları çok fazla iş yaptık, ancak tekrarlanan çatışmaların karmaşıklığından o kadar bunalmıştık ki, bir avuç rebase işleminden sonra önceki işimizi iptal etmek ve kaybetmek zorunda kaldık.

Size birkaç teknik önereceğim, ancak birleştirmenin görevi otomatikleştirmekten daha kolay olmasına yardımcı olabilirler.

  • Kaynak/dil dosyaları. Bir kaynak dosyasında eklenti değişiklikleriniz varsa, kolayca hatırlayabilmeniz için bunları daima dosyanın sonuna taşıdığınızdan emin olun değişikliklere karşı diğerleri 'değişikliklere karşı. Değişikliklerinizi altına kopyalayıp yapıştırabilir veya yalnızca çakışma işaretlerini kaldırabilirsiniz
  • Yapın. KESİNLİKLE. RE biçiminde değil. Ne siz ne de geliştirici arkadaşlarınız günlük çalışma sırasında "büyük bir kod reformu" gerçekleştiremezsiniz. Kod yeniden biçimlendirmesi, çatışma yönetimine aşırı sayıda yanlış pozitif ekler. Kod yeniden biçimlendirmesi yapılabilir
    • Artımlı olarak, ör. her geliştirici tarafından otomatik bir araç kullandıkları anda (örneğin Eclipse'nin kaydetme üzerinde yeniden biçimlendirme seçeneği vardır, Vanilla Visual Studio'da hiçbiri yoktur). Kesinlikle her geliştirici, IDE'niz tarafından yenen bir format dosyasına kodlanmış aynı kod formatlama standartlarını kullanmalıdır. Size bir fikir vermek için 4 boşluk veya 2 sekme olması önemli değil, ancak herkesin aynı şeyi kullanması gerçekten önemli.
    • Serbest bırakılmadan hemen önce bir ekip lideri tarafından. Eğer insanlar dallar üzerinde çalışmadığı zaman, yani dallanmadan önce bir "kod yeniden biçimlendirme" taahhüdü gerçekleşirse, işler daha kolay olacaktır
  • İncele iş arkadaşları arasında bölünen iş. Bu, çoğu mühendisliğin geldiği bölümdür. Diğer cevapların işaret ettiği gibi, farklı görevleri yapan birden fazla geliştiricinin aynı kaynaklara dokunması gerekiyorsa tasarım kokusudur. Her bir eşzamanlı geliştirici tarafından hangi parçanın değiştirileceği konusunda ekip liderinizle görüşmeniz gerekebilir.

Ayrıca ekiplerimdeki Git iş akışlarında bazı kötü alışkanlıklar gördüm. Genellikle insanlar şubelerine fazla yüklenir. Şahsen bir geliştiricinin "düzeltme" etiketli 10 ila 20 komisyon eklediğine şahit oldum. Politikamız, size bir fikir vermek için taahhütlerin JIRA biletleri ile etiketlenmiş olmasıdır.

@JacobRobbins git rebase 'U günlük bir görev yapmayı önerir. Yaklaşımını ileriye taşımak istiyorum.

İlk olarak, bir avuç için taahhüt sayısını azaltmak için bir kez rebase kullanın. Ve sadece dallanmış olduğunuz taahhüt olan orijinal geliştirme dalına yeniden başlayın. Avuç dediğimde, 3 veya 4 (örneğin tüm ön uç, tüm arka uç, tüm veritabanı yamaları) veya insanca makul herhangi bir rakam anlamına gelebilirim. Bunları birleştirdikten sonra, fetch kullanın ve rebase'inizi yukarı akış kolu üzerinde çalışın. Bu, ekibiniz kendi yaklaşımlarını gözden geçirmedikçe sizi çatışmadan kurtarmayacak, ancak hayatınızı daha az acı verici hale getirmeyecektir.

Belirli görevler hakkında başka sorularınız varsa, Stackoverflow'u aramaktan ve sormaktan çekinmeyin.

Re-reformat ve izci kuralı hakkında [Düzenle]. Ben biraz ne değiştirdi RE-formatı ne demek istediğim dokunmamış kodu da dahil olmak üzere, tüm kaynak dosyasını sıfırdan biçimlendirme görevi olduğunu vurgulamak için. Her zaman tam olarak erkek izci olan kendi kodunuzu biçimlendirmenin aksine, ben de dahil olmak üzere bir dizi geliştirici, dosyanın tamamını IDE'nin yetenekleriyle yeniden biçimlendirmek için kullanılır. Etkilenen satırlar içeriklerinde ve anlamlarında değişmese bile dosya başkaları tarafından dokunduğunda Git dosyayı bir çakışma olarak görür. Yalnızca çok güçlü bir dil tanıyan düzenleyici, çatışmanın yalnızca biçimlendirme ve en iyi biçimlendirilmiş parçayı otomatik olarak birleştirmeyle ilgili olduğunu önerebilir. Ama böyle bir araç olduğuna dair kanıtım yok.

Sonuçta, izci kuralı sizi diğer insanların karmaşasını temizlemeye zorlamıyor. Sadece senin.

15

İlk olarak, değişikliklerinizi atmayı düşünmeyin. Birleştirme işlemini öğrenme fırsatlarını kaybedeceksiniz.

İkinci olarak, dosyalar üzerinde çalışan ve çatışmaya neden olan birini bulun. Tarihi görebilirsiniz. Kişiyle konuşun ve bu dosyalardaki çakışmaları giderin. Diğer çatışmalar için de aynısını yapın.

Çok fazla çakışma varsa, göreviniz küçük ama tekrarlayıcı olabilir. Bir desen bulmaya çalışın. Bu, Git kullanıcı arabirimi istemci araçlarıyla çakışmaları çözmenize yardımcı olur. TortoiseGit kullanıyorum. Birleşmeye yardımcı olur.

Ve gelecekte kaçınmak için,

  • Geliştirme dalını düzenli olarak özellik dalınızla birleştirmek çok iyi bir uygulamadır.

  • CI etkinse, CI aracının bir şube oluşturma sağlayıp sağlamadığını kontrol edin. Bu, özellik branşınızda yaptığınız her çeke dayalı olmalıdır, ancak birleştirme işleminden sonra dal geliştirin.

6
PKV

Burada altta yatan birkaç sorun var. Birleştirme sorunlarınız büyük olasılıkla sizin hatanız değildir ve daha çok kötü uygulamaların bir belirtisidir.

1) İdeal olarak şubenizi her gün gelişmeye birleştirirsiniz. Günde en az bir kez, tüm testleri geçen çalışma koduna sahip olmaya çalışın, böylece gelişmeye katılabilirsiniz.

2) Her zamanki iş gününüzde hiçbir noktada çalışma kodunuz yoksa, üzerinde çalışmak için çok büyük kod parçalarınız olabilir. Birleştirme yapabilmek için görevinizi daha hızlı tamamlanabilen (ideal olarak birbirinden bağımsız) daha küçük görevlere ayırmanız gerekir.

3) Proje dosyalarınız büyük olasılıkla çok büyük. Bir dosya için birçok birleştirme çakışması varsa, bir dosya üzerinde çalışan çok fazla kişi var. İdeal olarak, bir kişinin üzerinde çalıştığı bir şey, herkesin üzerinde çalıştığından ayrı olmalıdır.

4) Takımınız çok büyük olabilir. Tüm bir özelliği atmayı ve baştan başlamayı daha kolay bulursanız, muhtemelen aynı depoya kod işleyen çok fazla insan vardır.

5) Tutarlı kod biçimlendirme standartlarınız olmayabilir. Hepiniz aynı kod formatını tutarlı bir şekilde kullanmazsanız, aynı kod için birçok farklı çakışma yaşarsınız. Git'inizin nasıl ayarlandığına bağlı olarak, bunlar beyaz boşluk çakışmalarına (satır sonları, girinti, sekmeler ve boşluklar) bile gelebilir.

6) İnsanlar değişikliklerini doğrudan gelişim koluna itiyor olabilirler.

siz şunları yapabilir: 1) Her gün gelişmek için birleştirilemezseniz, her gün (veya daha sık) birleştirme/yeniden satış şubenize gelişir.
2) Kodunuzu her birinin kodundan ayırmaya çalışın.
3) Ekibin geri kalanıyla daha küçük özellikler, tutarlı kodlama standartları ve daha iyi kod organizasyonu (daha küçük dosyalar, daha küçük işlevler) hakkında konuşun.

2
xyious

Aslında işimi kazımak ve işe başlamaktan daha kolay görünüyor, ki bu elbette sürdürülebilir bir çözüm değil)

Çoğu zaman, bu yaptığım şey, ilk kez bir hatayı düzelttiğimde veya sistemde bir değişiklik yaptığımda, nasıl yapılacağını öğreniyorum. Bir dahaki sefere aynı hatayı düzelttiğimde, şimdi sorunu anladığım gibi sadece% 1 zaman alıyor.

Ben de biraz iş yeniden yaptığımda, daha iyi kod yazmak .....

Bu nedenle, ustadan yeni bir şube oluşturmak, işinizi yeniden yapmak, ne yapmanız gerektiğini hatırlatmak için "özel şube" nizi kullanırken yanlış bir şey yoktur.

Değişikliğinizi, her biri tamamlandıktan sonra ana dalda birleştirilecek olan mantıksal ve doğru parçalara bölmenin bir yolunu keşfetmeniz de mümkündür. Örneğin, birim testleri ve arka uç kodunda değişiklikler yapılabilir ve birleştirilebilir. Daha sonra ayrı bir işlemde, bunları kullanan UI değişikliklerini yapabilirsiniz, bu nedenle aynı UI dosyasını düzenleme konusunda başka birinin riski daha azdır.

1
Ian

Geliştirme dalını sizin dalınıza çok sık birleştirmek istemiyorsanız, git pull --rebase Kullanarak svn benzeri bir iş akışı elde edebilirsiniz. Bu, yeni taahhütleri çekecek ve taahhütlerinizi bunlara yeniden temellendirecektir. Bu, şubenizi geliştirmeye birleştirdiğinizde, hızlı ileri bir birleştirme (sanki tüm geçmiş taahhütlerinizi birbiri ardına aynı anda eklerdiniz gibi) olacak ve herhangi bir birleştirme çakışması olmayacağı anlamına gelir. git pull --rebase.

Ancak, dalınızı geliştirmeye veya dalınıza geliştirmeye başlamadan önce ne kadar fazla taahhütte bulunursanız, bir sonraki rebase o kadar karmaşıklaşır ve dalınız birleştirilmediği sürece var olan dalların duygusunu biraz bozar. .

1
allo

Açıkçası ilk şey, en azından zor çatışmalara yol açacak şekilde, birden fazla kişinin aynı dosyalar üzerinde çalışmasını önlemek. İyi bir kod biçimi kullanıldığı sürece numaralandırmalara bir şey eklemek sorun olmaz. Kontrol akışını farklı şekillerde değiştirmek ve kodu hareket ettirmek çok daha zordur. Yine de bu kaçınılmazdır. Gerçekten karmaşık olan anlaşmazlıkları çözerken soru sormanız gerekir.

Bununla birlikte, düzenli olarak gelişmek için birleştirmeyi/yeniden birleştirmeyi öneren birçok cevap görüyorum. Bu tür tavsiyeler konusunda daha az hevesli olurdum. Bu noktada amacınız, çatışma çözme sürecini olabildiğince kolay ve güvenli hale getirmektir. Bu süreçte muazzam bir şekilde yardımcı olacak bir şey, yeni özelliğinizin bir parçası olan yenileri de dahil olmak üzere hemen hemen birçok regresyon testine sahip olmaktır. Şubenizi geliştirmeyle çok düzenli olarak senkronize ederseniz, özelliğinizi gerçekten uygularken yarı işiniz bittiğinde her zaman çatışmaları çözmek zorunda kalacaksınız. Ve bu, kodun sizin için yapılmadığı için ne yapılması gerektiğini anlamaya çalışmak çok daha zor olacağı anlamına gelir. Birleştirmeye çalışmadan önce, şubenizin tutarlı bir değişim birimi olduğundan emin olun. Daha da iyisi, birleştirmeden önce tek bir taahhütte yeniden birleştirin.

Muhtemelen başka bir soru için olan birleşme üzerinde rebase'in esasına girmemeye çalıştım. Bu bağlamda araçlar gerçekten önemli değil.

1
Kafein

Şubemi yeniden geliştirmek için birleştirmeye hazır olduğum zaman, diğerleri o kadar çok değişiklik yaptılar ki, anlaşmazlıkları çözmek çok zor

Bu çift programlama için ideal bir senaryo gibi geliyor!

Yararları ve temel yaklaşımlar hakkında daha fazla bilgi:
https://gds.blog.gov.uk/2018/02/06/how-to-pair-program-effectively-in-6-steps/

Doğal olarak zaman içinde kendi başınıza çalışmayı hızlandıracaksınız, ancak o zaman gelene kadar göz korkutucu olabilir ve bazen de uzun bir mesafe. Ayrıca, insanlar her zaman yetişmek için baskı altında olan stresli bir ortamda olmayı hızlı bir şekilde öğrenebilirken, sürekli baskı altında iyi öğrenmeyen diğerleri engellenecektir.

Kendi başınıza bir dal üzerinde çalışmak ve sizden çok daha hızlı olan diğer geliştiricilere ayak uydurmak yerine, başka bir geliştiriciyle doğrudan (aynı PC) çalışacaksınız. Bu şekilde anında tavsiye alırsınız ve muhtemelen nasıl hızlanacağı vb.

Çift programlama bazı projeler için her zaman mantıklı olmadığından, projenizdeki belirli kod için en iyi yaklaşımı bulursunuz - ancak sizden daha deneyimli birini otursanız ve izleseniz bile muhtemelen her zaman öğrenme için mantıklıdır. (iyi bir geliştirici oldukları sürece, deneyim mutlaka iyi uygulamalar kullandıkları anlamına gelmez).

Daha hızlı, daha deneyimli bir geliştiriciyle oturmanın aşağıdakilere yardımcı olma potansiyeli vardır:

  • Daha deneyimli biriyle çalışmak tek başına çalışmanın aksine tamamlanma süresini artıracağından birleştirme çatışmalarını muhtemelen azaltacaktır
  • Size öğretecekleri gibi, muhtemelen tek başlarına çalışacaklarından daha yavaş olacaklar, bu yüzden hala birleşme çatışmaları olabilir ve bu yüzden deneyimli biriyle onlarla çalışabilir ve belki de zamandan tasarruf etmek için bazı ipuçları alabilirsiniz.
  • Potansiyel hileleri ve daha hızlı olmanın yollarını görmenize yardımcı olun (yavaş olmak bazen iyi uygulamalardan ziyade sadece deneyim eksikliğidir)
  • Bir şey mantıklı olmadığında veya% 100 net olmadığında hemen soru sorabilir
  • 1: 1 çalışmak öğrenme için değerlidir, çünkü yardım isteyeceğiniz kişi üzerinde çalıştığı haliyle kod ve senaryoyu zaten anlar, çift programlama olmadan, genellikle bir sorunla sonuçlanan kod ve senaryoyu açıklamanız gerekir. böylece gerçekten çok tavsiye almak için zaman/dikkatini kaybedersiniz
  • Daha deneyimli ve tecrübeli birinin düşünce sürecini tanıyın ve iyi iletişim ile kesinlikle yeni şeyler öğreneceksiniz

'Kodlamada daha iyi olmak' dışında kullanabileceğim bir taktik var mı? Bunu önümüzdeki hafta amirimle birlikte büyütmeyi planlıyorum.

Benim tavsiyem, çift programlamayı diğer geliştiricilerle tartışmak ve ardından amirinize yaklaşmaktır. Eğer iyi iseler, çift programlamanın artılarını sunmanız için daha fazla şansa sahip olan inisiyatifinizi takdir edeceklerdir (buna ihtiyaç duyarlarsa, çoğu insan bunu biliyor ve neden yardımcı olduğu konusunda ortak bilgi).

1
James

Ortak dosyalarda çalışırken, bir şekilde siz veya ekip arkadaşlarınızın birleştirme işlemi bitmeden önce tüm çakışmaları çözmeniz gerekir, bu nedenle ilk etapta lütfen üzülmeyin. Hâlâ proje çalışması yapıyorsunuz ve çalışmalarınızdan gurur duyuyorsunuz. Şimdi daha akıllıca bir hamle yapmak için aşağıdaki önerileri takip edebilirsiniz.

  1. Görevleri bağımsız olarak bölme:

    İşinize başlamadan önce, tüm görevleri her ekip üyesi için verilen görev mümkün olduğunca bağımsız ve modüler olacak şekilde planlayın ve bölün (geliştirirken olası çatışmalardan kaçınmak için). Scrum liderine acemi olduğunuzda sizin için bazı bağımsız görevler atamak üzere yaklaşabilirsiniz.
  2. Taneli sık taahhütleri birleştir:

    Son öfkeden önce tüm görevin tamamlanmasını beklemeyin. Tabii ki daha büyük görevler birden fazla alt göreve ayrılabilir. Bu nedenle, daha iyi yaklaşım, daha büyük alt görevler için daha küçük taahhütleri aynı anda sık sık birleştirmektir.
  3. Şubenizi sık sık ısıtın:

    Uzak şubenizle yerel şubenize sık sık rebase uygulaması yapın. Yerel şubenizi uzak bir şubeyle sık sık yeniden birleştirmek için aşağıdaki komutu kullanabilirsiniz,

    git pull --rebase #or
    git pull --rebase Origin dev #when dev is remote branch
    

    Şimdiye kadar en yararlı git benim yaşamımda benim için komut.

  4. Takım arkadaşlarıyla yakın çalış:

    Ortak görevde takım arkadaşınızla gerçekten paralel olarak çalışmanız gerekiyorsa, lütfen birlikte çalışın. Siz acemi olduğunuz ve bir uzman olduğu için karmaşık çatışma çözümlerinden kaçınmak için bir süre bekleyebilir.

  5. Git seçenekleriyle alış:

    Git birleştirme araçlarının gücünü kullanın. Birleştirme sırasında çakışmaları çözmenin birçok uygun yolu vardır. Birleştirme stratejileri bazen çok yardımcı olabilir. Git komutlarıyla ve korkusuz alışık olun.

1

Geliştirme şubenizden 'git fetch' (git pull değil) komutunu düzenli olarak (günlük) çalıştırmalısınız. Bu, diğer insanların değişiklik yapmalarını sağlar ve değişiklikleri kendi şubenize entegre etmeye çalışmadan özellik dalınıza getirir.

Bu, baş geliştirici ile konuşmanız gereken bir şeydir (mutlaka yöneticiniz değil), çünkü şirketinizin kendi standartları veya bu sorunu ele almanın önerilen yolları olabilir; çok yaygın. Gelecek haftaya kadar beklemeyin - işlemi şimdi öğrenin ve süreci test edebilmeniz için bazı önemsiz işler (kod biçimlendirme veya yorum ekleme gibi) yapıp yapamayacağınızı sorun.

1
PeteCon