İş akışı: Git'te kilitsiz ikili belge biçimlerini kullanma (alt sürümden taşıma)

Farklı müşteriler için çok sayıda projeye sahip bir yazılım danışmanıyız. Geleneksel olarak Subversion kullanıyoruz, ancak şu anda Git'e geçmeyi düşünüyoruz.

Ürettiğimiz belgelerin önemli bir kısmı müşterilerimizle paylaşılıyor (gereksinimler, global tasarımlar, test spesifikasyonları vb.) Ve bunları üretmek için MS Office kullanıyoruz. Subversion'da, kimsenin aynı belgeyi aynı anda düzenlemediğinden emin olmak için "Kilitle" özelliğini kullanabiliriz. Git'te dağıtılmış doğası gereği git'in kilitleri olmadığından bunu yapamazsınız.

Kilitler bir iletişim mekanizmasından çok daha fazlasıdır, ancak çok etkili bir mekanizmadır.

Şu anda, kodumuz ve müşteriye dönük belgelerimiz genellikle farklı bir svn deposunun farklı alt klasörlerinde bulunmaktadır. Git'e taşınırken ne yapmamızı önerirsiniz? Bir dizi seçenek görüyorum:

1. Svn depolarını git bire bir git'e taşıyoruz. Office dosyalarında kilitleri kullanmak yerine, git insanların önerdiklerini yapıyoruz ve bir şekilde düzeltmek için iş akışımızı değiştirmeye çalışıyoruz. Bu, herhangi bir belge düzenlemesinde bir dalda çalışıyor olabilir ve bu incelemeyi birleştirebilir. Bu yaklaşım, örneğin, proje yönetim bilgisi içeren Excel sayfalarını; ekip üyeleri tarafından kolayca düzenlenirler (ve bunun yapılmasını teşvik ederiz), ancak herhangi bir resmi inceleme sürecine tabi tutulmazlar

2. Kod için sv ve dokümanlar ve proje yönetimi için svn kullanıyoruz. Bunun dezavantajı, bazı daha tasarım-ish belgelerinin belirttiği koda "yakın" olmaması ve insanların bunları güncellemeyi unutma şansını arttırmasıdır. Buna ek olarak, herkes iki araç setini kullanmak ve anlamak zorundadır. Bununla birlikte, belki de müşteriye dönük olmayan tasarım dokümanları için metin tabanlı doküman araçlarına (lateks, işaretleme, HTML, ne olursa olsun) geçmek için harika bir fırsat.

3. 1 gibi, ancak git locksvn lock'un bizim için ne yaptığını yapan bir komutu hackliyoruz (salt okunur bayrağı uygun şekilde değiştirin ve bir yolla bir sunucu ile senkronize edin).

Kilitlerin bir DVCS'de çalışmadığı argümanı satın almıyorum çünkü sistem tamamen çevrimdışı olduğunuzda bile çalışmalıdır. Svn kilitleri de geçersiz kılınabilir; onlar bir iletişim mekanizmasıdır. Bir tür ağ bağlantısı olmadan, bilgisayarınızın çok fazla iletişim kurmasını sağlamazsınız.

svn lockİş akışımıza ne kadar uyduğundan çok memnun olan tek dükkan olamayız, değil mi?

Herhangi bir fikir veya ipucu?

Https://stackoverflow.com/questions/119444/locking-binary-files-using-git-version-control-system buldum ancak tartışma oldukça teknik; Aynı ikili dosyayı aynı anda düzenleyen iki ekip üyesinin pratik sorununu çözmenin veya önlemenin yollarını arıyorum.

MS Office belgeleri için iki nedenden dolayı SVN ile kalmanızı tavsiye ederim:

1. Zaten orada ve (bence) Office belgelerini tutmak için daha iyi ( buraya bakın ). Bunu yapmak için çok daha fazla üçüncü taraf aracı var.
2. Git'te elde edilebilecek bir kilit olsa da, "Git bir şeyler yapmanın yolu" değildir. Bu özelliklere ihtiyacınız varsa, size en iyi çözümü veren araca sadık kalın.

Bunun gibi bir şey söylediğini sevdiğim bir söz var: "Bir çekiç tuttuğunuzda, her şey çivi gibi görünüyor". Kodunuzu tutmak için Git'e gittiğiniz için, bunu belgelerinizi tutmak için kullanmanız gerektiği anlamına gelmez.

Kod sürümü denetimi, Office dosyalarında çalışmak için en iyi araç değildir, çünkü bunlar ikili ve bu araçlar dosya düzeyinde değişiklik üzerinde çalışır.

Word belgesini kolayca ayıklayabileceğiniz MediaWiki (ücretsiz) veya Atlassian Confluence (ücretli) gibi bir işbirliği aracı kullanın. Veya Office dosyalarını oluşturmak için LaTex'i kullanın.

Genişleteyim ...

İşbirliği yapmanız gerekiyorsa, birime, örneğin bir dosyaya yapılan değişiklikleri (ör. Bir kelimeyi değiştirmiş, yeniden yazmış veya sadece bir fontu değiştirmiş) vurgulayan bir model benimsemelisiniz.

SVN ve Git, kod düşünülse bile, dosyalarını metinsel içeriğe göre karşılaştıran düşük düzeyli araçlardır. Ancak sorun, yalnızca metin dosyalarında çalışabilmeleridir, çünkü üst düzey bir değişiklik modelini ayıklamak için dosyanın doğasını / içeriğini umursamazlar.

Bunun açık bir örneği bir görüntü dosyasıdır . TortoiseMerge , SVN kullanıcılarına görüntüleri gerçek modifikasyonları için karşılaştırarak yardımcı olan bir araç olsa da , normal VCSes , dosyalar üzerinde içerik yamaları tarafından çalıştırılır . Açıklamama izin ver. TortoiseMerge gibi bir araç, bir görüntü dosyasının yeni bir sürümünün yalnızca birkaç piksel veya iki dosyanın daha karmaşık HSV analizini gerçekleştirmesi durumunda parlaklık ile değiştiğini söyleyebilir. Sen, resim dosyaları karşılaştıran bir aracı bir filigran veya değiştirmek renk düzeyleri ekleyebilirsiniz olacak iyi algoritmayı gerçekler eğer size farklılıkları vurgulayın. Ama müşteri yeni dosyayı kontrol etmek için mutlakabir delta üret. Delta, kaldırılan satırlar ve dosyaya eklenen satırlardır. Onlar yoksa İkili dosyalar Satırın sonunda gerçekleşmesi için \r\ntek bir karakteri bütün bir çizgi değiştiriyorsanız değiştirirseniz veya benzer, onların yükü içinde ve bir delta içinde.

İşte sorun burada. İkili dosyalar sürüm denetimi için iyi değildir, çünkü her revizyon için neredeyse tüm dosyayı değiştiriyor olabilirsiniz. MS Office'i kullanarak Office dosyalarını yazarken ve OpenOffice ile ortak çalışan düzenlemelerinizi düşünün. OpenXML dosyalarının sıkıştırma algoritmasının biraz farklı bir sürümünü bile uygularlarsa , belgedeki tek bir virgül değiştirseniz bile tamamen farklı dosyalarla karşılaşırsınız .

İşbirliği yazılımları belgeleri şirket içinde metin tabanlı bir biçimde oluşturur, çünkü metin şirketiniz için gerçekten anlamlı olan şeydir ve farklılıkları hesaplayabilir veya çakışmaları kaldırabilir. LaTex veya isterseniz Markdown, bir belgeyi gelişmiş biçimlendirmeye sahip bir metin dosyası olarak depolamanın bir yoludur , bu nedenle yazı tipi / biçimlendirme kontrolü olmayan klasik TXT dosyası gibi değil.

Ancak müşterileriniz Markdown dosyalarını açmak istemeyecekler, değil mi? Tamam, basitçe yapabilirsiniz ve gerçekten basitçe, bir kaynak belgeyi PDF'ye, Word'e veya herhangi bir şeye dönüştürmek için google için çok tembel olduğum herhangi bir yazılımı kullanın .

Özetleme

Metin dosyalarını kaynak denetiminizde kontrol etmeye başlarsanız, dosya geçmişi üzerinde daha fazla kontrole sahip olursunuz ve özellikle VCS kilitlerini kullanmadan çakışmaları kolayca yönetebilirsiniz.

Bir belgeyi resmi olarak paylaşmadan önce, kaynak metin belgesini bir Office dosyasına aktarmak için bir rutine ihtiyacınız vardır

İki adımı ayırmak, insanları bir öğrenme eğrisinin pahasına mutlu eder.

Kilit eklemeden bu belgeler için git'i kullanabilirsiniz. Master'da değilse, ana dalı itmeleri engelleyen bir git iş akışı seçin. (Aralarından seçim yapabileceğiniz birkaç iş akışı vardır.) Bu, kişilerin birbirlerinin ikili belge dosyalarındaki değişikliklerinin üzerine yazmasını önler. İki kişinin aynı ikili belgeyi değiştirdiğini varsayın. Bunu master'a iten ilk değişikliklerini alır. İkincisi, kopyaları master dalın arkasında olduğu için bloke olur. Önce senkronize etmeleri gerekiyor. Böylece ikinci kişi senkronize olur. İkili belge için birleştirme çakışması gösterecektir. Bu kişi versiyonunu bir yere kaydeder ve versiyonu master'dan (ilk kişi tarafından itilir) alarak çatışmayı çözer. Bu noktada, ikinci kişinin dosyaları ana dal ile günceldir. En son ikili belgede (elle) yapılan değişikliklerinde birleştirilirler; bu, hem birinci kişinin hem de ikinci kişinin değişikliklerini içerecektir. Daha sonra yeni sürüm master hale getirilir ve yeni master şube haline gelir. Birleşme bir acıdır, ancak sadece bir çatışma olduğunda olur. Ayrıca, değişiklikler kaybolmaz veya üzerine yazılmaz. Çakışmalar algılanır ve kullanıcılar bunları temiz bir şekilde çözebilir.

İlk 2 çözümünüzü bir araya getirin, üçüncüye ihtiyacınız yok.

E-tablolarınızı diske CSV olarak kaydederseniz, Excel bunları yine de düzenler ve git sizin için birleştirmekten mutluluk duyacaktır.

Benzer şekilde, HTML veya (tanrı bize yardımcı olur) RTF ise, dosyalarınızı Word'de açabilir, düzenleyebilir ve kaydedebilirsiniz. Tabii ki kelime yararlı metinden daha fazla şişkinlik katacak, ama yine de git sizin için birleştirmekten mutlu olan metin.

Verilen bu çözümler, Excel tarafında gerçekten büyük olasılıkla bir sorun olan MS'ye özgü özelliklerden yararlanmadığınızı veya bu özelliklerden uzaklaşabileceğinizi varsayar.

Tabii ki, Word'ün bir belgeye yüklenmesini gerektirmedikçe, belgelerinizi okuyabilmek için, bu benim için korkunç bir olasılıktır ...