Возможны ли параллельные операции с Git-репозиториями?

Есть два сценария, которые меня интересуют.

Хранилище является общим, и два пользователя хотят одновременно вносить в него измененияЯ хочу запланировать ночной или еженедельный "gc", используя работу cron. Он запускается, и кто-то хочет нажать или клонировать во время операции.

Есть ли риск коррупции в любом из этих сценариев?

 dromodel23 окт. 2012 г., 23:29
можете ли вы предоставить ссылку?
 cmbuckley23 окт. 2012 г., 23:54
q8424232; q6028141 тоже может быть интересно
 cmbuckley23 окт. 2012 г., 23:04
Для # 1, я полагаю, вы говорите о одновременных нажатиях на разные ветви? Ответы на одновременную передачу в ту же ветку находятся в другом месте на SO.

Ответы на вопрос(3)

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

git gc"может удалить объекты, которые использует другой параллельный процесс, но не создал ссылку.
У Git 2.12 (1 квартал 2017 года) есть больше об этом.

Видетьсовершить f1350d0 (15 ноября 2016 г.)Мэтт Маккатчен (mattmccutchen).
(ОбъединеноJunio C Hamano -gitster - всовершить 979b82f10 января 2017 г.)

И увидетьКомментарий Джеффа Кинга:

Современные версии git делают две вещи, чтобы помочь с этим:

любой объект, на который ссылается «недавний» объект (в течение 2 недель), также считается недавним. Поэтому, если вы создаете новый объект коммита, который указывает на дерево, даже до того, как вы ссылаетесь на коммит, это дерево защищено

когда запись объекта оптимизирована, потому что у нас уже есть объект, git обновит mtime в файле (свободный объект или файл пакета), чтобы освежить его

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

Если у вас есть долгосрочные данные (например, временный индексный файл, который может буквально сидеть без дела несколько дней или недель), я думаю, что это потенциальная проблема. И решение, вероятно, заключается в том, чтобы как-то использовать ссылки для указания на ваши объекты.
Если вы беспокоитесь о краткосрочной операции, где кто-то может запуститьgit-gc Одновременно я согласен, что это возможная проблема, но я подозреваю, что вы можете игнорировать это на практике.

Для многопользовательского сервера я рекомендую полностью отключить auto-gc и перепаковать вручную с помощью "-k«быть на безопасной стороне.

Вот почемуgit gc справочная страница теперь включает в себя:

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

Git имеет две функции, которые значительно уменьшают эту проблему:

Любой объект с временем модификации более новым, чем--prune дата сохраняется вместе со всем достижимым.

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

Однако этим функциям не хватает полного решения, поэтому пользователям, которые одновременно запускают команды, приходится сталкиваться с некоторым риском повреждения (что на практике кажется низким), если они не отключают автоматический сбор мусора с помощью «git config gc.auto 0». ,

Пессимистический Параллельный Контроль.

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

В частности, каждый раз, когда индекс изменяется операцией, git создает файл с именемindex.lock в.git каталог для блокировки общего ресурса. Git создает при необходимости другие файлы блокировки: например,.keep файл создается во времяGit Index-Pack операции.

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

Кто-то может сказать, что вы не должны беспокоиться о выполненииgc с работой cron, так как сам git запускаетgc временами. Даже если это правда,справочная страница сам рекомендует:

Users are encouraged to run this task on a regular basis 
within each repository to maintain good disk space utilization
and good operating performance.

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

Ваш ответ на вопрос