Kuruluşta Git Tabanlı Kaynak Kontrolü: Önerilen Araçlar ve Uygulamalar?

Git'i kişisel projeler için kullanıyorum ve harika olduğunu düşünüyorum. Hızlı, esnek, güçlü ve uzaktan geliştirme için harika çalışıyor.

Ama şimdi iş yerinde zorunlu ve açıkçası sorun yaşıyoruz.

Kutunun dışında git, farklı yeteneklere ve git gelişmişlik düzeylerine sahip geliştiricilere sahip büyük (20+ geliştirici) bir organizasyonda merkezi geliştirme için iyi çalışmıyor gibi görünüyor - özellikle de Perforce veya Subversion gibi diğer kaynak kontrol sistemleriyle karşılaştırıldığında. bu tür bir ortamı hedefliyor. (Evet, biliyorum, Linus asla buna niyet etmedi.)

Ama - politik nedenlerden dolayı - yapmaya çalıştığımız şey için berbat olsa bile git ile sıkışıp kaldık.

İşte gördüğümüz şeylerden bazıları:

• GUI araçları olgun değil
• Komut satırı araçlarını kullanarak, bir birleştirmeyi mahvetmek ve başka birinin değişikliklerini ortadan kaldırmak çok kolaydır.
• Global salt okunur veya okuma-yazma ayrıcalıklarının ötesinde kullanıcı başına depo izinleri sunmaz
• Bir havuzun HERHANGİ BİR parçası için izniniz varsa, aynı şeyi havuzun HER bölümüne yapabilirsiniz, böylece merkezi sunucuda diğer kişilerin yapamayacağı küçük bir grup izleme şubesi yapmak gibi bir şey yapamazsınız. bulaşmak.
• "Her şey olur" veya "iyiliksever diktatör" dışındaki iş akışlarını teşvik etmek bir yana, teşvik etmek zordur
• Tek bir büyük depo (herkesin her şeyi karıştırmasına izin verir) veya bileşen başına çok sayıda depo (sürümleri senkronize etmeye çalışırken baş ağrısına neden olan) kullanmanın daha iyi olup olmadığı açık değildir.
• Birden fazla depoyla, başka birinin sahip olduğu tüm kaynakları merkezi depodan çekerek nasıl kopyalayacağınız veya dün öğleden sonra 4: 30'dan itibaren her şeyi almak gibi bir şey nasıl yapılacağı da net değil.

Ancak insanların git'i büyük geliştirme organizasyonlarında başarıyla kullandığını duydum.

Böyle bir durumdaysanız - ya da genel olarak, bazılarının komut satırı hayranı olmadığı büyük bir organizasyonda git'i kullanmayı daha kolay ve daha üretken hale getirecek araçlarınız, ipuçlarınız ve püf noktalarınız varsa - sahip olduklarınızı duymak isterim önermek.

BTW, bu sorunun halihazırda LinkedIn'de olan bir versiyonunu sordum ve hiçbir gerçek cevabım yok ama birçok "Tanrım, bunu da bilmek isterim!"

GÜNCELLEME: Açıklayayım ...

Çalıştığım yerde git dışında HİÇBİR ŞEY kullanamayız . Bu bir seçenek değil. Biz ona sıkışıp kaldık. Mercurial, svn, bitkeeper, Visual Source Safe, ClearCase, PVCS, SCCS, RCS, bazaar, Darcs, monoton, Perforce, Fossil, AccuRev, CVS ve hatta 1987'de kullandığım Apple'ın iyi ol 'Projektörünü kullanamayız. Yani diğer seçenekleri tartışmaya razı olsanız da, git tartışmazsanız ödülü alamayacaksınız.

Ayrıca, git'i kuruluşta nasıl kullanacağıma dair pratik ipuçları arıyorum . Yaşadığımız sorunların bir listesini bu sorunun başına koyuyorum. Yine, insanlar teoriyi tartışabilirler, ancak ödülü kazanmak istiyorsanız, bana çözümler verin.

Genel kanının aksine, bir DVCS kullanmanın kurumsal bir ortamda ideal bir seçim olduğunu düşünüyorum çünkü çok esnek iş akışlarını mümkün kılıyor. Önce DVCS ve CVCS'yi kullanmaktan, en iyi uygulamalardan ve daha sonra özellikle git'ten bahsedeceğim.

Kurumsal bağlamda DVCS ve CVCS:

Burada genel artılar / eksiler hakkında konuşmayacağım, bunun yerine bağlamınıza odaklanacağım. Bir DVCS kullanmanın, merkezi bir sistem kullanmaktan daha disiplinli bir ekip gerektirdiği genel kanıdır. Merkezi sistem için kolay bir yol sağlar olmasıdır zorlamak merkezi olmayan bir sistem gerektirir kullanarak, iş akışınızı daha fazla iletişim sözleşmelerin kurulan sadık ve disiplin. Bu, genel giderleri tetikliyor gibi görünse de, onu iyi bir süreç haline getirmek için gerekli olan artan iletişimde fayda görüyorum. Ekibinizin kod, değişiklikler ve genel olarak proje durumu hakkında iletişim kurması gerekecektir.

Disiplin bağlamındaki bir diğer boyut, dallanmayı ve deneyleri teşvik etmektir. İşte Martin Fowler'ın Sürüm Kontrol Araçları hakkındaki son bliki girişinden bir alıntı, bu fenomen için çok kısa bir açıklama buldu.

DVCS, deneme için hızlı dallanmayı teşvik eder. Subversion'da şubeler yapabilirsiniz, ancak bunların herkes tarafından görülebilmesi, insanları deneysel çalışma için bir şube açmaktan caydırır. Benzer şekilde bir DVCS, işin işaretlenmesini teşvik eder: yerel deponuzda testleri derleyemeyen veya geçemeyen eksik değişiklikler yapmak. Yine bunu Subversion'daki bir geliştirici dalında yapabilirsiniz, ancak bu tür dalların paylaşılan alanda olması, insanların bunu yapma olasılığını azaltır.

DVCS, basit metin farklılıkları yerine yönlendirilmiş döngüsel olmayan bir grafikte (DAG) küresel olarak benzersiz tanımlayıcılar aracılığıyla değişiklik kümesi izleme sağladıkları için esnek iş akışları sağlar. Bu, oldukça önemli olabilecek bir değişiklik kümesinin kaynağını ve geçmişini şeffaf bir şekilde izlemelerine olanak tanır.

İş Akışları:

Larry Osterman'ın (Windows ekibinde çalışan bir Microsoft geliştiricisi) Windows ekibinde istihdam ettikleri iş akışı hakkında harika bir blog yazısı var. En önemlisi sahip oldukları:

• Temiz, yüksek kaliteli yalnızca kodlu bir gövde (ana depo)
• Tüm geliştirmeler özellik dallarında gerçekleşir
• Özellik ekiplerinin ekip depoları vardır
• Düzenli olarak en son gövde değişikliklerini kendi özellik dallarıyla birleştirirler ( Forward Integrate )
• Eksiksiz özellikler, örneğin inceleme, test kapsamı, Soru-Cevap (kendi başlarına depolar) gibi çeşitli kalite kapılarını geçmelidir
• Bir özellik tamamlandıysa ve kabul edilebilir kaliteye sahipse, ana hat ile birleştirilir ( Ters Entegre )

Gördüğünüz gibi, bu depoların her birinin kendi başına yaşaması, farklı hızlarda ilerleyen farklı ekipleri ayırabilirsiniz. Ayrıca esnek kaliteli bir geçit sistemi uygulama imkanı DVCS'yi bir CVCS'den ayırır. İzin sorunlarınızı da bu seviyede çözebilirsiniz. Ana depoya yalnızca bir avuç insanın erişmesine izin verilmelidir. Hiyerarşinin her seviyesi için, ilgili erişim politikalarıyla birlikte ayrı bir depoya sahip olun. Gerçekten de, bu yaklaşım ekip düzeyinde çok esnek olabilir. Takım deposunu kendi aralarında paylaşmak isteyip istemediklerine veya yalnızca takımın liderinin takım deposuna taahhüt verebileceği daha hiyerarşik bir yaklaşım isteyip istemediklerine karar vermeyi her takıma bırakmalısınız.

(Resim Joel Spolsky'nin hginit.com sitesinden çalındı .)

Yine de bu noktada söylenecek bir şey var: - DVCS harika birleştirme yetenekleri sağlasa da, bu asla Sürekli Entegrasyon kullanmanın yerini almaz. Bu noktada bile büyük bir esnekliğe sahipsiniz: Ana depo için CI, takım depoları için CI, Soru-Cevap depoları vb.

Kurumsal bağlamda Git:

Git, daha önce de belirttiğiniz gibi kurumsal bağlam için ideal bir çözüm olmayabilir. Endişelerinizden bazılarını tekrar edersek, bence en önemlisi bunlar:

• Windows'ta hala biraz olgunlaşmamış destek (lütfen yakın zamanda değiştiyse beni düzeltin) Artık pencerelerde github windows client , tortoisegit , atlassian'dan SourceTree var
• Olgun GUI araçlarının eksikliği, birinci sınıf vatandaş vdiff / birleştirme aracı entegrasyonu yok
• İç işleyişinin üstünde çok düşük seviyede soyutlamalarla tutarsız arayüz
• Svn kullanıcıları için çok dik bir öğrenme eğrisi
• Git çok güçlüdür ve geçmişi değiştirmeyi kolaylaştırır , ne yaptığınızı bilmiyorsanız çok tehlikelidir (ve bazen bildiğinizi düşünseniz bile olacaksınız)
• Ticari destek seçeneği yok

Burada bir git vs hg alev savaşı başlatmak istemiyorum, bir DVCS'ye geçerek zaten doğru adımı attınız. Mercurial, yukarıdaki bazı noktalara değinir ve bu nedenle kurumsal bağlamda daha uygun olduğunu düşünüyorum:

• Python çalıştıran tüm platformlar desteklenir
• Tüm büyük platformlarda (win / linux / OS X) harika GUI araçları, birinci sınıf birleştirme / vdiff aracı entegrasyonu
• Çok tutarlı arayüz, svn kullanıcıları için kolay geçiş
• Git'in yapabildiği çoğu şeyi yapabilir, ancak daha temiz bir soyutlama sağlar. Tehlikeli işlemler her zaman açıktır. Gelişmiş özellikler, açıkça etkinleştirilmesi gereken uzantılar aracılığıyla sağlanır.
• Ticari destek selenic'ten alınabilir.

Kısacası, bir kuruluşta DVCS kullanırken, en az sürtünme sağlayan bir araç seçmenin önemli olduğunu düşünüyorum. Geçişin başarılı olması için, geliştiriciler arasında (VCS ile ilgili olarak) değişen becerilerin dikkate alınması özellikle önemlidir.

Sürtünmeyi azaltmak:

Tamam, duruma gerçekten takılmış göründüğünüz için, IMHO'nun kaldığı iki seçenek var. Git'i daha az karmaşık hale getirecek bir araç yok; git edilir karmaşık. Ya bununla yüzleşirsin ya da git etrafında çalışırsın:

1. Tüm ekip için git giriş kursu alın. Bu sadece temel bilgileri ve bazı alıştırmaları (önemli!) İçermelidir.
2. Ana depoyu svn'ye çevirin ve "genç yıldızlar" git-svn'ye izin verin . Bu, geliştiricilerin çoğuna kullanımı kolay bir arayüz sağlar ve ekibinizdeki eksik disiplini telafi edebilirken, genç yıldızlar git'i kendi depoları için kullanmaya devam edebilir.

Dürüst olmak gerekirse, bir alet probleminden ziyade gerçekten bir insan problemin olduğunu düşünüyorum. Bu durumu iyileştirmek için ne yapılabilir?

• Mevcut sürecinizin sürdürülebilir bir kod tabanıyla sonuçlanacağını düşündüğünüzü açıkça belirtmelisiniz.
• Sürekli Entegrasyona biraz zaman ayırın. Yukarıda özetlediğim gibi, hangi tür VCS kullanırsanız kullanın, CI'nın yerini hiçbir zaman alamazsınız. Ana depoya saçma sapan insanlar olduğunu belirttiniz: Kırmızı bir uyarı söndüğünde saçmalıklarını düzeltmelerini sağlayın ve yapıyı bozmakla (ya da bir kalite ölçüsünü karşılamadığı için) suçlayın.

Oldukça büyük bir geliştirme organizasyonunun SCM mühendisiyim ve geçen yıl kadar bir süredir svn'den git'e geçtik. Bunu merkezi bir şekilde kullanıyoruz.

Depoları barındırmak için gitosis kullanıyoruz . Git'in dallanma birimi temelde havuz olduğu için monolitik svn depolarımızı birçok küçük git depolarına böldük. (Bunun etrafından dolaşmanın yolları vardır, ancak bunlar gariptir.) Dallara göre erişim kontrolleri istiyorsanız, gitolit daha iyi bir yaklaşım olabilir. Parayı harcamak istiyorsanız , GitHub'ın güvenlik duvarı içi bir sürümü de var . Amaçlarımız için, gitosis iyidir çünkü depolarımızda oldukça açık izinlere sahibiz. (Depo gruplarına yazma erişimi olan ve herkesin tüm depolara okuma erişimi olan insanlardan oluşan gruplarımız var.) Bir web arayüzü için gitweb kullanıyoruz.

Bazı özel endişelerinize gelince:

• birleştirmeler: Seçtiğiniz bir görsel birleştirme aracını kullanabilirsiniz; nasıl kurulacağına dair çeşitli yerlerde talimatlar vardır. Tamamen yerel deponuzda birleştirme yapıp geçerliliğini kontrol edebiliyor olmanız, bence git için büyük bir artı; herhangi bir şeyi itmeden önce birleştirmeyi doğrulayabilirsiniz.
• GUI'ler: TortoiseGit kullanan birkaç kişimiz var ama ben bunu gerçekten önermiyorum; komut satırı ile garip şekillerde etkileşime giriyor gibi görünüyor. Bunun iyileştirilmesi gereken bir alan olduğunu kabul etmeliyim. (Bununla birlikte, genel olarak sürüm kontrolü için GUI hayranı değilim.)
• küçük grup izleme dalları: Gitolit gibi daha ince ACL'ler sağlayan bir şey kullanırsanız, bunu yapmak yeterince kolaydır, ancak çeşitli geliştiricilerin yerel depolarını bağlayarak paylaşılan bir şube de oluşturabilirsiniz - bir git deposunda birden fazla uzaktan kumanda olabilir.

Git'e geçtik çünkü çok sayıda uzak geliştiricimiz var ve Subversion ile ilgili birçok sorunumuz vardı. Hala iş akışları üzerinde deneyler yapıyoruz, ancak şu anda onu Subversion kullandığımız gibi kullanıyoruz. Sevdiğimiz bir diğer şey de, kod incelemesi için hazırlık havuzlarının kullanılması ve küçük gruplar arasında kodun paylaşılması gibi diğer olası iş akışlarını açmasıydı. Aynı zamanda birçok insanı kişisel senaryolarını izlemeye başlaması için teşvik etti çünkü bir depo oluşturmak çok kolay.

Evet, biliyorum, Linus asla buna niyet etmedi.

Aslında Linus, merkezi sistemlerin çalışamayacağını savunuyor.

Ve diktatör ve teğmenlerin iş akışının nesi var ?

Unutmayın, git dağıtılmış bir sistemdir; onu merkezi bir yer gibi kullanmaya çalışmayın.

(güncellenmiş)

Git'i sanki "steroid üzerinde svn" gibi kullanmaya çalışmazsanız sorunlarınızın çoğu ortadan kalkacaktır (çünkü öyle değildir).

Herkesin zorlayabileceği (ve potansiyel olarak batırabileceği) merkezi bir sunucu olarak çıplak bir depoyu kullanmak yerine, birleştirmeleri işleyen birkaç entegrasyon yöneticisi kurun, böylece yalnızca onlar çıplak depoya itebilir.

Genellikle bu insanlar ekip lideri olmalıdır: her lider kendi ekibinin çalışmasını entegre eder ve onu kutsanmış arşive iter.

Daha da iyisi, bir başkası (yani diktatör) takım liderlerinden çeker ve değişikliklerini kutsanmış depoya entegre eder.

Bu iş akışında yanlış bir şey yok, ancak biz aşırı çalışan bir girişimiz ve insan zamanının ve dikkatinin yerini alacak araçlarımıza ihtiyacımız var; kimse hayırsever diktatör olmayı bırakın kod incelemeleri yapacak bile bant genişliğine sahip değildir.

Entegratörlerin kodu incelemek için zamanı yoksa sorun değil, ancak yine de herkesten birleştirmeleri entegre eden insanlara ihtiyacınız var.

Git çeker yapmak o kadar fazla zaman almaz.

git pull A
git pull B
git pull C

Git yapar insan zaman ve dikkat yerine; bu yüzden ilk etapta yazılmıştır.

• GUI araçları olgun değil

GUI araçları temel şeyleri oldukça iyi halledebilir.

Gelişmiş işlemler, kodlayıcı / nerdy zihniyet gerektirir (örneğin, komut satırından rahat çalışıyorum). Kavramları kavramak biraz zaman alıyor ama o kadar da zor değil.

• Komut satırı araçlarını kullanarak, bir birleştirmeyi mahvetmek ve başka birinin değişikliklerini ortadan kaldırmak çok kolaydır.

"Merkezi depoya" tam yazma erişimi olan birçok beceriksiz geliştiriciniz olmadığı sürece bu bir sorun olmayacaktır.

Ancak, iş akışınızı yalnızca birkaç kişinin (entegratörlerin) "kutsanmış" havuza yazmasını sağlayacak şekilde ayarlarsanız, bu bir sorun olmaz.

Git, birleştirmeleri mahvetmeyi kolaylaştırmaz.

Birleştirme çakışmaları olduğunda git, çakışan satırları açıkça işaretler, böylece hangi değişikliklerin size ait olduğunu ve hangilerinin olmadığını bilirsiniz.

Başkalarının kodunu svn veya başka herhangi bir (dağıtılmayan) araçla silmek de kolaydır. Aslında, bu diğer araçlarla çok daha kolay, çünkü uzun süre "değişikliklerin üzerinde durma" eğilimindesiniz ve bir noktada birleşmeler korkunç derecede zorlaşabilir.

Ve bu araçlar nasıl birleştirileceğini bilmediğinden, her zaman bir şeyleri manuel olarak birleştirmek zorunda kalırsınız. Örneğin, birisi yerel olarak düzenlemekte olduğunuz bir dosyaya taahhütte bulunduğu anda, manuel olarak çözülmesi gereken bir çakışma olarak işaretlenecektir; şimdi bu bir bakım kabusu.

Git ile, çoğu zaman herhangi bir birleştirme çakışması olmayacak çünkü git aslında birleşebilir. Bir anlaşmazlık olması durumunda git, sizin için satırları açıkça işaretleyecektir, böylece hangi değişikliklerin size ait olduğunu ve hangi değişikliklerin diğer insanlardan geldiğini tam olarak bilirsiniz .

Bir kişi, bir birleştirme çatışmasını çözerken diğer insanların değişikliklerini ortadan kaldırırsa, bu yanlışlıkla olmayacaktır: bunun nedeni ya çatışmanın çözümü için gerekli olması ya da ne yaptıklarını bilmemeleridir.

• Global salt okunur veya okuma-yazma ayrıcalıklarının ötesinde kullanıcı başına depo izinleri sunmaz

• Bir havuzun HERHANGİ BİR parçası için izniniz varsa, aynı şeyi havuzun HER bölümüne yapabilirsiniz, böylece merkezi sunucuda diğer kişilerin yapamayacağı küçük bir grup izleme şubesi yapmak gibi bir şey yapamazsınız. bulaşmak.

• "Her şey olur" veya "iyiliksever diktatör" dışındaki iş akışlarını teşvik etmek bir yana, teşvik etmek zordur

Git'i merkezi bir sistemmiş gibi kullanmayı bıraktığınızda bu sorunlar ortadan kalkacaktır.

• Tek bir büyük depo (herkesin her şeyi karıştırmasına izin verir) veya bileşen başına çok sayıda depo (sürümleri senkronize etmeye çalışırken baş ağrısına neden olan) kullanmanın daha iyi olup olmadığı açık değildir.

Yargılama çağrısı.

Ne tür projeleriniz var?

Örneğin: A projesinin xy sürümü, tam olarak B projesinin wz sürümüne bağlı mıdır, öyle ki, A projesinin xy'sini her kontrol ettiğinizde, B projesinin wz'sini de kontrol etmeniz gerekir, aksi takdirde oluşmaz? Öyleyse, hem A projesini hem de B projesini aynı depoya koyardım, çünkü bunlar açıkça tek bir projenin iki parçası.

Buradaki en iyi uygulama beyninizi kullanmaktır

• Birden fazla depoyla, başka birinin sahip olduğu tüm kaynakları merkezi depodan çekerek nasıl kopyalayacağınız veya dün öğleden sonra 4: 30'dan itibaren her şeyi almak gibi bir şey nasıl yapılacağı da net değil.

Ne anlatmak istediğinden emin değilim.

Kurumsal işler için http://code.google.com/p/gerrit/ 'i şiddetle tavsiye ederim . Size erişim kontrolü ve ayrıca yerleşik incelemeye dayalı bir iş akışı sağlar. Herhangi bir LDAP sistemine karşı kimlik doğrulaması yapar. Http://wiki.hudson-ci.org/display/HUDSON/Gerrit+Plugin ile Hudson'a bağlayabilir , değişiklikleri daha gözden geçirilirken oluşturabilir ve test edebilirsiniz; gerçekten etkileyici bir kurulum.

Gerrit kullanmaya karar verirseniz, bazı açık kaynak kodlu adamların sevdiği gibi dallı bir geçmişi değil, oldukça doğrusal bir tarih tutmaya çalışmanızı öneririm. Gerrit bunu "yalnızca ileri sarma değişikliklerine izin ver" olarak ifade eder. Daha sonra, sürümler ve başka şeyler için alıştığınız şekilde dallanma ve birleştirmeyi daha çok kullanabilirsiniz.

Bu soruyu 2010'da Git'i benimsediğimiz büyük bir telekomünikasyon şirketinde geliştirici müdürü olarak edindiğim deneyimlere dayanarak yanıtlıyorum.

Burada oldukça farklı problemleriniz var:

• iş akışları
• müşteri araçları
• sunucu erişim kontrolü ve entegrasyonu

İş Akışları

Başarılı bir şekilde merkezi bir depo modunu benimsedik: kurumsal projemizde (5 milyon kullanıcı tabanı için büyük bir portal) sahip olduğumuz şey, resmi yapıları üreten fiili bir merkezi depodur ve daha sonra teslimat süreciyle alınır (ki bu bizim durum, üç düzey test ve iki dağıtımdan oluşur). Her geliştirici kendi deposunu yönetir ve biz özellik başına şube bazında çalışıyoruz.

İstemci araçları

Artık birkaç seçenek mevcut, burası artık çok kalabalık bir alan. Birçok geliştirici, IntelliJ Idea ve Eclipse'i başka hiçbir şey kullanmadan Git eklentisiyle başarıyla kullanıyor . Ayrıca Linux geliştiricilerinin çoğu CLI git istemcisini sorunsuz bir şekilde kullanıyor. Bazı Mac geliştiricileri Tower Git'i başarıyla kullanıyor . Lütfen bu istemcilerin hiçbirinin kullanıcının merkezi depoyu "karıştırmasını" engelleyemeyeceğini unutmayın : sunucu tarafı kontrol mekanizmasına ihtiyaç vardır.

Sunucu erişim kontrolü ve entegrasyonu

Geliştiricilerin Git deponuzu "karıştırmasını" önlemek istiyorsanız, aşağıdakileri yapan bir çözüm seçmeniz gerekir:

• her işlemi yapmak için iyi bir web yönetici arayüzü sunar
• kullanıcı kimliklerini zorlamanıza izin verir ("çıplak" bir Git deposu kullanmak, başkası adına son derece kolaydır)
• size ayrıntılı güvenlik sağlar (böylece örneğin FORCE-PUSH'ı önleyebilir ve bazı şubeleri bazı geliştiriciler / gruplar için yalnızca okunacak şekilde ayarlayabilirsiniz)
• kurumsal kimlik doğrulama sisteminizle (yani LDAP, Windows ActiveDirectory) entegre edin
• size tam denetim sağlar (SOX uyumluluğu bazen büyük şirketler için çok önemlidir)

Buna yardımcı olabilecek pek çok kullanıma hazır sunucu tarafı çözümü yok, şunlardan birine göz atmanızı öneririm:

• Devasa : Temel erişim seviyesi güvenliği sağlayabilir, ancak kutunun dışında ayrıntılı izin denetiminden yoksundur, bu nedenle, şube seviyesi izinleri gibi senaryoları işlemek için muhtemelen bazı kodlamalar yapmanız gerekecektir. Ayrıca mevcut kurumsal kimlik doğrulama mekanizmalarıyla entegrasyondan yoksundur
• GitHub Enterprise: Yakın zamanda GitHub tarafından yayınlandı, kurumunuzda GitHub'a yer veriyor. SOX uyumluluğundan ve ince taneli güvenlikten yoksundur
• Gerrit : Kurumsal kimlik doğrulama sistemleriyle hassas erişim seviyesi güvenliği ve entegrasyon sağlayabilir ancak SOX uyumluluğu ve SSO'dan yoksundur. Ayrıca bazı işlemler yalnızca CLI aracılığıyla SSH aracılığıyla yapılabilir
• GitEnterprise : şube düzeyinde izinler, SSO, SOX uyumluluğu, tam web tabanlı yönetim sağlar. Yakın zamanda Gerrit ile de entegre edildi, böylece size tam bir Gerrit örneği de sağlıyor

Bu yardımcı olur umarım!

Görünüşe göre probleminiz bir iş akışına karar vermemiş veya başlatmamış olmanız. Git, onu svn veya başka bir VCS gibi kullanmak için yeterince esnektir, ancak o kadar güçlü ki, herkesin uyması gereken kurallar koymazsanız, o zaman bir karmaşa ile karşılaşırsınız. Yukarıda birisinin bahsettiği diktatör-teğmen iş akışını, ancak Vincent Driessen tarafından tanımlanan dallanma modeliyle birlikte tavsiye ederim . Daha fazla bilgi için David Bock tarafından hazırlanan bu ekran videolarına ve Mark Derricutt'a ait bu ekran videolarına bakın .

Açık araçları , MacOS-X kullanıcıları GitX (http://gitx.frim.nl/) çok basit ve etkili buluyorum. Dezavantajı, Git İstemcisi kancalarını ($ GIT_ROOT / .git / hooks altındakiler) desteklememesidir.

Genel olarak, aşağıdaki konularda ayrıntılı erişim kontrolünü destekleyen bir araç seçiyorum : - dallar (kararlı sürüm dallarını daha fazla çeviklik ve esneklik gerektiren konu dallarından sıkı bir güvenlik ile ayırmak için) - kimlik denetimi (yazar / işleyen ). Bu SOX için ANAHTAR - git komutları kısıtlamaları - denetim izi. SOX için ANAHTAR

Bu özelliklerle başarıyla kullandıklarımız:

1. Gerrit Kodu İncelemesi (http://code.google.com/p/gerrit/)
2. GitEnterprise (http://gitenterprise.com)
3. CollabNet TeamForge (http://www.collab.net/gotgit), perde arkasında Gerrit 2.1.8 kullanıyor

PS SOX ve CMMI uyumluluğunu küçümsemeyin : Çoğu zaman, Güvenlik ile ilgili Şirket Kurumsal Politikalarınız tarafından belirlenen sınırlı seçenekleriniz vardır.

Bu yardımcı olur umarım.

Luca.

Yakın zamanda svn'den git'e geçtik. Git-daemon msysgit ile çalışmadığından, gitosis içeren bir Linux sunucusunda merkezi bir depo yaklaşımını seçtik.

Ustayı mahvetme olasılığını ortadan kaldırmak için basitçe kestik. Bunun yerine, test için seçilen dalları birleştirerek ve birleştirmeyi etiketleyerek tüm sürümleri hazırlıyoruz. Testleri geçerse, kaydetme bir sürümle etiketlenir ve üretime alınır.

Bunu halletmek için sürüm yöneticisinin dönüşümlü bir rolüne sahibiz. Sürüm yöneticisi, teste hazır olmadan önce her şubeyi incelemekten sorumludur. Daha sonra, ürün sahibi yeni bir test sürümü için onaylanan şubeleri bir araya getirme zamanının geldiğine karar verdiğinde, sürüm yöneticisi birleştirmeyi gerçekleştirir.

Ayrıca 2. seviye yardım masasının dönüşümlü bir rolüne sahibiz ve en azından bizim için iş yükü öyle ki, her iki rolü de aynı anda almak mümkün.

Bir ana makineye sahip olmamanın bir yararı olarak, sürüm yöneticisinden geçmeden projeye herhangi bir kod eklemek mümkün değildir, bu nedenle daha önce projeye sessizce ne kadar kod eklendiğini doğrudan keşfettik.

İnceleme süreci, şube sahibinin farklılığı inceleme tahtasına göndermesi ve beyaz tahtaya şube adıyla (Kanban tabanlı bir iş akışımız var) "inceleme için" altında veya tamamlanmış bir kullanıcının parçasıysa yeşil bir post-it koymasıyla başlar. öykü, öykü kartının tamamını "inceleme için" konumuna taşıyın ve postit'i bunun üzerine koyun. Yeniden çalışma yöneticisi, kartları ve post-it'lerini "test için hazır" durumuna taşıyan kişidir ve ardından ürün sahibi, bir sonraki test sürümünde hangilerinin dahil edileceğini seçebilir.

Birleştirmeyi yaparken sürüm yöneticisi, birleştirme işleminin ürün sahibi için değişiklik günlüğünde kullanılabilecek mantıklı bir tamamlama mesajına sahip olduğundan da emin olur.

Bir sürüm üretime sokulduğunda, etiket şubeler için yeni temel olarak kullanılır ve mevcut tüm şubeler bununla birleştirilir. Bu şekilde, tüm dalların ortak bir ebeveyni vardır ve bu, birleştirmeleri işlemeyi kolaylaştırır.

Ben de bir "düşündün mü" yazısı ekleyeceğim.

Çarşı'nın en güzel yanlarından biri esnekliğidir. Bu, diğer tüm dağıtılmış sistemleri geride bıraktığı yerdir. Bazaar'ı merkezi modda, dağıtılmış modda çalıştırabilir veya şunu elde edebilirsiniz: her ikisini de elde edebilirsiniz (yani geliştiriciler hangi modeli rahat edeceklerini veya çalışma grupları için hangisinin en iyi çalışacağını seçebilirler). Ayrıca yoldayken merkezi bir havuzun bağlantısını kesebilir ve geri döndüğünüzde yeniden bağlayabilirsiniz.

Üstelik, mükemmel belgeler ve işletmenizi mutlu edecek bir şey: ticari destek mevcuttur.

• Github FI gibi iyi bir web arayüzü kurun
• İnsanları rahat ettirmek için nispeten merkezi bir modele (başlangıçta) bağlı kalın.
• Her paylaşılan dal için bir Sürekli Entegrasyon derlemesi çalıştırın .
• İyi bir genel git yapılandırma seçeneği seti paylaşın.
• Git'i bash tamamlama ve mevcut dal ile bir komut istemiyle kabuğunuza entegre edin.
• IntelliJ'in Git Entegrasyonunu bir birleştirme aracı olarak deneyin.
• Uygun şekilde .gitignore yaptığınızdan emin olun.

3. ve 4. noktalarla ilgili olarak (kullanıcı başına, bölüm başına, dal başına izinler), gitolite bir göz atın (Pro Git kitabında ele alınmıştır: http://progit.org/book/ch4-8.html ).

Politika ya da değil, Git DCVS'nin herhangi bir seçimi kadar iyi bir seçimdir. Her güçlü araç gibi, aracın nasıl çalışacak şekilde tasarlandığını anlamak için önceden biraz zaman harcamaya değer ve bu amaçla, Pro Git kitabını şiddetle tavsiye ediyorum. Onunla geçirilen birkaç saat, uzun vadede çok fazla hayal kırıklığı yaratacaktır.

GUI: Şu anda, TortoiseGit v1.7.6, çoğu günlük işlem için iyi durumda olmalıdır. Log, Commit, Push, Pull, Fetch, Diff, Merge, Branch, Cherry-pick, Rebase, Tag, Export, Stash, Add submodle, vb ... x64'ü yerel olarak da destekler

Git'i çok sayıda geliştiricinin bulunduğu bir geliştirme ekibinde verimli bir şekilde kullanmak için, sürekli olarak oluşturulan ve test eden bir CI sistemi gereklidir. Jenkins böyle bir araç sağlıyor ve bunu şiddetle tavsiye ediyorum. Entegrasyon parçası ne olursa olsun yapılmalıdır ve bunu daha erken ve daha sık yapmak çok daha ucuzdur.

Ortak gelişim için gitosis veya gitolite göre daha uygundur ancak açık kaynak Gitorious'dur . Depoların yönetimini ve birleştirme işlemlerini gerçekleştiren bir Ruby on Rails uygulamasıdır. Sorunlarınızın çoğunu çözmelidir.

Git, özel dallar oluşturmanıza izin verir. Bu, geliştiricileri, değişiklikleri küçük taahhütlere ayırmak için sık sık taahhütte bulunmaya teşvik eder. Geliştirici değişikliklerini yayınlamaya hazır olduğunda, merkezi sunucuya gönderir. Gerekirse kodunu doğrulamak için ön işleme komut dosyalarından yararlanabilir.

NXP, Android mobil geliştirmeyi geleneksel yazılım projeleriyle entegre eden tek bir ortak platformla (kurumsal ölçekte) Git ve Subversion'ı yönetiyor: http://www.youtube.com/watch?v=QX5wn0igv7Q