Отправить ветку и настроить tracking

В прошлом уроке мы сделали clone и увидели, что Git автоматически регистрирует origin и создаёт remote-tracking ветки вроде origin/main. Origin хранит адрес источника, а upstream связывает конкретную локальную ветку с её remote-tracking веткой. Для новой feature эта связь задаётся при первой отправке с флагом -u; после неё следующие коммиты можно отправлять обычным push в том же учебном clone.

Tracking-связь: что такое upstream локальной ветки

Remote origin — это просто именованный адрес другого репозитория. Сам по себе он не говорит Git, куда отправлять коммиты из конкретной ветки. Для этого существует отдельная настройка: upstream, или tracking-связь.

Upstream — это привязка конкретной локальной ветки к конкретной remote-tracking ветке. Например, локальная ветка feature может быть привязана к origin/feature. Это означает, что Git знает: когда ты работаешь в feature, её «партнёр» на стороне remote — именно origin/feature.

Важно не путать два уровня:

• origin — это remote, то есть ссылка на весь репозиторий shared.git целиком.
• upstream ветки — это связь одной конкретной ветки с одной конкретной remote-tracking веткой внутри этого remote.

Наличие origin не означает автоматической upstream-связи для новых веток. Когда ты создаёшь git switch -c feature в clone, эта ветка существует только локально. У неё нет upstream до тех пор, пока ты его явно не задашь.

Настройка хранится в конфигурации именно этого clone — в его .git/config. Другие клоны того же репозитория никак не затрагиваются: у каждого клона своя таблица tracking-связей.

git push -u origin <ветка>: первая отправка и настройка upstream

Когда локальная ветка feature готова к первой отправке, нужна команда:

git push -u origin feature

Здесь origin — remote назначения, feature — имя локальной ветки. Вся команда git push -u origin feature при успешной отправке даёт три результата:

• создаёт ветку feature в remote, если её там ещё не было;
• отправляет коммиты из локальной feature в remote;
• записывает upstream: теперь локальная feature связана с origin/feature.

Создание или обновление ветки в remote и передача коммитов — эффекты push. Флаг -u (длинная форма --set-upstream) добавляет настройку upstream для отправленной локальной ветки.

В выводе команды будет подтверждение настройки связи — точная фраза зависит от версии Git, но смысл один: tracking настроен.

Если попробовать отправить новую ветку без флага -u — обычным git push — при стандартных настройках Git ответит ошибкой:

fatal: The current branch feature has no upstream branch.

Git не угадывает, куда именно отправлять ветку, и честно сообщает об отсутствии upstream. В том же сообщении он предложит точную команду с --set-upstream. Наличие origin само по себе эту проблему не решает — нужен явный -u при первой отправке.

git branch -vv и git push: чтение статуса опережения и повторная отправка

После первого git push -u origin feature команда git branch -vv показывает состояние локальных веток вместе с их upstream:

* feature 57397ed [origin/feature] Добавить версию
  main    e0b770e [origin/main] Первый справочник

Каждая строка содержит: * у текущей ветки, имя ветки, короткий хеш последнего коммита, upstream в квадратных скобках и сообщение коммита. Если у ветки нет upstream, квадратных скобок не будет вовсе.

Теперь добавим второй коммит — например, в README.md добавлена строка Автор: учебный проект:

git add README.md
git commit -m "Добавить автора"

Сразу после этого git branch -vv покажет изменение в поле upstream:

* feature 3a1c92f [origin/feature: ahead 1] Добавить автора
  main    e0b770e [origin/main] Первый справочник

ahead 1 означает: локальная ветка опережает origin/feature на один коммит, который ещё не отправлен. Git знает это потому, что у ветки настроен upstream и он может сравнить указатели.

Отправить этот коммит теперь можно без аргументов:

git push

Git сам знает, куда идти — в origin/feature. После успешной отправки снова запустим git branch -vv:

* feature 3a1c92f [origin/feature] Добавить автора
  main    e0b770e [origin/main] Первый справочник

Пометка ahead 1 исчезла: локальная ветка и origin/feature указывают на один и тот же коммит.

Проверка: оба коммита в свежем clone через git log origin/feature

После того как обе отправки завершены, можно создать второй clone и убедиться, что shared.git содержит всю историю ветки feature.

Для независимого опыта распакуйте весь git_practice.zip в новую отдельную папку через файловый менеджер. Используйте новую распаковку, а не папку после предыдущего clone: в ней my_clone и colleague_clone ещё отсутствуют. Выданный git_practice/remote/shared.git содержит начальную ветку main и один коммит; README.md в нём содержит «# Командный справочник», «Контакт: команда» и «Статус: черновик».

Используйте обычный clone с неизменёнными настройками отправки. Между вашими отправками в этот учебный remote не должно быть чужих push. Откройте терминал в новой папке распаковки. Рабочий clone создаётся и обе локальные настройки автора задаются до первого коммита:

cd git_practice
git clone remote/shared.git my_clone
cd my_clone
git config user.name "Student"
git config user.email "student@example.com"
git switch -c feature

Добавляем в README.md строку Версия: 1.0, затем:

git add README.md
git commit -m "Добавить версию"
git push -u origin feature
git branch -vv

Upstream настроен, [origin/feature] виден в выводе. Добавляем в README.md строку Автор: учебный проект:

git add README.md
git commit -m "Добавить автора"
git branch -vv

Видим [origin/feature: ahead 1]. Отправляем:

git push
git branch -vv

Пометка ahead 1 исчезла. Только теперь создаём проверочный clone:

cd ..
git clone remote/shared.git colleague_clone
cd colleague_clone
git log --oneline origin/feature

Аргумент origin/feature в команде git log — это имя remote-tracking ветки: показать историю именно этой ветки, а не текущей локальной. Новый clone получил origin/feature автоматически при создании, никаких дополнительных команд не нужно.

Вывод будет примерно таким (хеши у вас будут свои):

3a1c92f Добавить автора
57397ed Добавить версию

Оба коммита на месте. Заметьте: colleague_clone создаётся только после обеих отправок — иначе он получил бы только часть истории. И в colleague_clone мы не создаём коммиты, поэтому настройка автора там не нужна.