Удалённые репозитории

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

Сценарий lesson-13 в архиве использует только новые папки на вашем компьютере: общий bare-репозиторий и две учебные копии alice и bob. Bare означает хранилище истории без обычного рабочего дерева. Инструкции подготовлены для ручного выполнения; обмен, коммиты и команды не выполнялись. Настоящий GitLab и репозиторий ProfessorWeb здесь не используются.

Общая точка и две копии

Исходный снимок сохраняет каталог с двумя правильными ссылками. В отдельной папке seed сценарий создаёт первую запись и передаёт её в новый catalog-origin.git. Затем две копии получают одинаковую историю. Имя origin обозначает настроенный путь к этому локальному хранилищу; само имя не говорит, находится ли оно в интернете или на соседнем диске.

В копии alice добавьте в конец README строку «Редакционные задачи обсуждаются до объединения.» и сохраните её отдельным коммитом. Эта запись обозначается A1. До передачи другие копии о ней не знают. История общего хранилища ещё заканчивается исходным S, как и копия bob.

alice: S — A1  main
origin: S      main
bob: S         main, origin/main

Схема показывает указатели, а не фактический вывод. В лаборатории передача производится командой git push origin main из alice. Она обновит общую ветку при соблюдении правил приёма. Руководство push описывает отправку объектов и обновление ссылок; в нашей модели разрешён обычный переход вперёд, без переписывания общей истории.

После передачи общий main указывает на A1, однако README в bob пока прежний. Это ожидаемо: две рабочие папки не являются одной общей папкой с мгновенно синхронизируемыми файлами. Для сайта такое различие важно ещё до обсуждения деплоя: сохранённая кем-то запись не обновляет автоматически вашу сборку.

Получение без объединения

Перейдите в копию bob и прочитайте настройки удалённого хранилища. Убедитесь, что путь относится к подготовленной лаборатории. Затем получите изменения:

git remote -v
git fetch origin
git log --oneline --decorate --all

Ожидается, что origin/main переместится на A1, а локальный main останется на S. origin/main — локальная ссылка с последними полученными сведениями об общей ветке. Она не является непрерывным просмотром текущего состояния сервера. Если коллега передаст ещё одну запись после вашего получения, ссылка останется прежней до нового обновления.

Документация fetch описывает получение объектов и ссылок. В упражнении важно наблюдение: получение доступной истории само по себе не добавило новый абзац в рабочий README. Вы можете сначала изучить изменение и решить, как его включить в собственную работу.

git log --oneline main..origin/main
git diff main origin/main -- README.md
git status --short

Ожидается одна новая запись и добавленный абзац. Рабочее дерево остаётся чистым. Здесь две разные формы сравнения помогают разным вопросам: список записей показывает историю, а различие файлов показывает содержание. В этой маленькой линии они описывают одну задачу, но в большой истории могут заметно отличаться.

Явное обновление собственной ветки

В bob нет собственных новых коммитов, поэтому можно переместить локальный main обычным fast-forward:

git switch main
git merge --ff-only origin/main

Теперь ожидается новый абзац в рабочем README и совпадение обеих ссылок на A1. Параметр --ff-only ограничивает действие случаем, когда собственная линия не расходится с полученной. Если у bob уже были независимые записи, операция остановится, и способ согласования потребует отдельного решения.

Добавьте в README следующий абзац «В локальном примере нет выпуска на хостинг.» и сохраните его в копии bob отдельной записью B1. До передачи схема теперь обратная: локальный main впереди известного origin/main. Получение и передача отвечают разным направлениям обмена; их нельзя заменить одним общим словом «синхронизировать», не уточнив намерение.

git log --oneline origin/main..main
git push origin main

В заданной модели общая ветка ещё на A1, поэтому ожидается обычная передача B1. Если alice успеет передать независимую новую запись, отправка bob может быть отклонена. Не исправляйте такой отказ принудительной отправкой. Получите новую историю, прочитайте обе задачи и согласуйте их обычным объединением или принятым процессом команды.

Названия копий обозначают роли, а не права доступа. Alice и Bob в лаборатории имеют одинаковую возможность читать и передавать историю в новую bare-папку. На настоящем сервере назначение ветки может ограничивать приём изменений, а чтение проекта может требовать отдельного доступа. Поэтому ошибка «отправка запрещена» не обязательно означает расхождение графа. Сначала прочитайте причину отказа и договор проекта. Наш сценарий выделяет только обычное движение ветки вперёд и момент получения сведений. Отсутствующие правила аккаунта не нужно угадывать по локальной модели. Она помогает увидеть, что именно передаётся, но не заменяет настройку прав команды или выбор способа совместной работы. Постоянные ссылки внутри файлов при таком обмене не меняются сами по себе.

Границы локальной модели

Успешный push означает принятую историю в выбранном репозитории, но не наличие Merge Request, одобрение ревью или опубликованную версию сайта. В нашей лаборатории вообще нет хостинга. При переносе работы в GitLab дополнительно появляются доступы, защищённые ветки и правила процесса, которых bare-папка сама по себе не моделирует.

В реальном проекте не подставляйте в эти команды случайный существующий remote. Сначала прочитайте назначение и убедитесь, что работа относится к нужному проекту и ветке. Учебный пример намеренно использует локальные пути и вымышленные имена: он позволяет рассмотреть направление обмена без настоящих токенов и внешних действий.

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

Конечное ожидаемое состояние bob содержит обе новые заметки README, две неизменные ссылки и чистое дерево. Общая ветка имеет последовательность S, A1, B1. Мы проследили три разных состояния и явно включили полученную работу. В следующем уроке подготовим изменение так, чтобы его было удобно обсуждать до объединения.