Блокування двійкових файлів за допомогою системи контролю версій git

Протягом півтора років я не зводив очей з git-спільноти в надії перейти від SVN. Однією з особливих проблем, що стримують мене, є неможливість заблокувати двійкові файли. Протягом минулого року я ще не бачив подій з цього питання. Я розумію, що блокування файлів суперечить фундаментальним принципам розподіленого контролю джерел, але я не бачу, як компанія веб-розробників може скористатися перевагами git для відстеження змін вихідного коду та файлів зображень, коли існує можливість конфліктів бінарних файлів.

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

Чи має хтось із вас досвід роботи з git та бінарними файлами, які слід заблокувати перед внесенням змін?

ПРИМІТКА. Схоже, новий проект розподіленого контролю версій Source Gear, Veracity, є блокуванням однією з своїх цілей.

Git LFS 2.0 додав підтримку блокування файлів.

За допомогою Git LFS 2.0.0 тепер ви можете блокувати файли, над якими ви активно працюєте, не даючи іншим натискати на сервер Git LFS, поки ви знову не розблокуєте файли.

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

Subversion має замки, і вони не просто рекомендаційні. Їх можна застосувати за допомогою svn:needs-lockатрибута (але їх також можна навмисно зламати, якщо це необхідно). Це правильне рішення для управління файлами, що не об’єднуються. Компанія, в якій я працюю, зберігає майже все в Subversion і використовує svn:needs-lockдля всіх файлів, що не об’єднуються.

Я не погоджуюся з тим, що "замки - це лише спосіб спілкування". Вони є набагато ефективнішим методом, ніж push-повідомлення, такі як телефон або електронна пошта. Замки диверсії самодокументуються (хто має замок). З іншого боку, якщо вам доводиться спілкуватися іншими традиційними каналами push-сповіщень, наприклад електронною поштою, кому ви надсилаєте сповіщення? Ви не знаєте заздалегідь, хто може захотіти редагувати файл, особливо в проектах з відкритим кодом, якщо у вас немає повного списку всієї вашої команди розробників. Тож ці традиційні методи спілкування не настільки ефективні.

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

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

Ось цікаве читання за темою.

Я згоден з тим, що блокування двійкових файлів є необхідною функцією для деяких середовищ. Я просто думав про те, як це реалізувати:

• Майте спосіб позначити файл як "needs-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

А щоб отримати його на центральному сервері (джерело):

git push origin feature1:users/a/feature1

(це, можливо, можна спростити за допомогою змін конфігурації)

У будь-якому випадку, після перевірки feature1 хтось несе відповідальність (у нашому випадку це розробник функції, у вас може бути один користувач, який відповідає за злиття, щоб виконати майстер), робить наступне:

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

Витягування виконує вибірку (витягуючи будь-які нові зміни майстра та гілку функції) та майстер оновлень до того, що має центральне сховище. Якщо користувач а виконав свою роботу і відстежив майстра належним чином, проблем із об’єднанням не повинно бути.

Все це означає, що навіть якщо користувач або віддалена команда вносить зміни в двійковий ресурс, він переглядається перед тим, як його включити в головну гілку. І є чітке розмежування (на основі процесу) щодо того, коли щось переходить у головну гілку.

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

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

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

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

Зараз, у Git, я не турбуюся про такі речі. Пам’ятайте: блокування в Subversion насправді не є обов’язковими блокуваннями, це лише засоби комунікації. І вгадайте: мені не потрібна Subversion для спілкування, я чудово впораюся з електронною поштою, телефоном та миттєвими повідомленнями.

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

Це не рішення, а скоріше коментар щодо того, навіщо потрібні механізми блокування. Є деякі інструменти, що використовуються в деяких областях, які використовують лише двійкові формати, які є чітко визначеними для критичних завдань, і "використовувати краще / різні інструменти" просто неможливо. Немає життєздатних альтернативних інструментів. Ті, з ким я знайомий, насправді не будуть кандидатами на об’єднання, навіть якщо ви зберігаєте ту саму інформацію у форматі ascii. Я почув одне заперечення проти того, що ви хочете мати можливість працювати в автономному режимі. Конкретний інструмент, про який я думаю, насправді не працює в автономному режимі через необхідність витягувати ліцензії, тому якщо у мене є дані на ноутбуці, це не схоже на те, що я все одно можу запустити інструмент у поїзді. Тим не менш, що git надає, якщо у мене повільне з'єднання, Я можу отримати ліцензії, а також знизити зміни, але маю швидку локальну копію для перегляду різних версій. Це приємно, що DVCS дає вам навіть у цьому випадку.

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

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

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

Здається, я пам’ятаю, як хтось говорив (або навіть реалізовував) підтримку злиття OpenOffice-документів у git.

А як щодо файлів CAD? Якщо файли не заблоковані, а також залишатимуться лише для читання, більшість програм CAD просто відкриють їм зміни довільних бітів, які будь-які vcs розглядають як новий файл. Отже, на мій погляд, блокування є ідеальним засобом для повідомлення про ваш намір змінити якийсь файл particalur. Крім того, це заважає деякому програмному забезпеченню отримати доступ до запису в першу чергу. Це дозволяє оновлювати локальні файли без необхідності повністю закривати програмне забезпечення або принаймні всі файли.

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

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

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

Якщо ваша організація вимагає командного середовища (зазвичай для позбавлення розробників безпеки роботи), тоді використовуйте svn, git не для вас. Svn забезпечує як управління джерелами, так і зв'язок між розробниками щодо замків.

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

Може бути правдою, що реорганізація проекту може допомогти уникнути блокування, але:

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

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

Блокування не вписуються у філософію git (яка ніколи не створювалася для двійкових файлів), але існують ситуації, якими не можна знехтувати, коли замки є найбільш ефективним способом вирішення такої проблеми.

Git не надає жодної команди для блокування файлів, але я фінансую спосіб досягнення цієї функції за допомогою git hooks. Для зберігання інформації про блокування потрібен допоміжний сервер. Ми можемо скористатися гачком перед фіксацією, щоб перевірити, чи не заблоковано якийсь із фіксованих файлів. І якщо хтось заблокує файл, програма повинна повідомити допоміжний сервер інформацію шафки та заблокованого файлу.