Yaklaşık on kişilik dokümantasyon ekibimiz yakın zamanda SVN'den Git'e taşındı. SVN'de herkes usta üzerinde çalıştı - her zaman nefret ettiğim bir model, ama bu değişikliği yapamadım. Git'e taşınmanın bir parçası olarak bunu düzeltmeye karar verdik, ancak henüz bunu yapamıyoruz (yapıların keyfi dallardan oluşmasına izin verecek derlemeleri beklemek). Bu arada, herkes usta üzerinde çalışıyor. Evet bunun korkunç olduğunu biliyorum, inan bana.

Şimdi Git'in iki aşamalı modelinin (yerel ve uzak) neden olduğu SVN kullandığımızdan çok daha fazla hıçkırık görüyoruz. Bazen insanlar taahhüt eder ancak itemezler ya da bekleyen yerel değişikliklerle çatışmalar kurarlar. Dün biri, son değişiklikleri değiştirdi - bir şekilde - bir birleşme yanlış gitti, ki bence Git'i çekip olağanüstü değişiklikler yaptığınızda yaptığınız bir birleşme oldu. (Bana tam olarak ne yaptığını söyleyemedi ve bir GUI kullandığı için kabuk tarihini kontrol edemiyorum.)

En yetkin Git kullanıcısı olarak (okuyunuz: daha önce kullandım, süper karmaşık bir şey olmasa da), politika belirleyen, araçları öğreten ve karışıklıkları temizleyen kişi benim. Dalları geliştirmeye geçene kadar, paylaşılan, aktif bir efendiyi daha az hataya açık hale getirmek için bu araçları nasıl kullandığımız konusunda ne gibi değişiklikler yapabilirim?

Takım, Windows'ta Tortoise Git'i kullanıyor. Tortoise Git kullanıyoruz çünkü daha önce Tortoise SVN kullanıyorduk. ( Ben şahsen bazı işlemler için Cygwin komut satırını kullanın, ama takım temizleyinonlar bir GUI ihtiyaç ve biz bunu ile gidiyoruz yaptı.) Cevapları değiştirmeler önermemektedir, bu araç ile çalışmalıdır.

Kaplumbağa Git'in tek bir işlem olarak kullanılabilen "Teslim Et ve İttir" i var ve onlara her zaman yapmalarını söyledim. Ancak, atomik değil - bu (sonuçta yerel olanın) taahhüdünün sadece iyi çalıştığı, ancak itirazın (bir çatışma veya bir ağ sorunu nedeniyle) çalışmadığı anlamına gelebilir. Bu olduğunda, belirsiz bir hata alırlar; BitBucket işlem günlüğünü, yeni bir işlem hakkında herhangi bir şüpheleri olup olmadığını ve görmezlerse zorlamalarını kontrol etmelerini söyledim . (Eğer sorun buysa çatışmayı çözmek veya ne yapacaklarını bilmiyorlarsa yardım isteyin.)

Takımın zaten "erken ve sık çekme" gibi alışkanlıkları var. Bununla birlikte, çekilişin yeni olduğunu düşündüğüm çatışmalara neden olabileceği anlaşılıyor. Yeni değilse, SVN'den çok daha sık. Git'in nasıl çekileceğini değiştirebileceğimi duydum (birleştirme yerine yeniden yapılanma), ancak oradaki takasları (veya çevremizde nasıl yapabileceğimizi) iyi anlayamıyorum.

Sunucu BitBucket'tir (Github değil). Depomuz üzerinde tam yönetim kontrolüm var ancak sunucuda daha genel olarak yok. Bunların hiçbiri değişken değil.

Kaynak dosyalar XML'dir. Ayrıca, birleştirme yapamayacağınızı herkesin bildiği grafik dosyaları da var, ancak neredeyse hiç orada çarpışmalarımız olmadı. Birleştirme çatışmaları, grafiklerden değil XML dosyalarından gelir.

Git'i, paylaşım uzmanının ekip için daha sorunsuz çalışmasını sağlamak için gözden geçirilmiş, test onaylı çekme istekleriyle özellik dalları kullanmaya devam edene kadar ne gibi değişiklikler yapabilirim?

Şimdiye kadar SourceTree, kavramları öğrenmek için en iyi IDE idi, çünkü her aşamada sahip olduğunuz tüm ilgili diyalogları ve seçenekleri gösterir, varsayılan seçenekler genellikle iyidir, rebase ile uğraşmayın, vb. Normal akışı izleyin:

• Ustadan çekin, sadece güncel olduğunuzdan emin olmak için
• Dosyalarınızı değiştirin
• Değişikliklerinizi kabul edin (yalnızca yerel olarak)
• Master'dan tekrar çekin (bu, çatışmaların ortaya çıkmasına neden olur)
• Çakışmalar çözülene kadar tüm dosyaları düzenleyin; yani dosya, işlemek istediğiniz özellik konumunda (ham dosyada <<<<< HEAD ve >>>> ana iletiler yok)
• Birleştirme değişikliklerini kabul et
• it

Herkes bu tarifi takip ederse, iyi olmalı.

Ne zaman birisi daha büyük veya merkezi bir değişiklik yaparsa, diğer kullanıcıları yerel olarak işlem yapmaları ve ustalardan çekilmeleri konusunda bilgilendirir, böylece daha sonra çok fazla çatışma almazlar ve ilk kişi hala onlarla çatışmaları çözmek için buralardadır.

Herkesin akışı anlamasını sağlamak için çok zaman harcayın, aksi takdirde bir süre dolanabilir ve daha sonra ana şubeyi sıkıştırarak rahat hissedebilirsiniz, örneğin "uzaktan kumanda yerine dosyamı kullan" sadece bir çatışmayı çözmek için diğer insanlar tarafından yapılan tüm değişiklikleri dışarı.

Git, öğrenmesi zor bir sistemdir, özellikle de Svn ile büyüdüyseniz, sabırlı olun ve düzgün bir şekilde öğrenmeleri için onlara zaman verin, yeni kullanıcılarla bazen bir gün biraz karışıklığı temizlemek için harcayabilirsiniz, bu normaldir. ;)

Aynı şubeden başkasıyla çalışırken, hatırlamanız gereken üç ana şey vardır:

• Asla kullanmayın --forceEğer sürece gerçekten ne yaptığınızı biliyorum.
• Ya commitda stashçalışmalarınız her şeyden önce devam ediyor pull.
• A'dan pullhemen önce yaparsanız genellikle daha kolay olur push.

Bunun dışında, dağıtılmış versiyon kontrolü ile "resmi" deponuzun şubeleri kullanıp kullanmamasının önemi olmadığını belirteceğim. Bu, bireysel kullanıcıların yerel depolarında ne yaptıklarına dair hiçbir önemi yoktur. Şirketim tamamen farklı bir merkezi VCS kullandığında yerel şubeleri almak için git'i kullanırdım. Özellikleri için yerel dallar oluştururlar ve yerelleriyle birleştirme hataları yaparlarsa master, yeniden günlüğe veya başka sihirlere girmeden düzeltmeleri çok daha kolaydır .

Herkesin git öğrenmesi için bir gün sürmesi mümkün mü?

Profesyonelleri kullanan bilgisayarlardan gerçekten yeni bir araç öğrenmesi beklenmeli ve herhangi bir VCS'de birçok hata yapabilmek mümkün olsa da aracı kullanmak için tasarlandığı gibi kullanması gerekir.

Bunu tanıtmanın en iyi yolu, her birinin bir değişiklik yaptığında (mümkün olduğu kadar kısa) kendi branşında çalışmalarını sağlamak ve yeniden yaptıklarında daha sonra yeniden yapıldığında ustayla birleşmektir. Bu, mevcut çalışma şeklinden çok uzakta değildir ve daha karmaşık işlemler yapacak kadar güvende hissedinceye kadar alışabilecekleri basit bir iş akışı sunar.

Pencereleri kullanmıyorum ama eğer Kaplumbağa temel olarak onlardan saklıyor ve SVN gibi davranıyorsa, belki de Kaplumbağa yanlış bir araçtır.

Bazen yaptığınız şeyin değişmesi gerekir.

En büyük sorun herkesin olmasıdır edilir usta üzerinde çalışıyor. Bu, kod geliştirme için tipik değildir ve sizin durumunuzda da yanlış model olabilir. Bunu değiştirebilirseniz, değişikliklerin ayrı dallarda yapılmasını isteyerek / talep ederek, daha iyi durumda olacaksınız. Şubelerle aşağıdakileri kazanabilirsiniz:

• Doğrudan baskı yapılmasına masterizin verilmemesini zorunlu kılın .
• Bitbucket aracılığıyla, çekme isteklerinin oluşturulup birleştirilmeden önce en az bir onay almasını sağlayın . Bu, kullanıcının değişikliklere bakmasını sağlar ve ayrıca kullanıcı masaüstünde ne olursa olsun UI, kodun uzak sürümüyle çakışmalar göstereceğinden birleşmenin kendisini daha az acı verici hale getirir. Bu, başarılı olmuş, ancak başarılı olmayan senaryoyu önler.
• Birleştirme işleminden önce reponuza "yapı" oluştur. Bunun bir belge deposu olduğunun farkındayım, ancak belki de bu derlemeden oluşturulabilecek yazım denetimi, hukuki kazıma veya otomatik çeviri (STRING_DEF şeylerini bir csv dosyasına aktarma) olabilir. Ya da belki değil, işinize bağlıdır.
• İnsanların aynı anda daha kolay bir şekilde birçok farklı şey üzerinde çalışmasına izin verin. Evet, bu da zula ile yapılabilir, ama bu biraz dağınık ve bir şey de bunları kullanmadığınızı söylüyor.

Eğer değilse olamaz dallanma kullanmak, bir yazma düşünebilirsiniz merge-and-pushuzakta ağrı noktalardan bazılarını otomatikleştirebildiğiniz senaryoyu. Belki kullanıcının ustada kalmadığını kontrol eder, bir alma ve çekme yapar ve sonra birleştirme girişiminde bulunur ( muhtemelen ile--no-commit --no-ff ), vb.

Birleştirmeleri yineleyebileceğinizi vurgulayın

Sizin için açık olabilir, ancak eski SVN kullanıcıları bir birleştirme işlemini birden çok kez çözmeye çalışabileceklerinin farkında olmayabilir. Bu, aldığınız yardım bayraklarının sayısını azaltabilir.

Çalıştığınız zaman trunkSVN'de etrafta oturmadan kayıtsız şartsız değişiklik yapmanız gerekirdi. O zaman bir yaparsın svn update. Bu noktada değişiklikleriniz sonsuza dek diğer insanlarla değişecektir. Geri almanın bir yolu yoktu (afaik), bu yüzden her şeyi manuel olarak kontrol etmekten ve deponun iyi durumda olduğunu ummaktan başka seçeneğiniz yoktu. Ne zaman gerçekten birleşmeyi tekrar yapmak çok daha rahat olurdu.

Gittiğimizde bile insanlar aynı zihniyete sahip olacaklardı. Çok fazla istenmeyen hataya yol açıyor.

Neyse ki git ile geri dönmenin bir yolu var, çünkü özellikle yerel taahhütlerde bulunabilirsiniz. (Komut satırında bunun nasıl ifade edildiğini daha sonra açıklayacağım)

Bu nasıl yapılsa da, alete göre değişecektir. Bir çekmeyi yinelemenin çoğu GUI'de tek bir düğme olarak görünmediğini, ancak muhtemelen mümkün olduğunu tespit ediyorum. Cygwin'i kullanmanı seviyorum. İş arkadaşlarım sourcetree kullanıyor. BitBucket kullandığınızdan beri aynı şirket tarafından yönetildiği için bunu GUI'niz olarak kullanmak mantıklı olacaktır: Atlassian. Daha sıkı bir entegrasyon olduğundan şüpheleniyorum.

Çekme ile ilgili olarak

Sanırım birleşmenin pullinsanları neyin mahvettiği konusunda haklısın . A pullaslında git fetchdeğişiklikleri sunucudan alan ve ardından git merge origin/<branchname>uzaktan değişiklikleri yerel şubenizde birleştiren * ifadesidir. ( https://git-scm.com/docs/git-pull )

Sonuçta tüm standart birleştirme komutları pull ile çalışır. Bu birleştirme çatışmalar varsa tarafından iptal edebilirsiniz git merge --abort. Hangi birleşmeden önce seni geri götürmeli. Sonra ya git pullda ile tekrar deneyebilirsiniz git merge origin/<branchname>.

Bir şekilde iş arkadaşlarınızın GUI seçim aracını kullanarak yukarıdakilerin nasıl yapıldığını öğrenebilirseniz , sorunlarınızın çoğunu çözeceğini düşünüyorum. Üzgünüm, daha spesifik olamam.

* Kökeninin burada her zaman böyle olmadığını anlıyorum.

git reflogSorunları teşhis etmek için kullanın

Sizin gibi, çoğunlukla GUI araçlarının kötüye kullanılmasıyla yaratılan sorunları teşhis etmek zorundayım. Bunun git reflogbazen depodaki eylemlerin oldukça tutarlı bir izi olduğu için yardımcı olabileceğini düşünüyorum. Zaman zaman okumak zor olsa da.

Bir alternatif

Durumunuz geçici olduğu için , devam edecek süreci gerçekleştirene kadar SVN'ye geri dönebilirsiniz. “Gitmeyi bir kez denedik ama işe yaramadı…” diyerek birçok yerde devam ettiği için bunu yapmakta tereddüt ederdim ve asla geri almadım.

Diğer bazı yaygın geçiş problemleri

• İnsanlar sık ​​sık depolarını silip geri alırlar, depolarının kullanılamaz bir durumda olduğuna ikna olurlardı. Genellikle bu, yerel ve uzak farkın izini kaybetmekten kaynaklanıyordu. Hem GUI araçları hem de CLI bunu göstermede başarısız oluyor. CLI'de git log --decoratefarkları gözden geçirmenin en kolay yolunu buluyorum . Fakat işler ustada çok kıllı olursa (örneğin)git reset --hard origin/master

- Olası bir mekanizma, açık kaynak ekipleri bir çok benimsemiş olması, çatallaşma modelini kullanmaktır https://www.atlassian.com/git/tutorials/comparing-workflows bir çatallaşma git iş akışı tartışırken (açıkça enunciate emin olun ) .

Bu geliştiricinin veya alt ekibin, BitBucket'ten teslim aldıkları depo çatalları vardır , bunun için bir mekanizma sağlarlar , varsayılan uzaktan kumandaya ek olarak "yukarı akış" kökeni ayarlarlar - yukarı akış getirmeyi "hatırlamaları gerekir" "ve" Remote / Upstream / Master'ı düzenli aralıklarla birleştirir.

Yapı araçları, ustaya farklı bir projede, yani çatalda gösterileceği için yapı mekanizma problemlerinizi çözecektir.

Daha sonra birçok insandan doğrudan ana projeye itme yeteneğini kaldırabilir ve rolleri gözden geçirip onaylayan daha küçük bir insan ekibi oluşturabilirsiniz. Bkz https://www.atlassian.com/git/tutorials/making-a-pull-request

İstenilen kontrollerin itten hemen önce yapılmasını sağlamak için okunacak yer kancalar üzerindeki git kitabı bölümündedir - https://git-scm.com/book/gr/v2/Customizing-Git-Git-Hooks - İşin geçerli olmasını sağlamak için önerilen taahhüt üzerinde bazı testler yapmak gibi şeyler yapmak için ön işleme ve ön itme kancalarını kullanabilirsiniz. - Müşteri tarafı kancalarıyla ilgili tek sorun, geliştiricilerin onları devre dışı bırakabilmesi veya etkinleştirememesidir. onlar.

Her iki yukarı akış alma / birleştirme ve kancalar TortoiseGit'te mevcuttur.

Bu, sezgisel görünmeye başlayacak ama beni duyun:

Git ile deneme yapmaya başlamak için onları teşvik edin.

Git hakkındaki ilginç şeylerden biri, herhangi bir yerel operasyonu tamamen güvenli hale getirmenin şaşırtıcı derecede kolay olmasıdır. Git'i ilk kullanmaya başladığımda, kendimi yaparken bulduğum şeylerden biri, bir şeyi mahvetmeme ihtimaline karşı tüm dizini yedekleme olarak sıkıştırmaktı . Daha sonra bunun çok büyük bir kirlilik olduğunu ve işinizi korumak için neredeyse hiç gerekli olmadığının farkına vardım, ancak ne haltında olduğunuzu ve ne yaptığını bilmiyor olsanız bile, çok güvenli ve çok basit olma erdemine sahip Denemek istediğiniz komut çıkacaktır. Bunu yaparken kaçınmanız gereken tek şey push. Hiçbir şeyi zorlamazsanız, istediğiniz herhangi bir şeyi denemek için% 100 güvenli bir yoldur.

Bir şeyler denemekten korkma, gitmeyi öğrenmenin en büyük engellerinden biridir. Size göz korkutucu olan her şey üzerinde çok fazla kontrol sağlıyor . Gerçek şu ki, günlük kullanımınızın çoğu için birkaç güvenli operasyona sadık kalabilirsiniz, ancak bunların hangi komutları araştıracağını bulmak biraz daha zor.

Onlara bir güvenlik hissi vererek , işleri kendi başlarına nasıl yapacaklarını çözmeye çalışmaktan çok daha istekli olacaklar. Ve yerel makinelerinde kendileri için çalışan kişisel bir iş akışı bulma konusunda çok daha fazla güçlenecekler. Herkes aynı şeyi yaparsa yerel , yani yeter ki onlar ne standartlarına uymak gibi gayet itin . Onları böyle hissetmelerini sağlamak için bir işlem yapmadan önce tüm repoyu sıkıştırmayı alırsa, sorun değil; bir şeyler yaptıkça ve bir şeyler denedikçe daha iyi şeyler yapabilecekler. Bir şeyleri denemeye ve ne yaptığını görmeye başlaman için.

Bu, eğitimin değersiz olduğu anlamına gelmez. Aksine, eğitim size özellikleri, kalıpları ve normları tanıtmada yardımcı olabilir. Ancak , günlük işinizde oturup oturup bir şeyler yapmak yerine geçmez . Ne git ne de SVN sadece bir sınıfa girebileceğiniz şeylerdir ve o zamanlar hakkında her şeyi bilirsiniz. Onları tanımak için problemlerinizi çözmek için kullanmanız ve hangi özelliklerin hangi problemlere daha iyi uyması gerektiği.

Git ve gitmeyi öğrenmek için cesaretini kırmayı bırak.

Hiçbir şeyi zorlamamaktan bahsettim, bu aslında onlara öğrettiğiniz şeylerden birine karşı geliyor: her zaman "Taahhüt & İttir" e. Onlara bunu yapmalarını söylemeyi bırakıp tam tersini yapmalarını söylemelisiniz. Git temelde değişikliklerinizin yapılabileceği 5 "yere" sahiptir:

• Diskte, kaydedilmemiş
• Aşamalı ancak taahhüt edilmedi
• Bir de yerel işlemek
• Yerel bir depoda
• Uzaktan depolar (Yalnızca taahhütler ve etiketler hiç farklı havuzlar arasında itilir ve çekilir)

Her şeyi tek bir adımda çekip itmeye teşvik etmek yerine, bu 5 farklı yerden yararlanmaya teşvik edin. Onları cesaretlendirin:

• Bir şey yapmadan önce değişiklikleri al.

• Bir Make kararı getirilen değişikliklerin nasıl işleneceğini. Seçenekler:

  • Yerel değişikliklerini tamamlayın, ardından alınan değişikliklerin üstüne yeniden ekleyin.
  • Yerel değişikliklerini kabul et ve ardından getirilen değişikliklerle birleş.

  • Değişikliklerini saklayın, birleştirin ve ardından çakışmaları düzeltin ve çözümleyin.

    Başka şeyler var, ama buraya girmeyeceğim. Bir çekme, kelimenin tam anlamıyla sadece bir getirme ve birleştirme olduğunu unutmayın. Onlar gibi değil; o ise onları. ( --rebaseDeğişikliklerin yapılması, getirme + birleştirme'den getirme + yeniden oluşturmaya çekmek için geçerlidir.)

• Değişikliklerini yapın ve ardından gözden geçirin.
• Aşamalı değişikliklerini yapın ve ardından taahhüdü gözden geçirin.
• Ayrı olarak itin.

Bu, çalışmalarını herkese açık hale getirmeden önce çalışmalarını kontrol etmelerini teşvik eder , bu da hatalarını daha erken yakalayabilecekleri anlamına gelir. Taahhütlerini görecekler ve “Bekle, istediğim şey bu değil” diye düşünecekler ve SVN'den farklı olarak, itmeden önce geri dönüp tekrar deneyebilirler.

Değişikliklerinin nerede olduğunu anlama fikrine alıştıktan sonra, adımların ne zaman atlanacağına ve belirli işlemlerin ne zaman birleştirileceğine karar vermeye başlayabilirler (ne zaman çekilmesi gerektiğine, ne zaman çekmek istediğinizi biliyorsunuzdur; .

Bu aslında Git'in SVN üzerindeki muazzam faydalarından biri ve git bu kullanım şekli göz önünde bulundurularak tasarlandı . Buna karşılık SVN, merkezi bir depoya bürünüyor, bu nedenle git için kullanılan takımın aynı iş akışı için optimize edilmiş olması şaşırtıcı değil. SVN'de, taahhüdünüz yanlışsa, tek gerçek başvurunuz yanlışlığı gidermek için yeni bir taahhüttür.

Bunu yapmak aslında doğal olarak bir sonraki stratejiye yol açacaktır:

Yerel şubeleri kullanmalarını teşvik edin

Yerel şubeler aslında paylaşılan dosyalar üzerinde çalışmanın acı noktalarını çok kolaylaştırıyor. İstediğim tüm değişiklikleri kendi şubemde yapabilirim ve onları zorlamadığımdan hiç kimseyi etkilemeyecek. Sonra zaman geldiğinde, aynı birleştirme ve yeniden pazarlama stratejilerinin hepsini kullanabilirim, ancak daha kolay:

• Yerel şubemi yeniden değerlendirebilirim, bu da onu ustaca önemsiz hale getirdi.
• Yerel şubemin değişikliklerini buna dahil etmek için ustada düz bir birleştirme (yeni bir taahhüt oluşturma) kullanabilirim.
• Şubeumun kurtarılması zor bir durum olduğunu düşünüyorsanız, tüm yerel şubemi ustalıkla tek bir bağlılıkla birleştirebilirim.

Yerel şubeleri kullanmak da sistematik bir dallanma stratejisi bulmak için iyi bir başlangıçtır. Kullanıcılarınızın kendi dallanma ihtiyaçlarını daha iyi anlamalarına yardımcı olur, böylece herkesin duyduğu için Gitflow'a düşmek yerine ihtiyaçlara ve ekibin mevcut anlayış / beceri seviyesine dayalı bir strateji seçebilirsiniz.

özet

Kısacası, git SVN değildir ve böyle davranılamaz. Gerek:

• Güvenli denemeyi teşvik ederek korkuyu ortadan kaldırın.
• Git'in ne kadar farklı olduğunu anlamalarına yardımcı olun ki normal iş akışını nasıl değiştirdiğini görebilsinler.
• Sorunlarını daha kolay çözmelerine yardımcı olmak için mevcut özellikleri anlamalarına yardımcı olun.

Tüm bunlar , bir dizi standardı uygulamaya başlayabileceğiniz noktaya ulaşana kadar giderek daha iyi git kullanımını benimsemenize yardımcı olacaktır .

Spesifik özellikler

Kısa vadede, aşağıdaki fikirler yardımcı olabilir.

rebase

Rebase'den bahsettin ve sorunda gerçekten anlamadın. İşte benim tavsiyem: az önce tarif ettiğim şeyi deneyin. Bazı değişiklikleri yerel olarak uygulayın, bir başkası bazı değişiklikleri zorladı. Değişikliklerinizi yerel olarak taahhüt edin . Depo dizininizi yedekleyin. Diğer kişinin değişikliklerini al. Şimdi bir rebase komutunu çalıştırmayı deneyin ve taahhütlerinize ne olacağını görün! Sonsuz blog yayınları okuyabilir veya yeniden düzenleme ve nasıl kullanmanız gerektiği veya kullanmaması gerektiği konusunda eğitim alabilirsiniz, ancak bunların hiçbiri, canlı yayınlandığını görmek için bir yedek değildir. Öyleyse dene .

merge.ff=only

Bu kişisel zevk meselesi olacak, ama en azından geçici olarak, anlaşmazlığı gidermekle ilgili sorunların olduğunu söylediğinden beri tavsiye edeceğim. Ben tavsiye ayarı merge.ffiçinonly :

git config --global merge.ff only

"ff" "hızlı ileri" anlamına gelir. Hızlı ileri birleştirme, git'in farklı komisyonlardan gelen değişiklikleri birleştirmesi gerekmediği zamandır. Şube işaretçisini grafikteki düz bir çizgi boyunca yeni bir işleme doğru hareket ettirir.

Bunun pratikte yaptığı, git'in otomatik olarak birleştirme komisyonları oluşturmaya çalışmasını önlemektir. Bu nedenle, yerel olarak bir şey taahhüt edersem ve ardından bir birleştirme taahhüdü oluşturmaya çalışmak yerine (ve kullanıcıyı potansiyel olarak çakışmalarla başa çıkmaya zorlamak yerine) başka birinin değişikliklerini kabul edersem, birleştirme başarısız olur. Aslında, git yalnızca bir a gerçekleştirmiş olacak fetch. Yerel bir taahhüdünüz yoksa, birleştirme normal şekilde ilerler.

Bu, kullanıcılara birleştirme girişiminde bulunmadan önce farklı taahhütleri gözden geçirme şansı verir ve onları birleştirmenin en iyi şekilde nasıl ele alınacağına dair bir karar vermeye zorlar. Yeniden git merge --no-ffyapılandırabilir , birleştirme işlemine devam edebilir ( yapılandırmayı atlamak için kullanarak ), veya şimdilik değişikliklerimi birleştirmeyi bırakıp daha sonra halledebilirim. Bu küçük hızlı çarpma ekibinizin birlikler hakkında yanlış kararlar vermekten kaçınmasına yardımcı olacağını düşünüyorum. Birleşmeleri idare etmede daha iyi olduklarında ekibinizin kapanmasına izin verebilirsiniz.

Şirketimde aynı SVN -> git deneyiminden geçtim ve deneyimlerime göre, tek çare zaman. İnsanların araçlara alışmalarına, hata yapmalarına, onları nasıl onaracaklarını gösterin. Hızınız bir süre acı çekecek ve insanlar işlerini kaybedecek ve herkes biraz tetchy olacak, ancak bu VCS'niz kadar temel bir şeyi değiştirmenin doğasıdır.

Bununla birlikte, TortoiseGit'in geçiş döneminin başlarında bir yardımdan ziyade bir engel olduğu görüşünde olan herkesle aynı fikirdeyim. TortoiseGit ... en iyi zamanlar için iyi bir GUI değildir ve git'in aslında basitlik adına nasıl çalıştığını gizleyerek iş arkadaşlarınızın iki aşamalı taahhüt gibi temel git kavramlarını anlamalarını önler.

Devs'i komut satırını (git bash veya posh-git ) bir hafta boyunca kullanmaya zorlama (oldukça sert) kararını verdik ve git'in gerçekte nasıl çalıştığını ve SVN'den nasıl farklı olduğunu anlamak için harikalar yarattı. Kulağa sert gelebilir, ancak basitçe denemenizi öneririm çünkü git modelini anlama anlayışı yaratır - ve bunu bir kez yaptıklarında, iş arkadaşlarınız gitmeden önce GUI cephelerini kullanmaya başlayabilirler.

Son not: Git'in neredeyse nasıl çalıştığını anlatan iş arkadaşlarınız olacak ve hiç çalışmayanlar olacak. İkinci grup, kodlarının yerel makineden sunucuya geçmesini sağlamak için mistik teşvikler öğretmeniz ve böylece herkesin görmesini sağlamanız gerekir.

Son zamanlarda, aşağıdaki iş akışını ana şubeyi asla doldurmamak için uyarladım:

1) Herkes esas olarak ana daldan bir kopyası olan kendi dalını kullanır.

Ana şubeye "master" ve kendi şubeme "my_master" adını verelim.

Ben şubemi ustadan yaptım, o yüzden aynısı. Kendi şubemde yeni bir özellik üzerinde çalışmaya başladım ve bittiğinde aşağıdakileri yapıyorum.

Şubemde parasal olarak, kodlamayı yeni bitirdim

git add . && git commit -m "Message" && git push

Ana şubeye geri dön

git checkout master

Güncel değilse çekin

git pull

Kendi şubeme geri dön

git checkout my_master

En son efendimi kendi şubemle birleştir

git merge master

Çakışmaları ve birleştirmeleri düzelt

Her şeyi tekrar test et

Her şey birleştiğinde ve kendi şubemde sabitlendiğinde, it

git push

Ana şubeye geri dön

git checkout master

Şubemle birleştir

git merge my_master

Önceden bir birleşme ile kendi şubenizde çözüldüğü için çatışmalar olması imkansız

Master it

git push

Herkes bunu takip ederse, ana dal temiz olur.

Bu yüzden TFS'den git'e geçen ve eski düşünme tarzlarını koruyan bir ekibimiz var. Genel operasyon kuralları aşağı yukarı aynıdır.

Evet, bu herkesin usta üzerinde çalıştığı anlamına gelir. Bu o kadar da kötü değil; ve TFS veya SVN için kullanılan bir ekip bunu en doğal bulacak.

Bunu mümkün olduğunca acısız hale getirmek için genel prosedürler:

1. do git stash && git pull --rebase && git stash popher sabah
2. erken ve sık taahhüt edin (derhal itmeye gerek yok; en azından git bu avantajından yararlanmaya başlayabiliriz)

3. itmek için aşağıdaki döngüyü yapın:

   git add git commit git pull --rebase fix any merges compile git push loop until you don't get the can't fast forward error message.

Herkes usta üzerinde çalışıyorsa, yapabileceğiniz hiçbir şey yok. İşler kaçınılmaz olarak berbatlaşacak.

Bir müşteriye gönderilen tamamlanmış ürünler için master kullanmalısınız. Devam eden gelişim için geliştirmeyi kullanmalı ve hiç kimsenin gelişime itmesine izin vermemelisiniz. Standart, herkesin dev'ten şubelere dalması, değişiklik yapması, yerelden sunucudaki şubesine itmesi ve bir zorlama isteği göndermesidir. Sonra birisi değişimi gözden geçirir ve gelişim ile birleştirir.

Çatışmalardan kaçınmak için herkes gelişmeyi zorlamadan önce kendi branşında birleştirir ve bu aşamadaki çatışmaları çözer (bu nedenle yalnızca yerel olarak bir geliştiriciyi etkiler). Geliştirmeyle birleşme çatışmalara yol açarsa, o zaman birleştirilmez - geliştirici gelişmeyi tekrar kendi branşında birleştirir ve tekrar sunucuya iter ve ardından tekrar gözden geçirilir.

Sourcetree'yi örneğin bu işi hiç acı çekmeden yapmak için kullanabilirsiniz.