Bir grup projesi için bir Git deposu başlatıyorum. Belgeleri kod ile aynı Git deposunda saklamak mantıklı mı - bu, git revizyon akışının doğası ile çakışıyor gibi görünüyor.
Sorularımın bir özeti:
Hem kod hem de belgeler aynı depoda işaretlenmişse Git revizyon stili kafa karıştırıcı mı olacak? Bununla ilgili deneyimler mi?
Git, doküman revizyon kontrolü için uygun mudur?
Ben [~ # ~] [~ # ~] bir Revizyon Kontrol Sisteminin dokümantasyon için genel olarak kullanılması gerekip gerekmediğini soruyorum - öyle olmalıdır.
Şimdiye kadarki geri bildiriminiz için teşekkürler!
Dokümanları 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. LaTeX'i özellikle metin tabanlı bir dil olduğu ve satır satır fark göstermesi kolay olduğu için seçtik.
Ayrıca gerektiğinde Microsoft Office .doc dosyaları, forma sayfaları, .Zip dosyaları, vb. Gibi metin formatlı olmayan bazı dosyaları da saklıyoruz ... diffs.
Anahtar, belgelerinizin iyi organize edildiğinden emin olmaktır, böylece insanlar belgeleri (ve kaynağı) ihtiyaç duyduklarında bulabilir (ve güncelleyebilir).
Bu, dokümantasyon için hangi biçimi kullandığınıza bağlıdır. Metin tabanlı bir şeyse, hepsi iyidir.
Git ayrıca ikili içeriği depolayabilir ve düzeltmeleri izleyebilirsiniz, ancak diff çıktısı mantıklı değildir.
Belgeyi perldoc pod gibi kodun kendisinde saklamak da mümkündür, Java ayrıca bunun için bazı format/ek açıklamalara sahiptir.
Belgede neden git veya başka bir sürüm kontrol sistemini kullanırken bir sorun olabileceğini düşündüğünüzü hayal edemiyorum. Tıpkı kaynak kodu gibi, belgelerin de tam bir geçmişi ve gerektiğinde önceki bir sürüme dönme yeteneği olmalıdır. Bir sürüm kontrol sistemi bunun için mükemmeldir.
Dokümanları depolamak için bir çeşit Versiyon Kontrol Sistemi kullanmanın bir beyinsiz olduğu açıktır. Sorunun daha ilginç kısmı, belgeleri kaynak kodu olarak AYNI konumda saklamanın iyi bir fikir olup olmadığıdır. Buradaki olası sorun, bu durumda kod ve belgeler için farklı erişim ayrıcalıkları ayarlamanın zor olabileceğidir. Ve birçok ticari durumda, insanların dokümanlara erişmesi gerekecek, ancak pazarlama veya BA departmanları gibi kaynak koduna ihtiyaç duymayacaklar.
Çalıştığım şirkette SVN'ye belge koyduk. Ancak, birkaç çatışmadan ve paylaşma ihtiyacından sonra, Mediawiki'ye taşımaya karar verdik.
İlk başta trac, Mediawiki'ye taşındıktan sonra kullanımı daha kolaydı ...
SVN ile ilgili temel sorun, SVN için yetkilendirme sistemimize sahip olduğumuz paylaşım nedeniydi.
Buraya benzer bir soru ile geldim. Bir proje ile ilgili tüm materyallerin aynı depoda tutulmasının temelde beyinsiz olduğu bir SVN ortamından geliyoruz. SVN'nin doğası nedeniyle, deponun bölümlerini kolayca kontrol edebilirsiniz, bu yüzden sadece kaynak koduna (örneğin, bir web sitesi dağıtımı) ihtiyacınız varsa, bu 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ına (genellikle normal ustanız, geliştirme, vb. Dallar olacak) ve kendi ayrı dizin yapısına sahip bir doktor dalına sahip olmaktır. Henüz en iyi fikir olduğundan emin değilim, ancak sorunuzun temelinde olduğunu düşündüğüm sorunu atlatan bir öneri.
Dahili dokümanlar için bir wiki kullanıyorum ... revizyon PLUS belirgin erişim/kolay düzenleme olsun. Belgeler senkronize olmadığında, belgeyi hemen oradan güncelleyin. Son kullanıcı belgeleri için Madcap Flare gibi profesyonel bir araç düşünün, belgeleri paylaşmak, oluşturmak ve dönüştürmek için bir XML lehçesi kullanırlar.