Yeni geliştirici şube birleşmelerine ayak uyduramaz

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

Benim sorunum şudur: Kullanıyoruz git- Şubemizden bir dal kestim develop, sonra atandığım küçük görev üzerinde çalışmaya başladım. Çok yavaş, çünkü deneyimsizim. Şubemi developbaşkalarıyla yeniden birleştirmeye hazır olduğumda , çatışmaları çözmenin çok zor olduğu pek çok değişiklik yaptım (işimi hurdaya çıkarmak ve elbette sürdürülebilir bir çözüm olmayan bu işe başlamak daha kolay görünüyor. ).

Bunun üstesinden nasıl gelebilirim? 'Kodlamada daha iyi olmak' dışında kullanabileceğim bir taktik var mı? Bunu gelecek hafta amirime getirmek niyetindeyim.

Şubenizde yaptığınız değişiklikler meslektaşlarınızın developşubede yaptıkları değişikliklere yakınsa, yani siz ve meslektaşlarınız aynı dosyadaki aynı kod satırlarını veya bitişik satırları değiştirdiyseniz, birleştirme çatışmaları elde edersiniz .

Böylece, birleştirme çatışmalarının olasılığını azaltmak için, meslektaşlarınızın bu arada daha az sayıda satır değiştirmesi için daha erken birleştirme yapmaya çalışabilirsiniz veya daha az satırları kendiniz değiştirmeyi deneyebilirsiniz.

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

Amacınıza ulaşmak için farklı yollar denemeniz gerekirse, belki de bazı deneyleriniz değişmesi gerekmeyen çizgileri değiştirdi? Birleştirmeden önce bu değişiklikleri geri alın.

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

• git diffve git diff --stagedhangi çizgileri değiştirdiğinizi görmek için.
• git add -p değişikliklerinizi yalnızca bir dosyaya eklemek için
• git commit --amendve git rebase -iince ayar yapmak için, yerel özellik şubenizde yapmış olduğunuz taahhütleri diğer Git havuzlarına göndermeden önce yapın.

(Mümkün olduğunca az çizgiler değiştirilmesi daha kolay çalışmanızı incelemek veya örneğin taahhüt arasındaki farklar hakkında uygun araçları kullanma yapabilir git cherry-pick, git rebase, git bisect, ve git blame.)

Ancak birleştirme çatışmaları olasılığını azaltsanız bile, bazen birleştirme çatışmalarıyla karşılaşacaksınız. Bu yüzden onlardan korkma, ama çatışmaları nasıl çözeceğini öğren.

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

Her gün çalıştırıyorsanız, muhtemelen etkileşimli bölüme ihtiyacınız olmayacak. Sadece onun işini yapmasına izin ver.

Oldukça deneyimli bir geliştiriciyim ve yeni bir projeye ayak uydurmam biraz zaman alıyor. Sizin durumunuzda, aynı proje üzerinde aynı anda çalışan birkaç kişi aynı anda çalışıyor gibi görünüyor, bu yüzden ya çok büyük bir proje ya da hızla gelişen yeni bir proje. Her iki durumda da, akışa girmeniz birkaç ay sürerse endişelenmeyin . Projeleri 2 veya 3 hafta değiştirip sonra da geri çevirirsem,% 100 tek başıma yazdığım bir projeye tamamen geri dönmem birkaç saat alabilir (veya bir veya iki gün bile)!

Kısacası, şu anda yavaş olmaktan korkma. İyileşmenin yolu, pratik yapmaya devam etmektir. Diğer geliştiricilere anlamadığınız projelerin yönlerini sormaktan korkmayın.

DÜZENLE:

Veya kullanın merge. Bu da bir seçenek. Dolayısıyla, yukarıdakiler şöyle olacaktır: " git rebase -i( -ietkileşimli araçlar) veya git merge". Hangisini kullanacağınızla ilgili olarak, ekibinizin geri kalanıyla konuşun. Her iki şekilde de güçlü tercihleri ​​olabilir (veya olmayabilir). Bazı millet açık mı güçlü tercihleri var.

Bu, şirketin tarafındaki kötü yazılım mühendisliğinin bir işareti olabilir. Çok fazla karşılıklı bağımlılık, örtüşen özelliklere sahip farklı konular, yanlış sırayla sorunları çözme teşebbüsü vb. Açıkladığınız duruma neden olabilir. developGelişim sırasında şubenize düzenli olarak katılmanızı öneririm

Bence kabul edilen cevaplar teknik olarak "Git'i nasıl daha iyi kullanmalı" bir teknik değil, bunun bir mühendislik probleminden ya da takım probleminden çok bir takım problemi olduğunu düşünüyorum.

Çok fazla bir birleştirme çatışmasıyla karşılaşıyorsanız, bu, siz ve takımdaki bir başkasının ayak parmaklarına bastığınız anlamına gelir.
Siz veya onlar kodlarken kişisel alan geliştirmeyi hedeflemeli ve zaten meşgul olan alanlarda çalışmaktan kaçınmalısınız.

Benim takımımda, yüksek derecede bir görev sahipliği eğilimindeyiz.
Genelde bir seferde iki veya üç dosyanın tam ve eksiksiz sahipliğini alıyorum ve en fazla bir veya iki gün boyunca bir dalda çalışacağım.
Genellikle bu dosyalara başka biri dokunursa, yalnızca kendi görevleri için kesinlikle gerekliyse, genellikle aynı görev bloğunda birlikte çalışmaz!

Çok fazla birleştirmek zorunda olduğunuzu buluyorsanız, o zaman ya tüm ekip kodunuz tek bir yerde (bu kendi içinde kaçınmanız gereken bir şeydir) ya da tüm görevlerinizdir.

Tüm bunlar, yeni bir dev olarak muhtemelen herhangi bir yeniden yapılanmayı zorlama, talep etme ve hatta gerçekten önerme konumunda bulunmuyorsunuz.
Beklediğim şey, görevlerinizin sizi takımda rahatlatmak için beceri seviyenizde makul bir şekilde ulaşılması gereken "halatları öğren" maddeleri olarak atanmış olması. Muhtemelen hala aynı alanda çalışan bir iş arkadaşının görevlerinden çıkarılmışlardır, bu nedenle birleştirme çatışmalarınız.
O zaman bunun çözümü sorunu çözmek, problemleri çözmek, elinizden geldiğince birleşme çatışmalarıyla baş etmek ve çok fazla endişe etmeyin, elinizden gelenin en iyisini yaptığınız sürece endişelenmek menajere kalmış olur. Senin ilerlemen.
Gittikçe daha hızlı ve daha güvenli olacaksın,

Birleşmeyle ilgili en önemli şey ne kadar uzun beklerseniz o kadar acı verici olur. Ve problem lineerden daha fazla büyüyor. Çatışmaların üç katı, çatışmaların dokuz katıdır. Bazı stratejiler var:

Ne zaman değiştiğinde gelişme dalıyla birleş, böylece her zaman ona yakın olursun ve asla çok fazla çatışmaların olmaz.

Uzun zaman alırsanız, bunun nedeni zamanın çoğunu değişikliklerin ne olduğunu bulmak için harcadığınız ve ardından değişiklikleri uygulamak için az miktarda bir zaman harcadığınız olabilir. Bu durumda, gerçek kod değişikliklerine başlamadan önce geliştirme şubesiyle birleştirme.

Çatışmalardan kaçınma stratejileri hakkında meslektaşlarınızla konuşun. İki kişi aynı kodu düzenlerse çakışma yaşarsınız. Sadece aynı dosya değil aynı kod. Bu yüzden yeni bir fonksiyon fonksiyonuA'ya ihtiyacım var ve yeni bir fonksiyon fonksiyonuB'ye ihtiyacınız var ve ikisini de aynı dosyanın sonuna ekliyoruz, bir çatışmamız var. Farklı yerlere eklersek, çatışma olmaz. Her ikimiz de dosyayı dosyaya mantıksal olarak ait olduğu bir yere eklersek, ihtimalimiz çatışmaz.

Çakışma varsa , iyi bir fark aracı edinin, böylece birleştirme işleminden önce geliştirme dalını, birleştirme işleminden önceki kodunuzu, orijinal kodunuzu ve birleştirilmiş kodunuzu karşılaştırabilir ve elle birleştirebilirsiniz.

En kötü durum: Çalışmanızı çöpe atmazsınız, ancak tam olarak hangi değişiklikleri yaptığınızı öğrenmek, tekrar gelişmek için dallanmak ve bunları yeniden yazmak yerine elle yaptığınız tüm değişiklikleri uygulamak için iyi bir fark aracı kullanın.

Zamanla dalımı tekrar gelişmeye birleştirmeye hazırım (benimkine önem verir)

Çatışmaların ele git mergealınması genellikle içeride olduğundan daha basittir git rebase. Git merge'de aynı anda değiştirilmiş dosyaların listesini görebilirsiniz. Diğer iş arkadaşları tarafından ne kadar taahhütte bulunulursa yapsın, bir kere birleşmen gerekecek . Rebase iş akışıyla, aynı çakışmaları tekrar tekrar ele geçirebilir ve manuel olarak gözden geçirmeniz gerekebilir. 13. taahhüdü tamamlamaya başlayabilir ve tünelden ışığı göremediğinizi hissedebilirsiniz .

Tecrübelerime göre, tekrarlanan yeniden kazanım çatışmalarını saf bir şekilde çözmeyi denediğimde, birinin değişikliklerini ya da derlemeyen bir uygulamayı kaybediyorum. Sık sık ben ve iş arkadaşlarım çok çalıştım, ancak tekrarlayan çatışmaların karmaşıklığı yüzünden öylesine şaşkına döndüm ki, bir miktar yeniden yapılanma taahhüdünün ardından önceki çalışmalarımızı iptal etmek ve kaybetmek zorunda kaldık.

Size birkaç teknik önereceğim ama onlar birleşmenin görevi otomatikleştirmekten daha kolay olmasına yardımcı olabilirler.

• Kaynak / dil dosyaları . Bir kaynak dosyasında ek değişiklikleriniz varsa , değişikliklerinizi başkalarının değişikliklerine karşı kolayca hatırlayabilmeniz için bunları her zaman dosyanın sonuna taşıyın . Değişikliklerinizi en alttaki kopyalayıp yapıştırabilir veya çakışma işaretleyicilerini kaldırabilirsiniz.
• Yap. Değil. KESİNLİKLE. YENİDEN biçimi . Ne siz ne de diğer geliştiricileriniz günlük çalışma sırasında "büyük kod reformat" ı yapamazsınız. Kod reformat, çatışma yönetiminde aşırı sayıda yanlış pozitif ekler. Kod reformat yapılabilir
  • Arttırıcı, örneğin her geliştirici tarafından, otomatik bir araç kullandıkları anda (örneğin Eclipse'in tasarrufta yeniden biçimlendirme seçeneği vardır, vanilya Visual Studio'da yoktur). Kesinlikle her geliştirici, IDE'niz tarafından yenilen bir format dosyasına kodlanmış aynı kod formatlama standartlarını kullanmalıdır. Size bir fikir vermek gerekirse, 4 boşluk veya 2 sekme olması farketmez, ama herkes aynı şeyi kullanıyorsa, gerçekten önemlidir.
  • Serbest bırakılmadan hemen önce, bir takım lideri tarafından. Eğer insanlar bir dal üzerinde çalışmadıklarında, yani bir daldan önce bir "kod reformat" taahhüdü gerçekleşirse işler daha kolay hale gelir
• İnceleme çalışanlar arasında çalışma bölme. Bu, çoğu mühendisliğin geldiği kısım. Diğer cevapların da belirttiği gibi, farklı işler yapan birden fazla geliştiricinin aynı kaynaklara dokunması gerekiyorsa, tasarım kokusudur. Her eş zamanlı geliştirici tarafından hangi bölümün değiştirileceği hakkında takım liderinizle görüşmeniz gerekebilir.

Ayrıca takımlarımdaki Git iş akışlarında bazı kötü alışkanlıklar gördüm. Genellikle insanlar şubelerine taşınır. Şahsen, her biri bir veya iki satırlık işleyen "düzeltme" etiketli 10 ila 20 komisyon ekleyen bir geliştiriciye şahit oldum. Politikamız, taahhütlerin size bir fikir vermek için JIRA biletleri ile etiketlenmiş olmasıdır.

@ JacobRobbins git rebasegünlük bir iş yapmayı önerir . Yaklaşımını ileri itmek istiyorum.

Öncelikle, taahhüt sayısını bir avuç seviyesine düşürmek için yeniden rebase kullanın. Ve sadece dallanmış olduğunuz taahhüt olan orijinal gelişme dalına yeniden yatırım yapın. Avuç deyince, 3 veya 4 (örneğin tüm ön uç, tüm arka uç, tüm veritabanı ekleri) veya insanca makul herhangi bir rakam anlamına gelebilir. Onları birleştirdikten sonra, yeniden fetcholuşturduğunuz alanı yukarı akış dalı üzerinde kullanın ve çalıştırın. Ekibiniz kendi yaklaşımlarını gözden geçirmedikçe, bu sizi çatışmalardan kurtarmaz, ancak hayatınızı daha az acı verici hale getirir.

Belirli görevler hakkında ek sorularınız varsa, arama yapmaktan ve Stackoverflow'tan sormaktan çekinmeyin.

Reformatsız ve izci kuralı hakkında [Düzenle]. RE-formatını , sizin anlamımın, sizin tarafınızdan dokunulmamış kod da dahil olmak üzere tüm kaynak dosyayı sıfırdan biçimlendirme görevi olduğunu vurgulamak için biraz eşleştirdim . Her zaman mükemmel bir çocuk izci olan kendi kodunuzu biçimlendirmenin tersine, kendim de dahil olmak üzere bir dizi geliştirici, dosyanın tamamını IDE'nin yetenekleriyle yeniden biçimlendirmek için kullanılır. Dosyaya başkaları tarafından dokunulduğunda, etkilenen satırlar içeriklerinde ve anlambilgilerinde değişmese bile Git dosyayı bir çatışma olarak görür. Yalnızca çok güçlü bir dil farkındalığı olan editör, çatışmanın yalnızca en iyi biçimlendirilmiş parçanın biçimlendirilmesi ve otomatik olarak birleştirilmesiyle ilgili olduğunu önerebilir. Ama böyle bir aracın kanıtı yok.

Ne de olsa, izci kuralı sizi diğer insanların pisliğini temizlemeye zorlamaz. Sadece senin.

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

İkincisi, çakışmaya neden olan dosyalar üzerinde çalışan bir kişi 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 ihtilaf varsa, göreviniz küçük fakat tekrarlayıcı olabilir. Bir model bulmaya çalışın. Bu, Git Kullanıcı Arabirimi istemci araçlarıyla çakışmaları çözmede yardımcı olur. TortoiseGit kullanıyorum. Birleşmeye yardımcı olur.

Ve gelecekte kaçınmak için,

• Gelişen şubeyi düzenli olarak özellik şubenizle birleştirmek çok iyi bir uygulamadır.

• CI'yi etkinleştirdiyseniz, CI aracının dal oluşturma sağlayıp sağlamadığını kontrol edin. Bu, özellik branşınızda yaptığınız her kontrolde, ancak birleştirme şubesinden sonra yapılmalıdır.

Geliştirme şubenizden düzenli olarak (günlük) 'git fetch' komutunu (git git değil) çalıştırmalısınız. Bu, diğer insanların değişime açık hale gelmesini sağlayacak ve değişiklikleri şubenize entegre etmeye çalışmadan onları özellik dalınıza getirecektir.

Bu, baş geliştiriciyle (mutlaka yöneticinizle değil) hakkında konuşmanız gereken bir şeydir, çünkü şirketinizin kendi standartlarına veya bu konuyu ele almanın önerilen yöntemlerine sahip olabilir; bu çok yaygın. Gelecek haftaya kadar beklemeyin - süreci hemen öğrenin ve bazı önemsiz çalışmalar yapıp yapamayacağınızı (kod biçimlendirme veya yorum ekleme gibi) isteyip istemediğinizi sorun. Böylece işlemi test edebilirsiniz.

Açıkçası ilk şey, birden fazla kişinin aynı dosyalar üzerinde ilk sırada, en azından zor çatışmalara yol açacak şekilde çalışmasını engellemektir. Numaralandırmalara bir şeyler eklemek, iyi bir kod formatı kullanıldığı sürece sorun olmaz. Kontrol akışını farklı şekillerde değiştirmek ve kodu hareket ettirmek çok daha zordur. Bazen bu yine de kaçınılmazdır. Gerçekten karmaşık olan ihtilafları çözerken sorular sormanız gerekecektir.

Bununla birlikte, düzenli olarak birleştirmek / yeniden inşa etmek için önerilen birçok cevabı görüyorum. Bu tür bir tavsiye konusunda daha az hevesli olurdum. Bu noktada hedefiniz, çatışma çözme sürecini mümkün olduğunca kolay ve güvenli hale getirmektir. Bu sürece çok büyük yardım edecek bir şey, yeni özelliğinizin bir parçası olan yeniler de dahil olmak üzere, derhal mevcut olan birçok regresyon testine sahip olmaktır. Şubenizi geliştirme ile çok düzenli olarak senkronize ederseniz, özelliklerinizi uygulamanın yarısı bittiğinde çatışmaları çözmek zorunda kalırsınız. Bu da, sizin yapmadığınız gibi, kodun ne yapması gerektiğini çözmeye çalışmaktan çok daha zor olacağı anlamına gelir. Birleşmeye çalışmadan önce, şubenizin tutarlı bir değişim birimi olduğundan emin olun. Daha iyi,

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

Şubemi tekrar geliştirmek için bir araya getirmeye hazır olduğumda, diğerleri çatışmaları çözmenin çok zor olduğu bir çok değişiklik yaptı.

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 zamanla kendi başınıza çalışmaktan hız kazanacaksınız, ancak o zaman gelene kadar göz korkutucu olabilir ve bazen de uzun sürebilir. Ayrıca, insanlar hızlı bir şekilde stresli bir ortamda bulunmayı her zaman yakalamak için baskı altında olsalar bile, sürekli baskı altında iyi öğrenmeyenler engellenecektir.

Bir dalda kendi başınıza çalışmak ve sizden çok daha hızlı olan diğer aygıtlara yetişmek yerine, bunun yerine doğrudan (aynı PC) başka bir aygıtla çalışırsınız. Bu yolla anında tavsiye alırsınız ve muhtemelen nasıl hızlandırılacağınızla ilgili ipuçları alırsınız.

Çiftli programlama bazı projeler için her zaman mantıklı gelmediğinden, projenizdeki belirli kod için en iyi yaklaşımı anladınız - her ne kadar oturuyorsanız ve sizden daha deneyimli birini izleseniz bile, her zaman öğrenme için mantıklı olabilir. (iyi bir geliştirici oldukları sürece, deneyim mutlaka iyi uygulamaları kullandıkları anlamına gelmez).

Daha hızlı, daha deneyimli bir dev ile oturmak size yardımcı olma potansiyeline sahiptir:

• Birleşme çatışmalarını daha deneyimli biriyle çalışmak, muhtemelen yalnız çalışmanızın aksine bitirme süresini artıracaktır.
• Size öğretecekleri için, tek başlarına çalışacaklarından daha yavaş olmaları muhtemeldir, bu yüzden hala bazı birleşme çatışmaları olabilir ve bu yüzden de tecrübeli birisiyle onlarla çalışabilir ve belki de zaman kazanma konusunda bazı ipuçları alabiliriz.
• Potansiyel püf noktaları ve daha hızlı olmanın yollarını görmenize yardımcı olun (yavaş olmak, bazen iyi uygulamaların eksikliğinden ziyade sadece deneyim eksikliğidir)
• Bir şey mantıklı gelmediğinde veya% 100 net olmadığında hemen soru sorabilir
• 1: 1'de çalışmak öğrenme için değerlidir, çünkü yardım isteyeceğiniz kişi üzerinde çalıştığı şekliyle tam kodu ve senaryoyu zaten anlar; çift programlamaya gerek kalmadan, genellikle bir soruna neden olan kodu ve senaryoyu açıklamanız gerekir. Böylece çok ihtiyaç duyulan tavsiyelere uyarak zaman / dikkatini yitirirsiniz.
• 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 gelecek hafta amirime getirmek niyetindeyim.

Benim tavsiyem, ikili programlamayı diğer aygıtlarla görüşmek ve daha sonra şefinize yaklaşmak. Eğer haklılarsa, çift programlamanın artılarını atmanız için daha fazla şansa sahip olan inisiyatifinizi takdir edeceklerdir (eğer ihtiyaç duyarlarsa çoğu insan bunu biliyor ve bunun neden yardım ettiği ortak bir bilgidir).

Burada birkaç temel sorun var. Birleşme sorunlarınız büyük olasılıkla sizin suçunuz değil ve daha çok kötü uygulamaların bir belirtisidir.

1) İdeal olarak, şubenizi her gün gelişmek üzere birleştirirsiniz. Tüm testlerden geçen en az günde bir kez çalışma kodunu almaya çalışın, böylece geliştirmeye devam edebilirsiniz.

2) Normal çalışma gününüz boyunca herhangi bir noktada çalışma kodunuz yoksa, üzerinde çalışmanız için çok büyük bir kod parçası vardır. Görevinizi birleştirebilmeniz için daha çabuk bitirilebilecek (birbirinden bağımsız olarak ideal) daha küçük görevlere bölmeniz gerekir.

3) Projelerinizin dosyaları büyük olasılıkla çok büyük. Bir dosya için çok fazla 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ığı şeyden ayrı olmalıdır.

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

5) Tutarlı kod formatlama standartlarınız olmayabilir. Hepiniz aynı kod formatını tutarlı bir şekilde kullanmazsanız, aynı kod için birçok farklı çakışma elde edersiniz. Git'inizin nasıl ayarlandığına bağlı olarak bunlar beyaz boşluk çatışmalarına (satır sonları, girinti, sekmeler ve boşluklar gibi) bile düşebilir.

6) İnsanlar değişikliklerini doğrudan geliştirme koluna itiyor olabilir.

İşte ne sen yapabilirsiniz: 1) siz) daha sık dal içine her gün geliştirmek (veya rebase / birleştirme, her gün geliştirmeye içine birleştirme yapamıyorsanız.
2) Kodunuzu her birinin kodundan ayrı tutmaya ç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 fonksiyonlar) hakkında konuşun.

İşimi hurdaya çıkarmak ve göreve baştan başlamak daha kolay görünüyor, ki bu elbette sürdürülebilir bir çözüm değil)

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

Ayrıca, biraz çalışmayı yinelediğimde daha iyi kod yazdığımı da biliyorum.

Bu nedenle, ustadan yeni bir şube oluştururken, yaptığınız işi tekrar yaparak, "özel şubenizi" yapmanız gerektiğini size hatırlatmak için yanlış bir şey yoktur.

Değişikliğinizi her biri bir kez tamamlandıktan sonra ana dalda birleştirilen mantıksal ve doğru parçalara bölmenin bir yolunu bulmuş olabilirsiniz. Örneğin, birim testleri ve arka uç kodunda yapılan değişiklikler yapılabilir ve birleştirilebilir. Daha sonra ayrı bir işlemde, bunlardan yararlanan kullanıcı arabirimi değişikliklerini yapabilirsiniz, dolayısıyla aynı kullanıcı adını düzenleme başka birinin daha az riski vardır.

Geliştirme şubesini şubenizde çok sık birleştirmek istemiyorsanız, svn'ye benzer bir iş akışı elde edebilirsiniz git pull --rebase. Bu, yeni taahhütleri çekecek ve taahhütlerinizi onlara geri çekecektir. Bu, şubenizi geliştirmek için birleştirdiğinizde, ileriye dönük bir birleştirme olur (sanki tüm taahhütlerinizi birbiri ardına aynı anda eklerdiniz) ve herhangi bir birleştirme çatışmalarına sahip olmazsınız çünkü git pull --rebase.

Ancak, şubenizi geliştirmek veya geliştirmek için şubenizi bir araya getirmeden önce ne kadar taahhüt ederseniz, bir sonraki rebase ne kadar karmaşık olursa o kadar karmaşıklaşacaktır ki, şubeniz yalnızca henüz çözülmediği sürece, özellik-dallanma hissini biraz daha altüst eder. .

Ortak dosyalarda çalışırken, siz ya da ekip arkadaşlarınızın birleşme bittikten önce tüm çatışmaları çözmeniz gerekir, bu nedenle ilk etapta lütfen üzülmeyin . Hala proje çalışması yapıyorsunuz ve çalışmalarınızla gurur duyuyorsunuz. Şimdi daha akıllıca bir hareket yapmak için aşağıdaki bazı önerileri takip edebilirsiniz.

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

   Çalışmanıza başlamadan önce, bütün görevleri her ekip üyesi için verilen görevin mümkün olduğu kadar bağımsız ve modüler olacak şekilde planlayın ve bölün (geliştirirken oluşabilecek olası çatışmaları önlemek için). Sizin gibi acemi sizin için bazı bağımsız görevleri atamak için scrum liderinize yaklaşabilirsiniz.

2. Birleştirme granüler sıklıkta taahhüt:

   Son görevden önce tam görev tamamlanmasını beklemeyin. Elbette daha büyük görevler birden fazla alt görevlere ayrılabilir. Bu yüzden daha iyi bir yaklaşım, aynı zamanda aynı anda daha küçük alt görevler için daha küçük taahhütleri bir araya getirip, toplu uyuşmazlık çözümünden kaçınmaktır.

3. Şubenizi sık sık yeniden açın:

   Uzak olanı ile yerel şubenize sık sık yeniden yapma uygulaması yapın. Uzaktaki bir yerel şubenizi sık sık yeniden açmak için aşağıdaki komutu kullanabilirsiniz,

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

   Bu benim gelişim hayatımda benim için en faydalı git buydu .

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

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

5. Git seçenekleri ile alışmak:

   Git birleştirme araçlarının gücünü kullanın. Birleşirken çatışmaları çözmenin birçok uygun yolu var. Stratejileri birleştirmek bazen çok yardımcı olabilir. Git emirlerine alış ve korkusuz ol