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

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

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

Вот интересное чтиво на эту тему.

Answer 3

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

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

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

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

Answer 4

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

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

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

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

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

Answer 5

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

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

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

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

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

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

feature1
feature2

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

git push origin feature1:users/a/feature1

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

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

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

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

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

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

Answer 6

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

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

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

Answer 7

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

Answer 8

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

Answer 9

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

Answer 10

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

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

Answer 11

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

Answer 12

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

Answer 13

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

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

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

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

Answer 14

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

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

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

Answer 15

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

Answer 16

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

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

Answer 17

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