Как состояние git может отражать изменения, сделанные другими пользователями в общей среде?
Вопрос этой темы связан с тем, что gitguys.com, по-видимому, требует, чтобы объяснить, что "выходные данные статуса git не должны изменяться" в среде нескольких пользователей, работающих с хранилищем NON-NARE ( http://www.gitguys.com/topics/shared-repositories-should-be-bare-repositories/)
На вышеупомянутой веб-странице поясняется, что если кто-то создал "репозиторий git без обнажений, в котором пользователь git репозитория и удаленные пользователи обновляли базу данных объектов git. Создатель репозитория non-bare git использовал бы команду git status одну минуту и посмотрите это: $ git status
# On branch master
nothing to commit (working directory clean)
В следующую минуту удаленный пользователь может внести изменения в не-пустой репозиторий. Затем, когда создатель репозитория git непонятного типа вводит git status, git находит другую базу данных объектов и дает разные результаты для этого прогона состояния git."Учебное пособие завершается следующим утверждением, которое мне сложно объяснить, основываясь на том, что Я знаю:вывод статуса git не должен изменяться, если пользователь не изменил файлы в рабочем каталоге или в своей объектной базе данных!
Я нахожу это "трудно объяснить", потому что это утверждение является обоснованием того, почему голые репозитории (в отличие от непокрытых репозиториев) должны использоваться в среде центрального репозитория, где несколько пользователей совместно используют этот репозиторий. Мне кажется, что это утверждение не является правильным, и поэтому трудно рассуждать, почему в среде разработки для нескольких пользователей требуются пустые репозитории. Это неверно, потому что подразумевает, что на состояние GIT влияет состояние хранилища серверов, так как я думал, что состояние git учитывает только локальные файловые объекты.git и рабочий каталог (т. Е. Не на сервере).
Пожалуйста, обратите внимание, что я пытался объяснить, почему пустые репозитории являются необходимыми, просто не принимая как данность, что пустые репозитории хороши для общей среды - но до сих пор я не делал этого с большим успехом (в том числе на этом сайте, возможно, потому что я не поставил проблему под рукой должным образом, я надеюсь, что на этот раз я понял это правильно, насколько изложил проблему)
Может ли кто-нибудь объяснить, как это может быть, что даже при работе с непокрытыми репозиториями с несколькими пользователями (предположим, 2 пользователя: USER A и USER B), например, USER A может получить 2 разных результата при выдаче состояния git из-за изменения с последующим git push пользователем USER B
1 ответ
Мне кажется, хотя я могу ошибаться, что у вас есть проблемы с пониманием того, как команда может эффективно сотрудничать в проекте через удаленное хранилище.
Я объясню некоторые основные понятия, прежде чем приступить к решению вашей путаницы.
Сначала давайте определим, что именно представляет собой удаленный репозиторий. В мире git удаленный репозиторий - это не что иное, как репозиторий, который вы зарегистрировали в своем локальном репозитории через git remote командование
Этот репозиторий даже не должен иметь общую историю с вашим локальным репозиторием, он не должен быть пустым, он не должен существовать на сервере - он может даже находиться в той же папке на вашем локальном компьютере - он просто нужно зарегистрироваться через git remote в вашем локальном хранилище, чтобы считаться удаленным хранилищем.
Довольно общий, не так ли?
При работе в команде общим рабочим процессом в git будет определение центрального хранилища, которое все разработчики регистрируют как удаленные. При клонировании репозитория (git clone) этот репозиторий будет иметь клонированный репозиторий, зарегистрированный как удаленный репозиторий.
Теперь каждый разработчик может работать локально и вносить свои изменения в этот центральный репозиторий; другие разработчики могут получить эти изменения оттуда.
Но так не должно быть.
Git - это распределенная система контроля версий, это означает, что каждый клон репозитория является полной резервной копией и может функционировать как удаленный репозиторий (если использовать термин git).
Что это значит для нас? Это означает, что рабочий процесс только в центральном репозитории является общим соглашением в команде рассматривать этот репозиторий как истинный.
Теперь вернемся к вашей путанице:
Пока вы, например, следите за рабочим процессом центрального хранилища, никакое нажатие не изменит ваш локальный клон хранилища (означает git status никогда не "изменится сам по себе").
Если я правильно понял ваши комментарии, пользователь B клонировал репозиторий пользователя A. Что мы узнали о клонировании хранилища? Хранилище пользователя A теперь считается удаленным хранилищем в клоне пользователя B.
Это означает, что каждый push-запрос пользователя B будет вносить свои изменения в репозиторий пользователя A - по умолчанию git не разрешает вставки в не-пустые репозитории, но это возможно. Такой толчок может эффективно изменить вывод git status хотя пользователь A не внес никаких изменений, но пользователь B сделал это с его толчком.