Ветки: две линии работы из одного снимка

Эксперимент не должен менять принятую версию

Вы хотите увеличить очередь, а основное описание пока должно оставаться стабильным. Можно скопировать всю папку, но потом трудно сравнить версии и вернуть исправления. Ветка даёт имя линии работы внутри одной истории. При переключении Git обновляет рабочие отслеживаемые файлы под выбранный снимок.

Ветка не является постоянной отдельной папкой. Если main и topic указывают на один коммит, их файлы пока одинаковы. После коммита в topic двигается только эта ветка. HEAD обычно указывает на выбранное имя; git branch перечисляет имена, а git switch меняет текущую ветку. Поведение switch стоит прочитать перед экспериментом с незавершёнными изменениями.

Создание ветки и переключение — разные действия: git branch topic создаёт ссылку, git switch topic выбирает её. Сочетание git switch -c topic делает оба шага. Названия feature и fix — соглашения команды. Git не знает, что «разработка» важнее «эксперимента», и не ограничивает их содержание по имени.

Чистая граница переключения

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

В наших опытах сначала создаём чистый коммит. Если нужно временно отложить работу, stash будет позже. Не применяйте switch --discard-changes ради скорости: начинающему важнее понять, какие файлы он собирается потерять. Чистое дерево не запрещает менять ветки, а облегчает наблюдение их снимков.

Создайте две линии

lab=$(mktemp -d "${TMPDIR:-/tmp}/git-04.XXXXXX")
cd "$lab"
git init -b main
git config user.name "Учебный автор"
git config user.email "learner@example.invalid"
git config commit.gpgsign false
printf 'queue=16\n' > settings.txt
git add settings.txt
git commit -m "Set base capacity"
git switch -c bigger-queue
printf 'queue=32\n' > settings.txt
git add settings.txt
git commit -m "Try larger queue"
git switch main
cat settings.txt
printf 'Run locally\n' > README.txt
git add README.txt
git commit -m "Document local launch"
git log --all --graph --oneline --decorate

В main после переключения queue равно шестнадцати. Новый README существует в main, но пока не в bigger-queue. Graph показывает общий начальный коммит и два продолжения. Звёздочки обозначают записи, линии — отношения истории; расположение текста зависит от версии Git, но общий предок и две вершины должны быть видны.

Посмотрите git show bigger-queue:settings.txt: это чтение другой ветки без переключения. Выполните git switch bigger-queue, проверьте settings и отсутствие отслеживаемого README из main. Отсутствие файла в одной ветке не означает, что Git удалил его из всей истории; снимок другой линии по-прежнему содержит его.

Когда HEAD не указывает на ветку

Старый снимок можно исследовать через git switch --detach HEAD~1. HEAD тогда указывает непосредственно на коммит: это detached HEAD. Можно читать файлы и даже создавать новые записи, но существующая ветка не будет автоматически двигаться за ними. Если решили сохранить такой эксперимент, создайте имя через git switch -c saved-experiment до ухода. Для обычной работы новичка удобнее именованная ветка с самого начала.

Проверьте точку создания ветки

У вас уже есть ветка limits с новым файлом. Вы выполняете switch -c documentation прямо из неё и удивляетесь, что документационная линия содержит лимит. Git выполнил ровно запрос: создал имя на текущей вершине, а не на «основе проекта вообще». Чтобы независимая линия началась от main, сначала выберите нужную основу либо явно укажите её при создании. Перед своей лабораторией произнесите, от какого коммита должна идти каждая ветка.

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

Самостоятельная лаборатория

Выделите 30–45 минут. Из чистого первого снимка создайте ветки documentation и limits. В одной добавьте описание запуска, в другой — файл лимитов. В main не вносите этих изменений. По очереди покажите содержимое каждой ветки через show, не меняя рабочее дерево. Затем переключитесь и проверьте прогноз.

Запишите для каждой вершины её имя, сообщение и родителя. Создайте ещё одну ветку из текущего снимка, но не делайте коммит; объясните, почему две ссылки пока показывают одинаковые файлы. Исследуйте detached HEAD и вернитесь в main без новых коммитов. Для проверки используйте git branch --show-current: в detached состоянии она не печатает имени.

Критерии готовности

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

Разбор

В main остаётся только начальный снимок; documentation содержит описание, limits — лимиты. Отдельные ветки не должны автоматически включить коммит соседней линии. Если включили, вероятно, вы создали вторую ветку уже из вершины первой. Это допустимое действие, но оно не соответствует условию общего исходного снимка.

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

В следующей главе объединим линии и разберём конфликт. Первичные источники: switch и глоссарий Git. Перед переходом нарисуйте свой graph на бумаге: это проверит понимание ссылок лучше, чем запоминание сокращений команд.