Блок 1. Урок 2: Синхронизация с удалённым

Урок 2. Синхронизация с удалённым репозиторием

Зачем это тебе

Деплой работает так: Jenkins забирает код из Bitbucket, собирает и выкатывает. Твои локальные коммиты должны попасть в Bitbucket — это git push; чужие правки забираются командой git pull. Урок 2 — ежедневный сценарий «забрал код → поправил → вернул» на командной строке: в CLI видно, какие коммиты ушли, какие пришли и что разошлось.

remote и origin

Remote (удалённый репозиторий) — копия репозитория на сервере (у вас — Bitbucket). Привязка к нему тоже называется remote: хранит имя и URL.

origin — стандартное имя первой привязки. После git clone URL git сам создаёт привязку origin на тот URL, откуда скопировал проект; все команды по умолчанию работают с ним.

• git remote -v — список имён remote и их URL.

• git clone URL — скачивает репозиторий со всей историей в новую папку, настраивает origin.

Три команды синхронизации

• git push — локальные коммиты → на сервер (отправить).

• git fetch — сервер → локально, но только «снимок» серверных веток: рабочие файлы и локальные ветки не меняются. Обновляются remote-ветки origin/main.

• git pull — сервер → локально с обновлением файлов: git fetch + слияние в текущую ветку.

Первый push новой ветки делается с -u (upstream): git push -u origin main — git запоминает связку ветки с удалённой, дальше достаточно git push.

git status сообщает диагноз: ahead by N — N локальных коммитов ещё не на сервере (нужен push); behind by N — на сервере есть коммиты, которых нет локально (нужен pull); diverged — ветки разошлись: есть свои коммиты и там, и тут (сначала fetch, посмотреть diff, объединить).

git diff и git log

• git diff — рабочая копия vs индекс.

• git diff --staged — индекс vs последний коммит.

• git diff HEAD — рабочая копия + индекс vs последний коммит.

• git diff origin/main — локальная ветка vs ветка на сервере, без слияния.

• git log --oneline --graph — история с графом веток и слияний.

• git log --oneline origin/main..HEAD — коммиты, ещё не запушенные (перед push).

• git log --oneline HEAD..origin/main — коммиты с сервера, ещё не влитые (перед pull).

• git log -p — история с текстом изменений каждого коммита.

Сквозной пример

Имитация сервера локально (bare-репозиторий):

git init --bare server.git

git clone /tmp/remote-server/server.git project
cd project
echo "Первый код" > app.txt
git add app.txt
git commit -m "Первый коммит"
git push -u origin main

Правка и отправка: git add + git commit → git status показывает «ahead by 1» → git push. Вторая копия (colleague) пушит свою правку → в project статус «behind by 1» → git pull забирает её → git log --oneline --graph показывает общую историю.

Типичные ошибки

• Fetch ≠ обновление файлов. Fetch скачивает снимок серверных веток; файлы меняет pull (или merge).

• Отказ non-fast-forward. На сервере есть коммиты, которых нет локально: git не перезаписывает чужую историю. Лечится git pull, затем push.

• git push --force — принудительная перезапись истории на сервере, риск стереть чужое; в общей ветке не используется без согласования.

• Забыл проверить, куда пушишь. git branch -vv показывает связку локальной ветки с удалённой.

• Секреты. Закоммиченный токен навсегда остаётся в истории: менять сам секрет, а не только удалять файл.

Итог

Связка с сервером называется remote, её имя по умолчанию — origin. git push отправляет локальные коммиты на сервер, git fetch скачивает снимок серверных веток без изменения файлов, git pull (fetch + merge) забирает изменения в текущую ветку. Статусы ahead / behind / diverged в git status — готовый диагноз расхождений.

Источники

Учебный план «Блок 1. Инструменты, которые трогаешь каждый день» (урок 2), составлен для курса автором.