Робочий процес: Використання бінарних форматів документів у Git без блокування (переміщення з підривної роботи)

Ми консультуємось з програмного забезпечення з безліччю проектів для різних клієнтів. Ми традиційно використовуємо Subversion, але наразі розглядаємо можливість переходу до Git.

Значна частина вироблених нами документів ділиться з нашими замовниками (вимоги, глобальний дизайн, тестові характеристики тощо), і ми використовуємо MS Office для їх виготовлення. У програмі Subversion ми могли використовувати його функцію "Блокування", щоб гарантувати, що ніхто не редагував один і той же документ одночасно. У Git цього не можна зробити, оскільки за його поширеним характером у git немає замків.

Замки насправді трохи більше, ніж механізм зв'язку, але вони дуже ефективні.

В даний час наш код і орієнтовані на клієнта документи, як правило, знаходяться в різних папках іншого сховища svn. Що ви рекомендуєте робити, коли переходите до git? Я бачу набір варіантів:

1. Ми переміщуємо сховища svn до git 1-on-1. Замість використання замків у файлах Office, ми робимо те, що пропонують люди, і якось намагаємось змінити наш робочий процес, щоб його виправити. Це може працювати у відділенні над будь-яким редагуванням документа та об'єднувати його під час перегляду. Цей підхід розбивається, наприклад, на листах Excel, які містять інформацію про управління проектами; вони легко редагуються членами команди (і ми радимо, що це робиться), але вони не підлягають офіційному перегляду

2. Ми використовуємо git для коду та svn для документів та управління проектами. Це має той недолік, що деякі інші документи-дизайни не будуть «поруч» кодом, який він специфікує, збільшуючи шанс того, що люди забудуть їх оновити. Крім того, кожен повинен використовувати та розуміти два набори інструментів. Однак, можливо, це чудова можливість перейти до текстових інструментів для документообігу (латекс, розмітка, HTML та інше) для дизайнерів, що не стосуються клієнтів.

3. Як і 1, але ми зламаємо git lockкоманду, яка робить те, що робить замовлення svn для нас (відповідним чином перемикає прапор лише для читання та синхронізує з сервером якимись засобами).

Я не купую аргумент про те, що блокування не працює в DVCS, тому що система повинна працювати навіть у режимі офлайн. Замки Svn можна також відміняти; вони механізм зв'язку . Без якогось підключення до мережі ви не змусите комп’ютера багато спілкуватися.

Ми не можемо бути єдиним магазином, який дуже задоволений тим, як svn lockвписується в наш робочий процес, правда?

Якісь ідеї чи поради?

Я знайшов /programming/119444/locking-binary-files-using-git-version-control-system, але обговорення досить технічне; Я шукаю способи вирішити або уникнути практичної проблеми двох членів команди, які одночасно редагують один і той же двійковий файл.

Я б радив вам залишитись у SVN для документів MS Office з двох причин:

1. Він уже є, і це, на мій погляд, краще для зберігання документів Office (дивіться тут ). Має набагато більше сторонніх інструментів для цього.
2. Блокування, хоча це може бути досягнуто в Git, не є "Git видом способів робити речі". Якщо вам потрібні ці функції, дотримуйтесь інструменту, який дає вам найкраще рішення.

Є приказка, що мені подобається, говорить приблизно так: "Коли ти тримаєш молоток, все схоже на цвях". Тільки тому, що ви переходите до Git, щоб утримувати код, це не означає, що ви повинні використовувати його для зберігання документів.

Контроль версій коду - не найкращий інструмент для роботи з файлами Office, оскільки вони є бінарними, і ці інструменти працюють на модифікації рівня файлів.

Використовуйте інструмент співпраці, як-от MediaWiki (безкоштовно) або Atlassian Confluence (платний), з якого ви можете легко отримати документ Word. Або використовуйте LaTex для створення файлів Office.

Дозвольте мені розширити ...

Якщо вам потрібно співпрацювати, ви повинні прийняти модель, яка висвітлює модифікації (наприклад, змінили слово, перефразовували або просто змінили шрифт) на одиницю, наприклад, файл.

SVN та Git, навіть якщо їх думати за кодом, - це інструменти низького рівня, які порівнюють свої файли за текстовим вмістом. Але проблема полягає в тому, що вони можуть працювати лише над текстовими файлами, оскільки вони не переймаються характером / вмістом файлу, щоб отримати модель модифікацій високого рівня.

Наочний приклад - файл із зображеннями . Хоча TortoiseMerge - це інструмент, який допомагає користувачам SVN, порівнюючи зображення для їх реальних модифікацій, звичайний VCSes працює за допомогою патчів вмісту над файлами. Дозволь пояснити. Такий інструмент, як TortoiseMerge, може сказати вам, що нова версія файлу зображення змінюється лише на кілька пікселів, або яскравість, якщо вона реалізує складніший HSV-аналіз двох файлів. Ви можете додати водяний знак або змінити рівень кольорів, інструмент, який порівнює файли зображень , виділить вам відмінності, якщо він реалізує хороший алгоритм порівняння. Але для перевірки нового файлу у вашого клієнта необхідновиробляють дельту. Дельта - це набір видалених рядків та рядків, які додаються до файлу. Бінарні файли не мають розривів рядків , якщо вони не трапляться мати \r\n, або подібні, в їх корисного навантаження, а також в дельті , якщо змінити один символ , який ви замінюєте всю лінію.

Тож ось проблема. Бінарні файли не корисні для контролю версій, оскільки ви могли майже замінити весь файл за кожну версію. Подумайте, коли ви пишете файли Office за допомогою MS Office і ваш колектив редагує за допомогою OpenOffice. Якщо вони реалізують навіть дещо іншу версію алгоритму стиснення файлів OpenXML, ви опинитеся в абсолютно інших файлах, навіть якщо ви змінили одну кому в документі.

Програмне забезпечення для спільної роботи надає документи всередині тексту у текстовому форматі, оскільки текст є дуже важливим для вашої компанії і може обчислити відмінності або вирішити конфлікти. Якщо ви хочете, LaTex або Markdown - це спосіб зберігати документ у вигляді текстового файлу з розширеною розміткою, тому не подобається класичному файлу TXT, який не має керування шрифтом / форматуванням.

Але очевидно, що ваші клієнти не люблять відкривати файли Markdown, чи не так? Гаразд, ви можете просто, і я справді маю на увазі просто, використовувати будь-яке програмне забезпечення, на яке я зараз лінивий в Google, щоб перетворити вихідний документ у PDF, Word чи інше.

Узагальнення

Якщо ви почнете перевіряти текстові файли у вихідному контролі, ви маєте більш високий контроль над історією файлів і можете легко керувати конфліктами, особливо без використання VCS-блокувань.

Перш ніж офіційно ділитися документом, вам потрібно розпочати експорт вихідного текстового документа в файл Office

Відокремлення двох кроків робить людей щасливими ціною кривої навчання.

Ви можете використовувати git для цих документів, не додаючи блокування. Виберіть робочий процес git, який блокує натискання на головну гілку, якщо не на головну. (Є декілька робочих процесів на вибір.) Це не дозволить людям перезаписувати модифікації один одного на бінарні файли документів. Припустимо, що двоє людей змінюють один і той же двійковий документ. Перший, який підштовхує його до майстра, отримує свої зміни. Другий буде заблокований, оскільки їх копія знаходиться позаду головного відділення. Вони повинні синхронізувати спочатку. Отже, друга людина робить синхронізацію. Він покаже конфлікт злиття для двійкового документа. Ця людина десь зберігає свою версію і вирішує конфлікт, беручи версію у майстра (на що її підштовхнула перша особа). На даний момент файли другої особи оновлюються з основною гілкою. Вони зливаються в своїх змінах з останнім бінарним документом (від руки), який потім буде містити зміни як першої, так і другої особи. Потім нова версія підштовхується до майстра і стає новою гілкою. Злиття - це біль, але воно відбувається лише тоді, коли є конфлікт. Крім того, зміни не втрачаються і не перезаписуються. Конфлікти виявляються, і користувачі можуть їх вирішити чисто.

Складіть свої перші 2 рішення разом, і третє вам не потрібно.

Якщо ви збережете свої електронні таблиці на диску у вигляді CSV-файлів, Excel все одно буде їх редагувати, і тоді git із задоволенням зробить їх для вас.

Так само ви можете відкривати, редагувати та зберігати свої файли у Word, якщо вони є HTML або (допоможе нам Бог) RTF. Слово звичайно додасть більше красного, ніж корисного тексту, але це все ще лише текст, який git радий злитися для вас.

Зрозуміло, ці рішення передбачають, що ви не використовуєте або не можете відійти від специфічних для MS функцій, що насправді є лише проблемою на стороні Excel.

Якщо, звичайно, ви також не вимагаєте, щоб Word було встановлено в системі, щоб мати можливість читати вашу документацію, що саме по собі є жахливою перспективою для мене ...