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

В Git LFS 2.0 добавлена ​​поддержка блокировки файлов.

С Git LFS 2.0.0 теперь вы можете блокировать файлы, над которыми вы активно работаете, не позволяя другим пользователям отправлять их на сервер Git LFS, пока вы снова не разблокируете файлы.

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

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

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

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

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

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

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

• Имейте способ пометить файл как «need-lock» (например, свойство «svn: needs-lock»).
• При оформлении заказа git пометит такой файл как доступный только для чтения.
• Новая команда git-lock свяжется с запущенным где-то сервером центрального замка и попросит разрешения на блокировку.
• Если сервер блокировки предоставляет разрешение, отметьте файл для чтения и записи.
• git-add сообщит серверу блокировки хэш содержимого заблокированного файла.
• Сервер блокировки будет следить за тем, чтобы этот хэш содержимого появился в фиксации в главном репозитории.
• Когда появится хеш, снимите блокировку.

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

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

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

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

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

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

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

Мы только недавно начали использовать Git (ранее использовали Subversion), и я нашел изменение в рабочем процессе, которое может помочь в решении вашей проблемы без необходимости блокировок. Он использует то, как разработан 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, кто несет ответственность (в нашем случае это разработчик функции, у вас может быть один пользователь, ответственный за слияние с главным), делает следующее:

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

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

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

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

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

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

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

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

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

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

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

Это не решение, а скорее комментарий о том, зачем нужны механизмы блокировки. В некоторых областях используются некоторые инструменты, которые используют только двоичные форматы, которые являются критически важными, и «использовать лучшие / другие инструменты» просто не вариант. Нет альтернативных жизнеспособных инструментов. Те, с которыми я знаком, действительно не были бы кандидатами на слияние, даже если бы вы сохранили ту же информацию в формате ascii. Я слышал одно возражение: вы хотите работать в автономном режиме. Конкретный инструмент, о котором я думаю, действительно не работает в автономном режиме из-за необходимости извлекать лицензии, поэтому, если у меня есть данные на ноутбуке, я все равно не смогу запустить инструмент в поезде. Тем не менее, что предоставляет git, если у меня медленное соединение, я могу получать лицензии, а также снимать изменения, но иметь быструю локальную копию для просмотра разных версий. Это хорошая вещь, которую DVCS дает вам даже в этом случае.

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

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

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

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

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

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

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

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

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

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

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

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

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