Блокировка двоичных файлов с помощью системы управления версиями git

Subversion имеет блокировки, и они не просто рекомендательны. Они могут быть применены с помощью svn:needs-lock атрибут (но также может быть преднамеренно нарушен, если это необходимо). Это правильное решение для управления файлами без слияния. Компания, в которой я работаю для магазинов почти все в Subversion, и использует svn:needs-lock для всех не сливающихся файлов.

Я не согласен с "замки-это просто метод связи". Это гораздо более эффективный метод, чем push-уведомления, такие как телефон или электронная почта. Блокировки Subversion являются самодокументированными (у кого есть блокировка). С другой стороны, если вам приходится общаться с помощью других традиционных каналов push-уведомлений, таких как электронная почта, кому вы отправляете уведомление? Вы заранее не знаете, кто может захотеть отредактировать файл, особенно в проектах с открытым исходным кодом, если у вас нет полного списка всей вашей команды разработчиков. Таким образом, эти традиционные методы коммуникации далеко не так эффективны.

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

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

вот интересное чтение по этой теме.

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

• есть способ пометить файл как " needs-lock "(например, свойство" svn:needs-lock").
• при проверке git пометит такой файл как только для чтения.
• новая команда git-lock связался бы с центральным сервером блокировки, работающим где-то, чтобы спросить разрешение на блокировку.
• если сервер блокировки предоставляет разрешение, отметьте файл read-write.
• git-add сообщит серверу блокировки хэш содержимого заблокированного файла.
• сервер блокировки будет следить за тем, чтобы этот хэш содержимого отображался в фиксации в главном репозитории.
• когда появится хэш, отпустите блокировку.

Это очень сырая идея и есть потенциальные дыры везде. Это также идет против духа git, но это, безусловно, может быть полезно в некоторых контексты.

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

в ответ на дополнительную озабоченность Марио изменениями, происходящими в нескольких местах на двоичных файлах. Таким образом, сценарий-Алиса и Боб одновременно вносят изменения в один и тот же двоичный ресурс. У каждого из них есть свое местное РЕПО, клонированное с одного центрального пульта.

Это действительно потенциальная проблема. Итак, Алиса финиширует первой и толкает к центру alice/update филиала. Обычно, когда это происходит, Алиса объявляет, что это должно быть пересмотрено. Боб видит это и пересматривает. Он может либо (1) включить эти изменения в свою версию (ветвление от alice/update и вносит свои изменения в это) или (2) публикует свои собственные изменения в bob/update. И снова он делает объявление.

теперь, если Алиса толкает к master вместо этого у Боба есть дилемма, когда он тянет master и пытается слиться с местным филиалом. Его конфликты с Элис. Но опять же, одна и та же процедура может применяться, только на разных ветвях. И даже если Боб игнорирует все предупреждения и фиксации над Алисой, всегда можно вытащить фиксацию Алисы, чтобы исправить вещи. Это становится просто проблемой коммуникации.

поскольку (AFAIK) блокировки Subversion являются просто консультативными, электронная почта или мгновенное сообщение могут служить той же цели. Но даже если вы этого не сделаете, Git позволит вам это исправить.

нет, нет никакого механизма блокировки как такового. Но механизм блокировки, как правило, просто заменяет хорошее общение. Я считаю, что ЖКТ разработчики не добавили механизм блокировки.

мы только недавно начали использовать Git (ранее использовался Subversion), и я нашел изменение в workflow-процессе, которое может помочь с вашей проблемой, без необходимости блокировки. Он использует преимущества того, как Git разработан и насколько просты ветви.

в основном, это сводится к нажатию на ветку, не являющуюся главной, проведению обзора этой ветви, а затем слиянию с главной ветвью (или какой бы ни была целевая ветвь).

путь git "предназначен" для использования, каждый разработчик публикует свой собственный публичный репозиторий, из которого они просят других извлечь. Я обнаружил, что у пользователей Subversion есть проблемы с этим. Поэтому вместо этого мы нажимаем на ветви деревьев в Центральном репозитории, причем каждый пользователь имеет свое собственное дерево ветвей. Например, такая иерархия может работать:

users/a/feature1
users/a/feature2
users/b/feature3
teams/d/featurey

не стесняйтесь использовать свою собственную структуру. Примечание. Я также показываю ветви темы, еще одну распространенную идиому git.

затем в локальном РЕПО для пользователя a:

feature1
feature2

и получить его на центральный сервер (origin):

git push origin feature1:users/a/feature1

(это, вероятно, можно упростить с изменения конфигурации)

в любом случае, как только feature1 будет рассмотрен, кто бы ни отвечал (в нашем случае, это разработчик функции, у вас может быть один пользователь, ответственный за слияния с master), делает следующее:

git checkout master
git pull
git merge users/name/feature1
git push

тяга делает выборку (потянув за любые новые изменения мастера и ветвь функции) и обновляет мастер того, что имеет центральный репозиторий. Если пользователь a правильно выполнил свою работу и отслеживал master, проблем со слиянием не должно быть.

все это означает, что, даже если пользователь или удаленная команда вносит изменения в двоичный ресурс, он пересматривается, прежде чем он будет включен в главную ветвь. И есть четкое разграничение (основанное на процессе), когда что-то входит в главную ветвь.

вы также можете программно применять аспекты этого используя крючки git, но опять же, я еще не работал с ними, поэтому не могу говорить о них.

когда я использовал Subversion, я религиозно установил svn:needs-lock свойство на всех двоичных и даже трудно редактировать текстовые файлы. Я!--2-->никогда на самом деле испытал любые конфликты.

теперь в Git, я не беспокоюсь о таких вещах. Помните: блокировки в Subversion на самом деле не являются обязательными блокировками, они просто инструменты связи. И угадайте, что: мне не нужна Subversion для общения, я могу справиться с электронной почтой, телефоном и IM.

еще одна вещь, которую я сделал, это заменить многие двоичные форматы текстовыми форматами. Я использую reStructuredText или LaT_ΕΧ вместо Word, CSV вместо Excel, ASCII-Art вместо Visio, YAML вместо баз данных, SVG вместо Oo Draw, abc вместо MIDI и так далее.

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

Я обсудил этот вопрос в дискуссионных группах git и пришел к выводу, что в настоящее время нет согласован метод централизованной блокировки файлов для git.

TortoiseGit поддерживает полный рабочий процесс git для документов Office, делегирующих diff самому Office. Он также работает делегирование OpenOffice для форматов OpenDocument.

Я бы не ожидал, что блокировка файлов когда-либо сделает ее функцией в git. Какие двоичные файлы вас в первую очередь интересуют? Вы действительно заинтересованы в блокировке файлов или просто предотвращении конфликтов, вызванных невозможностью их слияния.

Я, кажется, помню, что кто-то говорил (или даже реализовывал) поддержку слияния OpenOffice-документов в git.

Как насчет файлов cad? Если файлы не заблокированы, для хранения только для чтения, большинство cad-программ просто откроют их произвольные биты изменения, рассматриваемые как новый файл любым vcs. Поэтому, на мой взгляд, блокировка является идеальным средством для передачи вашего намерения изменить какой-либо файл particalur. Кроме того, это предотвращает некоторое программное обеспечение, чтобы получить доступ к записи в первую очередь. Это позволяет обновлять локальные файлы, без необходимости закрывать программное обеспечение или, по крайней мере, все файлы полностью.

просто поместите текстовый файл в cc с файлом, который вы хотите заблокировать, а затем отклоните его.

возможно, это правда, что реорганизация проекта может помочь избежать блокировок, но:

• команды также организованы по другим приоритетам (местоположение, клиенты,...)
• инструменты также выбираются другими целями (совместимость, цена, простота использования большинством сотрудников)
• некоторые инструменты (и, следовательно, двоичные файлы) нельзя избежать, так как просто нет замены, которая может выполнять ту же работу, приспосабливая то же самое к потребностям компании для того же цена.

просить, чтобы вся компания могла реорганизовать свой рабочий процесс и заменить все свои инструменты, которые производят двоичные файлы, только для того, чтобы иметь возможность работать с git из-за отсутствия блокировок, звучит довольно неэффективно.

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

Это не решение, а комментарий о том, почему необходимы механизмы блокировки. Есть некоторые инструменты, используемые в некоторых областях, которые используют только двоичные форматы, которые имеют решающее значение, и "использовать лучшие/разные инструменты" просто не вариант. Нет жизнеспособных альтернативных инструментов. Те, с которыми я знаком, действительно не будут кандидатами на слияние, даже если вы сохранили ту же информацию в формате ascii. Одно возражение, которое я слышал, что вы хотите иметь возможность работать не в сети. Конкретный инструмент, о котором я думаю, действительно не работает в автономном режиме из-за необходимости вытаскивать лицензии, поэтому, если у меня есть данные на ноутбуке, я все равно не могу запустить инструмент в поезде. Тем не менее, что Git предоставляет, если у меня Медленное соединение, я могу получить лицензии, а также отменить изменения, но иметь быструю локальную копию для просмотра разных версий. Это хорошая вещь, которую DVCS дает вам даже в этом случае.

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

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

Я не предлагаю использовать Git в моей компании для той же проблемы. Мы используем EA для всех наших проектов и Microsoft word для документации, мы не знаем заранее, кто может редактировать конкретный файл, поэтому эксклюзивная блокировка - наш единственный вариант.

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

Если ваша организация требует командной среды (обычно, чтобы лишить разработчиков безопасности заданий), то используйте svn, git не для вас. Svn обеспечивает как управление версиями, так и связь между разработчиками о блокировках.

Git не предоставляет никаких команд для блокировки файлов, но я финансирую способ достижения этой функции с помощью крючков git. Для хранения информации о блокировке необходим вспомогательный сервер. Мы можем использовать крюк предварительной фиксации, чтобы проверить, заблокирован ли какой-либо из зафиксированных файлов. И если кто-то блокирует файл, программа должна сообщить вспомогательному серверу информацию о шкафчике и заблокированном файле.