Работа с ветками

Работа с ветками#

Здесь мы познакомимся с ветками в контексте локальной работы над проектом. Все ветки будут созданы одним лицом для сопровождения нескольких направлений работ в рамках одного проекта. Последующие шаги по обмену ветками и их слияния будут рассмотрены в последующих разделах.

В этом разделе мы узнаем:

  • что такое ветка;

  • когда возникает необходимость работать с ветками;

  • о команде git branch для манипулирования с ветками в хранилище;

  • об опциях --graph, --all, --decorate, --no-decorate команды git log;

  • как создавать, просматривать и перемещаться между ветками.

У ветки есть различные определения:

  • другая версия проекта;

  • перемещаемый указатель на коммит;

  • киллер-фича Git;

  • набор коммитов, расположенных в хронологическом порядке.

Типы веток#

Необходимость в ветках появляется в следующих ситуациях:

  • работа над одним проектом параллельно нескольких разработчиков – у каждого разработчика своя версия (ветка) исходных кодов;

  • работа разработчика над несколькими задачами в рамках одного проекта – для каждой задачи своя версия (ветка) исходных кодов;

  • поддержка старой версии программы – для каждой версии программы своя версия (ветка) исходных кодов.

Ветки бывают разных типов. Рассмотрим три часто употребимых:

  • основная;

  • тематическая;

  • релизная.

Сколько бы ни было версий проекта в перспективе останется только одна, называемая основной веткой. Основную ветку еще называют стволовой или главной. Остальные версии (ветки) либо станут частью основной ветки, влившись в нее, либо остановят свое развитие и станут тупиковыми. Ситуация, когда в команде возникает разногласие по дальнейшему пути развития проекта, приводят к выделению проекта и основной ветки в отдельное хранилище. Такой процесс называется форком хранилища. Благо, лицензии открытых проектов позволяют это сделать.

Основная ветка будет стартовой для работы над проектом для любого участника проекта. От ревизий основной ветки требуется быть компилируемыми и успешно протестированными. На это есть как минимум две причины. Если разработчику попадается ревизия с нерабочей программой, то его работа встанет до момента исправления ошибки другим участником. Если ошибку в основной ветке не исправить сразу, то это повлияет на работу всей команды. Вторая причина, которая требует быть всем ревизиям основной ветки рабочей, это возможность находить момент внесения ошибки в программу. Чем больший объем кода был изменен, тем сложнее найти причину ошибки. Если ошибки ранее не было в программе, а появилась позже, то можно пройтись по коммитам и найти ревизию, в которой она впервые появилась. Этот процесс можно ускорить, если воспользоваться методом “половинного деления”. Способом можно воспользоваться только если из ревизии основной ветки программа собирается, запускается и нет других ошибок, которые бы смогли собою скрыть исходную.

Если задача объемная и не может быть решена одним коммитом и есть вероятность сломать программу, то под решение задачи создается отдельная ветка, называемая тематической. Требования к ревизиям в ней менее строгие, чем в основной. Хороший разработчик будет фиксировать только компилируемые изменения. От полного тестирования программы обычно временно отказываются, перенеся его на позднее время. Ошибки в программе стабилизируются последующими коммитами. После того, как задача решается в тематической ветке и изменения будут протестированы, их переносят в основную ветку.

Слово “release” переводится с английского как “выпускать на волю”. Релиз – это финальная ревизия программы, которая подготавливается или готова для передачи пользователю. В отличие от основной версии программы в релизной только исправляются ошибки. Изменения, добавляющие новую функцию или изменяющие структуру программы, не вносят. Для поддержки релиза создают отдельный вариант проекта в виде релизной ветки. Из релизной ветки в основную забираются изменения, связанные с исправлением ошибок, но сама ветка остается с системе для поддержки пользователей старой версии программы.

Команды#

Технически, ветка – это перемещаемый указатель на коммит. Указатель перемещается после создания коммита. В любой момент времени только одна ветка может быть текущей. Текущая – это та ветка, для которой была извлечена рабочая копия. На текущую ветку показывает указатель HEAD. В хранилище всегда присутствует как минимум одна ветка, название которой по умолчанию задавалось master, а сейчас – main.

Команда git log отрисовывает ветки в псевдографическом режиме, если ей передать опцию --graph. Отметки веток отображаются в истории коммитов, если передать опцию --decorate и скрываются по опции --no-decorate. По умолчанию опция --decorate считается заданной, поэтому отметки отображаются, если явно не попросить их скрыть опцией --no-decorate.

Чтобы увидеть содержимое всех веток, следует передать опцию --all команде git log. Сожмем описания коммитов до одной строки опцией --oneline, чтобы на экране вмещалось как можно больше коммитов. В итоге получим команду

git log --all --graph --oneline

* 57f50abdc4 (HEAD -> master, origin/master, origin/HEAD) CMake Nightly Date Stamp
*   729d904050 Merge topic 'cpack-wix'
|\  
| * d15c910a45 CPack/WIX: Remove "candle" from tool-agnostic error message
| * ac25c645a7 CPack/WIX: Improve formatting of CPACK_WIX_CUSTOM_XMLNS expansion
| * 54d09a2b3f CPack/WIX: Document WiX Toolset v3 tools
| * d2f4836f8e CPack/WIX: Prepare to provide version-specific WiX templates
| * 438809d3ba cmCPackGenerator: Add option to FindTemplate to use alternate builtin path
| * 4d661e3a92 cmMakefile: Reduce GetModulesFile caller allocations
* |   7c326643ad Merge topic 'file-RPATH-large-ELF'
|\ \  
| * | 615a1c6691 cmELF: Get correct section count for large ELF binaries
* | |   7f7105aa2c Merge branch 'release-3.29'
|\ \ \  
| * \ \   78e89edab4 (origin/release, release) Merge topic 'linker-vars-propagate-try_compile' into release-3.29
| |\ \ \  
* | \ \ \   899af83755 Merge topic 'linker-vars-propagate-try_compile'
|\ \ \ \ \  
| | |/ / /  
| |/| | |   
| * | | | 98cc86e265 try_compile(): Include languages with _ or - when passing linker vars
* | | | |   dbe05e4d7c Merge topic 'doc-tool'
|\ \ \ \ \  
| * | | | | be6763f34b Help: cmake(1) --toolchain path relative
* | | | | | 6cddfdf974 CMake Nightly Date Stamp
* | | | | | 86b55fd236 CMake Nightly Date Stamp
|/ / / / /  
* | | | |   cff8aefc6a Merge topic 'doc-CMP0118'
|\ \ \ \ \

Работа с ветками осуществляет команда git branch. Без аргументов она выводит список локальных веток в хранилище и отмечает зеленым цветом и звездочкой текущую:

bob@pc:~/projects/cmake$ git branch
* master
  release

Та же самая команда с опцией -v покажет рядом с каждой локальной веткой краткое описание последнего коммита.

bob@pc:~/projects/cmake$ git branch -v
* master  57f50abdc4 CMake Nightly Date Stamp
  release 78e89edab4 Merge topic 'linker-vars-propagate-try_compile' into release-3.29

Команда git branch <branch-name> создает новую ветку именем <branch-name>, указывающую на текущий коммит.

Чаще всего, новую ветку создают на месте текущей ветки и для этого достаточно. Вновь созданная ветка – это как почка, из которого скоро вырастит отдельный ряд коммитов. Создание новой ветки еще не означает переключение на нее. Для переключения необходимо воспользоваться командой git checkout <branch-name>. Последовательность команд создания новой ветки и переключение на нее можно заменить одной командой:

git checkout -b <branch-name>
Contents