it-roy-ru.com

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

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

Чтобы добиться эффекта блокировки, должен быть идентифицирован «центральный» репозиторий. Независимо от распределенной природы git, у большинства компаний будет «центральный» репозиторий для программного проекта. Мы должны иметь возможность пометить файл как требующий блокировки из управляющего репозитория git по указанному адресу. Возможно, это затрудняется, потому что git отслеживает содержимое файла, а не файлы?

У кого-нибудь из вас есть опыт работы с git и бинарными файлами, которые должны быть заблокированы перед изменением?

ПРИМЕЧАНИЕ. Похоже, что в новом проекте управления распределенными версиями Source Gear с открытым исходным кодом Veracity одной из целей является блокировка.

72
Mario

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

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

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

6
osowskit

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

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

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

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

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

74
Craig McQueen

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

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

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

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

10
Greg Hewgill

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

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

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

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

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

10
Michael Johnson

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

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

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

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

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

Затем в локальном репо для пользователя:

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 hooks, но, опять же, я еще не работал с ними, поэтому не могу говорить о них.

8
Michael Johnson

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

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

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

6
Jörg W Mittag

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

5
Khoth

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

3
Mario

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

2
Antonio Bardazzi

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

1
aproposd

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

1
Remote Shell

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

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

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

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

1
Stefan

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

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

1
JesperE

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

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

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

1
Dan

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

0
Hernan Rajchert

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

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

0
alpav

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

0
Cherler Ton