Git dokümantasyon ve proje yönetimi için kullanılmalı mı? Kod ayrı bir depoda mı olmalı?

Bir grup projesi için Git deposunu başlatıyorum. O belgeleri depolamak için mantıklı mı koduyla aynı Git depo - Bu git revizyon akışının doğası ile çakışan gibi görünüyor.

İşte sorum / sorularımın bir özeti:

• Hem kod hem de belgeler aynı depoda kontrol edilirse, Git revizyon tarzı kafa karıştırıcı mı olacak ? Bununla ilgili deneyimleriniz?

• Git dokümantasyon revizyon kontrolü için uygun mu?

• Ben am DEĞİL genel olarak Revizyon Kontrol Sistemi veya dokümantasyon kullanılmamalıdır gerektiğini soran - olması gerektiği.

Şimdiye kadarki geri dönüşler için teşekkürler!

Belgeleri her zaman SVN'de saklarız. Aslında, tüm kullanım kılavuzumuz LaTeX'te yazılmıştır ve SVN'de saklanmıştır. Özellikle LaTeX'i seçtik, çünkü metin tabanlı bir dil ve satır satır farklılık göstermesi kolay.

Ayrıca, gerektiğinde Microsoft Office .doc dosyaları, forma sayfaları, .zip dosyaları vb. Gibi bazı metin biçimli olmayan dosyaları da saklıyoruz ... diffs.

Önemli olan, dokümantasyonunuzun iyi organize edildiğinden emin olmaktır, böylece insanlar ihtiyaç duyduklarında dokümantasyonu (ve kaynağı) bulabilir (ve güncelleyebilir).

Belgelendirme için hangi formatı kullandığınıza bağlı. Metin tabanlı bir şey ise, her şey yolunda.

Git ayrıca ikili içeriği saklayabilir ve revizyonları izleyebilirsiniz, ancak diff çıktısı mantıklı olmaz.

Perldoc pod gibi belgeleri de kodda saklamak da mümkündür, java da bunun için bazı format / açıklamalara sahiptir.

Git'i veya başka herhangi bir sürüm kontrol sistemini belgeleme amacıyla kullanmakta bir sorun olabileceğini düşündüğünüzü hayal edemiyorum. Kaynak kodda olduğu gibi, belgelerin de tam bir geçmişi olmalı ve gerekirse daha önceki bir sürüme dönme yeteneğine sahip olmalıdır. Bir sürüm kontrol sistemi bunun için idealdir.

Belgeleri saklamak için bir çeşit Versiyon Kontrol Sisteminin kullanılmasının bir eğitici olmadığı açıktır. Sorunun daha ilginç olan kısmı, kaynak kod olarak AYNI konumundaki belgeleri saklamak iyi bir fikir midir? Buradaki olası sorun, bu durumda kod ve belgeler için farklı erişim ayrıcalıkları belirlemenin zor olabileceğidir. Ve birçok iş durumunda, insanların pazarlama veya BA departmanları gibi dokümanlara erişmeleri gerekecek, ancak kaynak kodlarına erişmeleri gerekmeyecek.

Çalıştığım firmada SVN'ye dokümantasyon koyuyoruz. Ancak, birkaç çatışmadan ve paylaşmaya ihtiyaç duyduktan sonra, onu Mediawiki'ye taşımaya karar verdik.

İlk başta trac idi, bundan sonra Mediawiki'ye taşındı çünkü kullanımı daha kolaydı ...

SVN'deki asıl sorun, SVN için yetkilendirme sistemine sahip olmamızın nedeni oldu.

• Bir depoda sadece kaynak koddan daha fazlasına sahip olmak çok iyi bir şey.

  Tüm kaynaklarınızı birlikte gruplandırır ve projeyi dağınık bir dosya koleksiyonundan ziyade tutarlı, merkezi bir varlığa dönüştürür. Katkıda bulunanlar / çalışanlar "x özelliğinin belgelerini nerede değiştiririm?" Göndermek yerine her şeyi nerede bulacağını biliyorlar e-postalar.

  İşleri düzenli tutmak isteyeceksiniz. Ayırmak için bir sistem oluşturun srcdan imagesitibaren docs. .gitignoreDepoyu ve geçmişi temiz tutmak için her zaman bir dizine bir ekleyebilirsiniz . Git taahhütlerinin dosya tabanlı olması nedeniyle, * kaynak değişikliklerini dokümantasyon değişikliklerinden istediğiniz kadar güçlü bir şekilde birleştirebilirsiniz.

• Diğerlerinin de söylediği gibi Git, metin tabanlı olduğu sürece dokümantasyon sürümleri için mükemmeldir.

• Tamamen katılıyorum; dokümantasyon, kodun yanında yazılı olarak verilmelidir.

Güvenilirliğim GitHub kullanıcısı olmaktan ve bir projeye katkıda bulunmaktan ve diğerlerini keşfetmekten kaynaklanıyor. Tecrübelerime göre, eksiksiz ve birleşik bir projenin yarı eksik bir projeden anlaşılması kolaydır. Tüm projelerimi mümkün olduğunda tek bir dizinde tutmaya çalışıyorum.

Buraya benzer bir soru ile geldim. Bir proje ile ilgili tüm materyalleri aynı depoda tutmanın temelde hiç akıllıca olmadığı bir SVN ortamından geliyoruz. SVN'nin doğası gereği, havuzun bölümlerini kolayca kontrol edebilirsiniz, böylece sadece kaynak koduna ihtiyacınız varsa (örneğin bir web sitesi dağıtımı) sorun değil.

Git ile işler farklı. Bir ödeme her zaman kök düzeyindedir, bu nedenle her şeyi aynı depoya koymak istiyorsanız, her zaman aynı dizin yapısına sahip olursunuz. Karşılaştığım bir yaklaşım, her şeyi ayrı dallara koymak, yani kod dallarınız (normal ana, geliştirme vb. Dallarınız olur) ve kendi ayrı dizin yapısına sahip bir doktora dalınız var. Emin değilim, ancak bu en iyi fikir, ancak sorunuzun temelinde olduğunu düşündüğüm sorunu çözen bir öneri.

Dahili dokümanlar için wiki kullanıyorum ... revizyon PLUS ile öne çıkarak erişim / kolay düzenleme. Dokümantasyon senkronizasyon dışındaysa, o zaman ve orada güncelleyin. Son kullanıcı dokümantasyonu için, Madcap Flare gibi profesyonel bir araç düşünün. Dokümanları paylaşmak, oluşturmak ve dönüştürmek için bir XML lehçesi kullanırlar.

Kodda, düşünceler genellikle satır satır ayrılır. Yumuşak hat sargılı belgeler yazma eğilimindeyim. Bu dosyaları işlediğimde, satırlar tüm paragraf uzunluğundadır. Bu okumak için çok kullanışlı değil git diff. Google sayfasını bulup bu sayfayı bulduğumda çözmeye çalıştığım sorun buydu. Beni tanıştırdığı için Arne Hartherz'e teşekkürler git diff --word-diff. Daha da git diff --color-wordsiyi olabilirsin .