Рабочий процесс: Использование двоичных форматов документов в Git без блокировок (переход от subversion)

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

Значительная часть документов, которые мы производим, передается нашим клиентам (требования, глобальные проекты, спецификации тестирования и т. Д.), И мы используем MS Office для их производства. В Subversion мы могли использовать функцию «Блокировка», чтобы гарантировать, что никто не редактировал один и тот же документ одновременно. В Git вы не можете этого сделать, поскольку по своей распределенной природе git не имеет блокировок.

Замки действительно немного больше, чем механизм связи, но они очень эффективны.

В настоящее время наш код и документы, ориентированные на клиента, обычно находятся в разных подпапках в другом хранилище SVN. Что бы вы порекомендовали делать при переходе на git? Я вижу множество вариантов:

1. Мы перемещаем репозитории SVN в Git 1-на-1. Вместо того, чтобы использовать блокировки для файлов Office, мы делаем то, что предлагают люди из git, и каким-то образом пытаемся изменить наш рабочий процесс, чтобы исправить это. Это может работать в ветке над любым редактированием документа и объединять его с проверкой. Этот подход распространяется, например, на листы Excel, которые содержат информацию об управлении проектом; они легко редактируются членами команды (и мы поощряем это), но не подлежат никакому официальному процессу проверки

2. Мы используем git для кода и svn для документации и управления проектами. Это имеет недостаток, заключающийся в том, что некоторые дополнительные документы, предназначенные для разработки, не будут находиться «рядом» с указанным кодом, что увеличивает вероятность того, что люди забудут обновить их. Кроме того, каждый должен использовать и понимать два набора инструментов. Тем не менее, возможно, это отличная возможность перейти к текстовым инструментам документов (латекс, уценка, HTML и т. Д.) Для сторонних дизайнерских документов.

3. Как 1, но мы взломали git lockкоманду, которая делает то, что делает для нас svn lock (соответствующим образом переключите флаг только для чтения и синхронизируйте с сервером каким-либо образом).

Я не покупаю аргумент, что блокировки не работают в 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, сравнивая изображения на предмет их реальных изменений, обычно они VCSзапускаются патчами содержимого над файлами. Позволь мне объяснить. Инструмент, такой как TortoiseMerge, может сказать вам, что новая версия файла изображения изменяется только на несколько пикселей или яркости, если он реализует более сложный анализ HSV этих двух файлов. Вы можете добавить водяной знак или изменить цветовые уровни, инструмент, который сравнивает файлы изображений, выделит вам различия, если он реализует хороший алгоритм сравнения. Но для того, чтобы проверить новый файл в вашем клиенте, необходимопроизвести дельту. Дельта - это набор удаляемых строк и добавляемых в файл строк. Бинарные файлы не имеют разрывов строк , если они не случатся иметь \r\n, или подобные, в их полезной нагрузке, а также в дельте , если изменить один символ , который вы заменяете всю линию.

Так вот в чем проблема. Двоичные файлы не годятся для контроля версий, потому что вы можете почти полностью заменить файл для каждой ревизии. Учитывайте, когда вы пишете файлы Office с помощью MS Office, а ваши соавторы редактируют с помощью OpenOffice. Если они реализуют даже немного другую версию алгоритма сжатия файлов OpenXML, вы окажетесь в совершенно разных файлах, даже если вы изменили одну запятую в документе.

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

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

Подведение итогов

Если вы начнете проверять текстовые файлы в своем контроле исходного кода, вы получите больший контроль над историей файлов и сможете легко управлять конфликтами, особенно без использования блокировок VCS.

Перед официальным совместным использованием документа вам потребуется процедура для экспорта исходного текстового документа в файл Office.

Разделение двух шагов делает людей счастливыми за счет кривой обучения.

Вы можете использовать git для этих документов без добавления блокировки. Выберите рабочий процесс git, который блокирует нажатия на главную ветвь, если не на главной. (Существует несколько рабочих процессов на выбор.) Это предотвратит перезапись пользователями изменений друг друга в двоичные файлы документов. Предположим, два человека изменили один и тот же двоичный документ. Первый, который подталкивает его к мастеру, вносит свои изменения. Второй блокируется, потому что их копия находится за главной веткой. Сначала они должны синхронизироваться. Так что второй человек синхронизируется. Это покажет конфликт слияния для двоичного документа. Этот человек где-то сохраняет свою версию и разрешает конфликт, беря версию от мастера (которая была выдвинута первым человеком). На данный момент файлы второго человека обновлены в основной ветке. Они объединяют свои изменения с последним двоичным документом (вручную), который будет содержать изменения как первого, так и второго лица. Затем новая версия передается мастеру и становится новой ветвью мастера. Слияние - это боль, но это происходит только в случае конфликта. Кроме того, изменения не теряются и не перезаписываются. Конфликты обнаруживаются, и пользователи могут разрешить их чисто.

Соедините ваши первые 2 решения, и вам не нужно третье.

Если вы сохраните свои электронные таблицы на диске в формате CSV, Excel все равно будет их редактировать, а затем Git будет рад объединить их для вас.

Точно так же вы можете открывать, редактировать и сохранять свои файлы в Word, если они являются HTML или (да поможет нам Бог) RTF. Word, конечно, добавит больше раздува, чем полезного текста, но все равно это всего лишь текст, который Git с радостью объединит для вас.

Конечно, эти решения предполагают, что вы не используете или можете отказаться от специфических для MS функций, что на самом деле является проблемой только в Excel.

Если, конечно, вам также не нужно, чтобы Word был установлен в системе, чтобы иметь возможность читать вашу документацию, что само по себе ужасно для меня ...