Блокировка бинарных файлов с помощью системы контроля версий git - PullRequest
73 голосов
/ 23 сентября 2008

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

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

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

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

Ответы [ 17 ]

74 голосов
/ 13 июня 2009

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

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

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

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

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

10 голосов
/ 23 сентября 2008

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

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

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

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

10 голосов
/ 26 сентября 2008

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

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

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

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

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

8 голосов
/ 24 сентября 2008

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

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

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

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

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

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

feature1
feature2

И чтобы получить его на центральном сервере (источник):

git push origin feature1:users/a/feature1

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

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

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

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

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

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

6 голосов
/ 24 сентября 2008

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

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

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

6 голосов
/ 26 апреля 2017

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

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

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

5 голосов
/ 23 сентября 2008

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

4 голосов
/ 26 сентября 2008

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

2 голосов
/ 13 февраля 2011

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

1 голос
/ 01 сентября 2009

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...