Урок 04 · Одно понятие

origin, push и pull: две истории и обмен между ними

На твоём компьютере лежит полная история проекта. На GitHub лежит полная история проекта. Между ними нет ни одной автоматической связи.

~15 минутнужен урок 2вводить в терминал ничего не надо

Облачный диск и Git

Начать стоит с привычки, которая здесь мешает. Облачные диски приучили к одной модели: положил файл в папку — он сам уехал на сервер, сам появился на других устройствах, сам обновился, когда его изменили. Ты в этом не участвуешь.

Git устроен наоборот, и это не недоделка, а замысел. Его придумали для работы без постоянной связи: в поезде, в самолёте, на даче с одной палочкой сигнала. Поэтому вся история проекта целиком лежит у тебя на диске, и работать с ней можно, ни с кем не соединяясь.

Отсюда главное следствие, из-за которого потом возникают все недоразумения:

Две полные копии

Слово «сервер» сбивает с толку: кажется, что там лежит что-то главное, а у тебя — рабочая копия. На самом деле обе стороны устроены одинаково.

Единственное реальное отличие — в последней строке. У тебя проект развёрнут в папку, которую видно в Finder. На GitHub развёрнутых файлов нет, там только хранилище; то, что ты видишь в браузере, — это отрисовка содержимого по запросу.

«Главный» репозиторий главный не технически, а по договорённости. Команда просто условилась считать копию на GitHub точкой сборки. Git об этой договорённости ничего не знает.

origin: кличка, а не место

У удалённого хранилища есть адрес — что-то вроде git@github.com:ykurilov/myapp.git. Писать его в каждой команде неудобно, поэтому адресу дают короткое имя. По традиции — origin.

Слово ничего не означает само по себе. Это не «главный», не «облако» и не «сервер» вообще. Это кличка конкретного адреса, записанная в настройках твоего проекта. Её можно поменять, а хранилищ можно подключить несколько: скажем, origin — твоя копия, upstream — чужая, из которой ты её сделал.

Откуда кличка берётся: когда проект скачивают командой git clone, Git сам записывает адрес, откуда качал, под именем origin. Отсюда и название — «источник», то место, откуда всё пришло.

Обмен по шагам

Дальше проще смотреть, чем читать. Пройди историю по шагам: слева твой компьютер, справа GitHub. Зелёным подсвечены коммиты, которых нет на другой стороне.

push и pull

Две команды, и обе всегда запускают вручную.

Запомнить направление помогает буквальный перевод: push — толкнуть от себя, pull — потянуть к себе.

Важная деталь про push: он отправляет коммиты, а не файлы из папки. Всё, что не закоммичено, не уедет никуда, сколько ни отправляй. Если агент сказал «запушил», а на GitHub пусто — почти наверняка он не сделал коммит.

origin/main: твоя память о сервере

Вот место, где ломаются почти все — потому что сущностей оказывается три, а не две.

В твоей истории живут две метки с похожими именами:

Обрати внимание на формулировку: не «где она сейчас», а «где была». origin/main лежит на твоём диске и обновляется только тогда, когда ты соединяешься с сервером. Это не сама удалённая ветка, а твоя запись о ней.

Как фотография доски в переговорке. Ты сфотографировал — снимок лежит в телефоне. Пока не зайдёшь в переговорку снова, ты не узнаешь, что на доске дописали ещё три строчки. Снимок при этом не врёт: он честно показывает, что было в момент съёмки.

Поэтому фраза «на GitHub этого нет, я только что смотрел» ничего не доказывает: смотреть надо было не в свою память, а на сервер.

fetch: разведка без последствий

Сходить и посмотреть, ничего у себя не меняя, — это git fetch. Он идёт на сервер, обновляет метку origin/main и на этом останавливается. Твоя ветка, твои файлы, твоя папка — нетронуты.

А git pull — это два действия подряд:

git pull  =  git fetch        ← сходить и обновить память
           + слить с твоей веткой  ← вот тут меняются файлы

Разница практическая. fetch безопасен всегда: он только приносит сведения. pull лезет в твою работу и может упереться в конфликт, если вы с кем-то правили одно и то же место.

Отклонённый push

Рано или поздно агент упрётся в это и напишет что-то вроде ! [rejected] main -> main (fetch first).

Читается так: на сервере есть коммиты, которых нет у тебя. Кто-то — коллега, второй агент, ты сам из другого worktree — успел отправить свою работу раньше.

Git отказывается не из вредности. Если бы он молча принял твою отправку, чужие коммиты пришлось бы куда-то деть, а деть их можно только выбросив. Отказ — это защита чужой работы.

Правильный выход всегда один и тот же: сначала забрать чужое к себе, разобраться, как оно уживается с твоим, и только потом отправлять. Как именно Git соединяет две разошедшиеся линии — тема следующего урока.

Force push и стёртая работа

У отказа есть способ обхода: git push --force. Он говорит серверу «выброси то, что у тебя, и запиши то, что у меня».

Работает безотказно. Проблема ровно в слове «выброси»: чужие коммиты исчезают с сервера, и человек, который их отправил, узнаёт об этом не сразу.

Практический вывод для тебя: это первый кандидат в список запретов для агента. Не потому, что агент злонамеренный, а потому, что --force — самый короткий способ убрать препятствие, и модель на него натыкается естественным образом.

Как сказать агенту

Проверь себя