Git branch: git branch — Creating, deleting and showing branches

Где и Как использовать Git Branch: Ветвление в Git

VPS

access_time

16 января, 2020

hourglass_empty

3мин. чтения

Git – это инструмент, используемый разработчиками для контроля версий их приложений. Он очень популярен и используется на многих серьёзных проектах, таких как GNOME и другие. Одной из важнейших функций Git является контроль над ветками разработки, что помогает улучшить процесс реализации проекта. Вот почему в этом руководстве мы покажем вам, как использовать git branch, или ветки Git. Любой проект, в том числе и проекты на основе VPS, определённо выиграет от этой замечательной функции.

Ветвление в Git помогает нам организовать несколько версий приложения. Вот почему очень важно уметь работать с этой функцией. Это руководство расширит ваши базовые знания Git.

Что Такое Git Branch

Git branching, или ветвление Git – отличный способ работать над нашим приложением и одновременно отслеживать его версии. Ветвь разработки – это бифуркация состояния кода, что создает новый путь для его эволюции. Вы можете генерировать разные ветки Git, которые будут существовать параллельно к главной ветке. Таким образом, вы сможете упорядоченно и точно включать новые функции в ваш код.

Использование Git Branches имеет несколько преимуществ. Тем не менее, мы хотим подчеркнуть следующие два:

• Можно разрабатывать новые функции нашего приложения, не мешая разработке в основной ветке.
• С помощью веток Git можно создавать разные ветки разработки, которые могут сходиться в одном и том же хранилище, например, стабильную ветвь, тестовую ветвь и нестабильную ветвь.

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

Где и как использовать Git Branch

Не забудьте получить доступ к вашему серверу по SSH перед запуском. Вот руководство по PuTTY, которое вам поможет!

Работать с Git branches довольно просто, это видно из самих команд. Но, как и в большинстве других случаев, чем больше у вас веток, тем сложнее управлять ими.

В любом проекте Git мы можем просмотреть все ветви, введя следующую команду в командной строке:

git branch

Если вы не создали ни одной Git branch, в терминале не будет выходных данных. Создать ветку действительно просто:

git branch [new_branch]

Затем нам нужно перейти в новую ветку Git, которую вы только что создали. Для этого мы запустим следующую команду:

git checkout [new_branch]

Результат сообщит нам, что мы перешли в новую ветку. Мы назвали её тестовой, так что мы увидим следующее сообщение:

Switched to branch ‘test’

Теперь в этой новой ветви разработки мы можем создать столько модификаций кода, сколько захотим, без необходимости что-либо менять в основной Git branch. Как мы видим, это поддерживает готовность программы к добавлению новых частей кода.

Если мы запустим команду для повторного вывода списка ветвей, мы увидим, что добавлена новая ветка и что мы находимся в ней.

git branch

Есть кое-что, о чём мы должны помнить, создавая новую ветку разработки. Во-первых, мы должны сделать commit в основную ветку, чтобы Git понял, что это master branch. Если мы этого не сделаем, мы получим ошибку. Итак, сначала сделайте commit, а затем создавайте ветки разработки.

Если мы хотим удалить ветку из Git, мы можем сделать это с помощью следующей команды:

git branch -d [branch_name]

Однако, мы не можем находиться в той ветке, которую хотим удалить. Сначала мы перемещаемся в главную ветку и уже оттуда удаляем только что созданную:

git checkout master

git branch -d test

Наконец, наступил момент, когда мы внесли много изменений в ветку разработки и она превратилась в стабильную, поэтому мы хотим связать её с другой веткой разработки. Для этого и существует команда слияния (merge).

Сначала найдите ветку разработки, к которой должна быть присоединена другая ветка. Например, мы хоти прикрепить тестовую ветвь к основной ветке – master branch. Для этого мы должны перейти в master branch и осуществить merge с помощью команды:

git merge [branch]

Как видите, основные функции ветки Git довольно просты. Вам просто нужно знать основы и стараться поддерживать порядок в своём проекте.

Выводы

Умение использовать Git branch, является очень важным, особенно, если вы работаете в команде. Организовывайте свой код в разных ветках Git с умом.

В этой статье мы научили вас основам работы с ветками Git.

Традиционно, мы рекомендуем прочитать официальную документацию Git касательно веток, чтобы понять, как выполняются сложные операции. Удачной разработки!

Описание метки [git-branch] — Stack Overflow на русском

`git branch` – это команда Git для управления ветками.
Используйте эту метку для обозначения всех вопросов, связанных с ветками, их созданием, структурой, управлением и удалением.

Общие сведения

git branch – это команда для управления ветками в репозитории Git.

Ветка в Git’е — это просто «скользящий» указатель на один из коммитов. Когда вы создаёте новые коммиты, указатель ветки автоматически сдвигается вперёд, к вновь созданному коммиту.

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

Использование

Чтобы создать новую ветку:

git branch <branch-name>

Просмотреть список всех веток в текущем репозитории:

git branch

То же, включая удаленные (remote) ветки:

git branch --all

Переключиться на другую ветку:

git checkout <имя-ветки>

Создать новую ветку, указывающую на текущий HEAD:

git branch <имя-новой-ветки>

То же, плюс переключиться на нее одной командой:

git checkout -b <имя-новой-ветки>

Удалить ветку:

git branch -d <имя-ветки>

Взять текущие изменения (после последнего коммита) и создать из них новую ветку:

git stash
git stash branch <имя-ветки>

Часто задаваемые вопросы

Рекомендуемые к прочтению вопросы

Документация

В русскоязычной документации используются следующие термины:

• branch — ветка
• branching — управление ветками
• local branch — локальная ветка
• remote branch — удаленная ветка

На русском языке:

1. Pro Git на русском: Ветвление в Git

На английском языке:

1. Git reference: branch

Шпаргалка по командам Git — Fandroid.

info

 Здесь набор основных команд для работы с git

Что такое Git, как установить Git и основы работы с Git смотрите здесь: Git — основы работы с системой контроля версий | Инструменты android разработчика

Создание локального репозитория

Создание репозитория в папке где выполняется команда
$ git init

Создание репозитория в указанном каталоге
$ git init <directory>

Создание репозитория Git для совместной работы

$ git init —bare —share sharedproject.git

Данная команда создает каталог с именем sharedproject.git c правами на запись в него. Подробнее тут.

Клонирование удаленного репозитория в локальный

Клонирование удаленного репозитория в локальный каталог с именем по умолчанию
$ git clone https://github.com/n0tb0dy/RemoreBranches.git

Клонирование удаленного репозитория в локальный каталог с указанным именем
$ git clone https://github.com/n0tb0dy/RemoreBranches.git LocalBranches

Клонирование локального репозитория на удаленный

Если у вас уже есть локальный репозиторий Git и вы хотите его выложить в общий доступ, то сперва вам надо создать удаленный репозиторий (например на GitHub), а затем дать команды представленные ниже, изменив соотвественно часть с названием вашего репозитория.

1. Связываем локальный репозиторий с удаленным
$ git remote add origin https://github.com/n0tb0dy/UpRemote.git

2. Верифицируем что удаленный репозиторий связан с нашим
$ git remote -v

3. Публикуем ветку master на удаленном репозитории
$ git push -u origin master

Более подробно можно почитать тут.

Задаем имя пользователя и электронную почту

Глобально для всех проектов текущего пользователья
$ git config —global user.name «John Doe»
$ git config —global user.email [email protected]

Для конкретного проекта (эти настройки переопределят глобальные)
$ git config —local user. name «John Doe»
$ git config —local user.email [email protected]

Просмотр настроек Git

Всех (глобальных, системных и локальных). Некоторые параметры могут появится в списке несколько раз, так как читаются из трех файлов настроек. Подробнее тут.
$ git config —list

Локальных для определенного проекта
$ git config —local —list

Системных
$ git config —system —list

Получение справки (помощи) по команде Git

$ git help <verb>
$ git <verb> —help

Например выведем справку по команде config (откроется браузер со справкой)
$ git help config

Настройка русских шрифтов (cp1251) в Git

Настраиваем правильное отображение файлов с русскими названиями в командах Git
$ git config —local core.quotepath false

Настраиваем кодировку Windows cp1251 для коммитов в Git
$ git config —local core.pager «iconv.exe -f cp1251 -t utf-8 | less»
$ git config —local i18n.commitEncoding utf8
$ git config —local i18n.logoutputencoding cp1251

Эти команды замечательно работают в msysgit 1.9.5. Как будет в других версия не знаю. Но надеюсь, что в более новых тоже будет работать. Более подробно про настройку русского языка в Git можно почитать тут. Так же они правильно работают  при установке Git из пакетов Cygwin, подробнее можно почитать тут.

Так же можно задать кодовую страницу для файлов проекта командой
$ git config —local i18n.filesEncoding windows-1251

ну или просто строкой в разделе [i18n]
filesEncoding = windows-1251

А вообще лучше вести проекты в кодировке UTF-8, если это возможно конечно.

Просмотр информации о состоянии файлов в Git

Основной инструмент, используемый для определения, какие файлы в каком состоянии находятся — это команда:
$ git status

И ее более краткий вывод:
$ git status -s

Просмотр разницы (что конкретно было изменено в файлах) между рабочим каталогом и индексом (staged area)
$ git diff

Просмотр разницы между последним коммитом и индексом
$ git diff —staged

Более подробно смотрим тут.

Фиксация изменений (коммит)

Если дать команду git commit без дополнительных параметров, то сперва будет вызван редактор для ввода комментария к коммиту и после сохранения комментария будет произведен коммит (фиксация изменений)
$ git commit

Чтобы включить в комментарий к коммиту информацию о том какие именно были сделаны изменения в каких файлах надо дать команду
$ git commit -v

По существу по данной команде в комментарий будет также помещена дельта diff изменений, таким образом вы сможете точно увидеть всё, что сделано.

Чтобы редактор не вызывался, можно написать комментарий прямо в командной строке в ключе -m
$ git commit -m «Commit Comment»

Автоматически добавить все измененные файлы в коммит
$ git commit -a

Удаление файлов из Git
По существу это удаление файла из отслеживаемых. Если файл уже был до этого закоммичен в Git, то из старых коммитов его по прежнему можно будет достать.

Удаление файла из отслеживаемых Git, а так же его физическое удаление из рабочего каталога
$ git rm <file_name>

Удаление проиндексированного измененного файла
$ git rm -f <file_name>

Удаление файла из индекса, но сохранение его в рабочем каталоге
$ git rm —cached <file_name>

Более подробно смотрим тут.

Переименование файла

$ git mv <old_file_name> <new_file_name>

Просмотр истории коммитов

Самый простой вариант это git log с разными ключами (смотрим help). Тут приведу просто примеры. А подробнеетут или в мануале.

Вывод простой истории коммитов
$ git log

Вывод последних n записей, в примере вывод двух последних записей
$ git log -2

Вывод дельты (diff) разницы между последними двумя изменениями (на уровне строк)
$ git log -p -2

Вывод изменений между двумя последними коммитами на уровне слов
$ git log -p -2 —word-diff

Вывод краткой статистики по 2 последним коммитам
$ git log -2 —stat

И очень полезный ключ —pretty (позволяет изменить формат вывода лога)
$ git log —pretty=oneline

$ git log —pretty=format:»%h — %an, %ar : %s»

Параметры ключа format

Параметр	Описание выводимых данных
%H	Хеш коммита
%h	Сокращённый хеш коммита
%T	Хеш дерева
%t	Сокращённый хеш дерева
%P	Хеши родительских коммитов
%p	Сокращённые хеши родительских коммитов
%an	Имя автора
%ae	Электронная почта автора
%ad	Дата автора (формат соответствует параметру --date=)
%ar	Дата автора, относительная (пр. «2 мес. назад»)
%cn	Имя коммитера
%ce	Электронная почта коммитера
%cd	Дата коммитера
%cr	Дата коммитера, относительная
%s	Комментарий

Можно так же посмотреть ASCII граф веток коммитов по ключу —graph
$ git log —pretty=format:»%h  %s» —graph

Есть параметры, ограничивающие по времени, такие как —since и —until, весьма полезны. Например, следующая команда выдаёт список коммитов, сделанных за последние две недели:
$ git log —since=2.weeks

Другой полезный фильтр это опция –S, которая как параметр принимает строку и показывает только те коммиты где эта строка была изменена, добавлена или удалена.
$ git log -S<stirng>

Пример будет искать строку MyStringForSearch
$ git log -SMyStringForSearch

Список коммитов с хэшем (короткое число)
$ git log —oneline

Отмена изменений

Изменение комментария к последнему комииту, но только в том случае, если после последнего коммита не было ни каких изменений в рабочем каталоге
$ git commit —amend

Отмена индексации файла (исключение из индекса)
$ git reset HEAD <file>

Отмена изменений файла (до внесения файла в коммит)
$ git checkout — <file>

С этой командой надо быть особо осторожным, подробнее тут.

Удаление раз и навсегда последнего коммита. Его больше ни кто ни когда не увидит. И вы в том числе :). Произойдет откат на предыдущий коммит. Все изменения которые были в последнем коммите будут утеряны. Хорошо подумайте прежде чем это делать.
$ git reset —hard HEAD~1

Работа с удаленными репозиториями

Просмотр удаленных репозиториев
$ git remote

Более подробный вывод о них
$ git remote -v

Добавление удаленного репозитория (вместо origin можно задать любое слово)
$ git remote add origin https://github. com/n0tb0dy/UpRemote.git
$ git remote add tr https://github.com/n0tb0dy/UpRemote.git

Получение изменений с удаленного репозитория под именем tr в локальную ветку tr
$ git fetch tr

Отправка данных на удаленный репозиторий. Формат git push [удал. сервер] [локальная ветка]
$ git push origin master

Инспекция удаленного репозитория git remote show [удал. сервер]
$ git remote show origin

Переименование удаленных репозиториев (по существу переименование локальной ссылки на удаленный репозиторий)
$ git remote rename <old_name> <new_name>
$ git remote rename tr newtr

Удаление удаленного репозитория 🙂 (попросту отключение от него — в примере от origin)
$ git remote rm origin

Подробней о работе с удаленными репозиториями тут.

Если у вас свой собственный репозиторий Git на сервере с само подписанным сертификатом, то перед любыми командами работы у удаленным репозиторием (clone, fetch, push, pull и т.п.), Git будет ругаться на само подписанный сертификат. Решить проблему можно изменив чуток конфиг
$ git config —local http.sslVerify false

Или же перед каждой операцией работы с удаленным репозиторием вставлять доп команду
$ git -c http.sslVerify=false push origin newbranch

А вообще настройка своего сервера Git это отдельная тема. Частично рассмотрена тут.

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

Посмотреть локальные ветки
$ git branch

Посмотреть последний коммит на каждой из локальных веток
$ git branch –v

Чтобы посмотреть все существующие локальные и удаленные ветки можно дать команду
$ git branch –a

Посмотреть последние коммиты на всех ветках (локальных и удаленных)
$ git branch –a -v

Посмотреть отслеживаемые ветки
$ git branch –vv

Сделать ветку локальную ветку serverfix отслеживаемой
$ git branch -u origin/serverfix

Создать ветку
$ git branch <имя_ветки>

Создать ветку на определенном коммите
$git branch new_branch 5a0eb04

Переименовать ветку
git branch -m <oldname> <newname>

Переименовать текущую ветку
git branch -m <newname>

Переключится на ветку
$ git checkout <имя_ветки>

Создать ветку и сразу же переключится на нее
$ git checkout -b <имя_ветки>

Слияние веток (в примере находимся на ветке master и сливаем с ней ветку hotfix)
$ git checkout master
$ git merge hotfix

Удалить ветку
$ git branch -d <имя_ветки>

Удалить ветку serverfix на удаленном сервере
$ git push origin —delete serverfix

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

Посмотреть все (перечисляет в алфавитном порядке, а не по времени их создания)
$ git tag

Посмотреть попадающие под маску
$ git tag -l ‘v1. 4.2.*’

Создать метку на текущем коммите (ключ -а) с меточным сообщением (ключ -m)
$ git tag -a v1.4 -m ‘my version 1.4’

Если ключ -m не указывать то откроется окно редактора чтобы ввести сообщение

Создание легковесной метки на текущем коммите
$ git tag <имя_метки>
$ git tag MyTAG

Посмотреть метки вместе с комментариями к коммитам, а так же с именами поставивших метки
$ git show <tag>
$ git show MyTAG

Так же можно выставлять метки и на уже пройденные коммиты. Подробнее о метках тут.

Задание псевдонимов для команд Git

Псевдонимы можно создать как в конфигурационных файлах Git, так и в конфиге Bash, но важно понимать в чем разница.

Задание псевдонимов в конфигах Git

$ git config —global alias.co checkout
$ git config —global alias.br branch
$ git config —global alias.ci commit
$ git config —global alias.st status

Теперь достаточно давать команды
$ git co
$ git br
$ git ci
$ git st

То есть через задание алиасов в конфиге Git мы не избавляемся от необходимости писать команду git, но все же это короче.

Кроме того в эти команды так же можно подставлять параметры
$ git config —global alias.unstage ‘reset HEAD —‘

Это делает эквивалентными следующие две команды:
$ git unstage fileA
$ git reset HEAD fileA

Более подробно по алисы в конфигах Git читаем тут.

Об алиасах заданных через Bash читаем тут.

Сравнение файла в разных коммитах

$ git diff ffd6b37 c258082 —cc test.txt

С помощью внешних утилит ExamDiffPro и P4Merge

Смотрим изменения файла test.txt между двумя коммитами
$ git difftool 9491cc8 02c1df6 —tool=edp —cc test.txt
$ git difftool 9491cc8 02c1df6 —tool=p4m —cc test. txt

Слияние (merge)

Отмена слияния
$ git merge —abort

Разное

Просмотр истории перемещения указателя HEAD
$ git reflog

Источник

создание ветвей (branch) – Zencoder

Продолжаю совместно с вами постепенно изучать магию Git\GitHub.

Слово магия здесь применено не случайно — не иначе, как магией возможности Git\GitHub не назовешь. По крайней мере, я впечатлен этими возможностями. Другое дело, что процесс изучения Git у меня лично идет как-то тяжеловато. Ну, это не страшно — главное, не останавливаться!

В этом разделе я попытаюсь осветить для себя (и возможно, для вас, уважаемый читатель) вопрос создания ветвей (branches) в Git, перемещение между ветвями (branches), слияние (merge) ветвей. Этот вопрос очень подробно и хорошо описан на странице официальной документации — “Git Branching — Basic Branching and Merging”. Здесь я попробую самостоятельно описать данный вопрос.

Инициализация Git-репозитория

Создаю тестовую директорию , в которой будут производиться эксперименты по созданию ветвей в Git. Внутри этой директории создаю два файла — индексный файл и файл таблиц стилей. А затем инициализирую Git-репозиторий, добавляю созданные файлы под версионный контроль Git:

$ mkdir git_branches
$ cd git_branches
$ touch index.html
$ touch style.css

$ git init
Initialized empty Git repository in /home/username/Desktop/projects/git_branches/.git/

$ git add .
$ git commit -m 'first launch'
[master (root-commit) eeb12ca] first launch
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 index.html
 create mode 100644 style.css

$ git status
On branch master
nothing to commit, working directory clean

Обратите на строку в выводе команды . Это не пустой набор служебной информации — здесь говориться о том, что в ветви нечего фиксировать и рабочая директория чистая.

Итак, мы уже кое-что узнали. А именно — при инициализации Git-репозитория была автоматически создана ветвь (branch) по имени . И на данный момент мы находимся в этой ветви.

Конечно, на самом деле это пока мало о чем говорит, так как не с чем сравнивать. Поэтому давайте я немного отредактирую оба файла и , проиндексирую\зафиксирую их.

В браузере примерный вид странички будет выглядеть таким образом:

Git — создание новой ветви (branch)

В системе Git (как уже упоминалось ранее) имеется механизм ветвления (branches). Попробую на словах объяснить, что он из себя представляет.

Допустим, в моем текущем проекте, у которого имеются два файла, нужно внести кардинальные изменения. Причем, изменения такого рода, что они могут нарушить работу уже существующего проекта. Чтобы обезопасить себя (подстраховать), создаю точную копию существующего проекта и перехожу в нее для дальнейшей работы.

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

$ git checkout -b second
  Switched to a new branch 'second'

Строка

1

Switched to a new branch 'second'

услужливо информирует, что меня автоматически “перебросило” во вновь ветвь . Можно проверить себя, набрав в консоли:

$ git status
  On branch second
  nothing to commit, working directory clean

Строка говорит сама за себя.

Отлично! Теперь давайте я внесу некоторые изменения в файлы и и мы вместе посмотрим на результат в окне браузера. Изменения будут касаться добавления блока-обертки, еще нескольких параграфов и другой легкой стилизации.

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

$ git commit -a -m 'Modify Brach Second'
  [second e4b5d5d] Modify Brach Second
  2 files changed, 24 insertions(+), 14 deletions(-)
  rewrite index.html (72%)

Смотрим, что у нас получилось в окне браузера — то, что и ожидалось:

Git — переключение между ветвями (branches)

А теперь настал самый интересный момент. Как вы помните, мы сейчас находимся в ветви . Давайте я переключусь в ветвь и мы снова посмотрим в окно браузера:

$ git checkout master
  Switched to branch 'master'

Оп! Мы видим старую картину — Git “запечатлел” тот момент, когда мы совершили переход из ветви в ветвь . Другими словами, мы вернулись в последнее зафиксированное состояние ветви :

$ git log --pretty=oneline
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

Если я снова вернусь в ветку и запущу команду просмотра логов Git, то коммитов окажется больше:

$ git checkout second
  Switched to branch 'second'

  $ git log --pretty=oneline
  e4b5d5df7a4b9a3ee56a7298726bdab4691a5a58 Modify Brach Second
  b7105dab98d2f3798b5456c35695a4e906a80e92 Master Branch
  eeb12ca79f224af90cd31cf470143998a6312249 first launch

Мне кажется, уже сейчас должно быть понятно, что такое ветви (branches) в Git и для чего они предназначены. На самом деле это действительно очень просто.

Git — слияние ветвей (branches)

В предыдущем шаге я создал ветвь , в которую внес “рискованные” изменения, чтобы проверить, “оправдают” ли они себя. Изменениями я доволен и хотел бы добавить их в первоначальную ветку , чтобы потом продолжить развитие проекта уже с этого места.

Фактически, я хочу сделать слияние двух веток — и . Это сделать очень просто — для этого я перехожу в ветку . То есть, я должен находиться в той ветке, в которую я вношу изменения из другой ветки. А затем произвожу само слияние:

$ git checkout master
  Switched to branch 'master'

  $ git merge second
  Updating b7105da..e4b5d5d
  Fast-forward
   index.html | 8 ++++++--
   style.css  | 6 ++++++
   2 files changed, 12 insertions(+), 2 deletions(-)

Команда слияния проста — я просто указываю имя той ветки (branch), которую хочу слить (merge) с текущей, в которой я нахожусь на данный момент.

При слиянии ветвей зачастую может возникнуть ситуация, когда происходит конфликт между двумя ветвями. Рассмотрение вопроса решения конфликтов при слиянии не рассматривается мною, так как на данный момент еще не освоил этот вопрос до конца.

Давайте снова “заглянем” в окно браузера — что он нам интересного покажет?

Показал он то, что и следовало показать — результат объединения двух ветвей и .

Git — графическое представление ветвей (branches)

Система Git имеет в своем составе возможность графического представления ветвления в репозитории. Причем, такое представление можно сделать даже в консоли, с помощью псевдографики.

Это можно сделать, набрав в консоли команду:

$ git log --oneline --abbrev-commit --all --graph

На Stack Overflow я нашел примеры красивых изображений консоли с псевдографическим выводом команды :

На самом деле вариантов использования команды с ключом бесчисленное множество. Поэтому нужно выбирать именно то, что нужно и нравиться именно вам.

Помимо псевдографики, ветви в Git можно визуализировать с помощью настоящего графического приложения. Под Mac OS X и Linux имеется достаточно большое количество таких приложений. Например, под Mac OS X это GitX, под Linux — Gitk или Gitg:

Git — удаление ветви (branch)

В разделе слияния ветвей в Git я научился процессу объединения двух ветвей в одну. Такой процесс в Git имеет название (слияние). Теперь ветвь имеет в себе все, что есть и в ветви . Поэтому ветвь можно удалить.

Выполняется это командой:

$ git branch -d second
  Deleted branch second (was 19a8328).

Посмотрим на вывод команды :

$ git hist
  * fa8b252 2014-09-03 | Last Commit in Master Branch (HEAD, master)
  *   22a9487 2014-09-03 | Merge Second Branch in Master Branch (origin/master, origin/HEAD)
  |\
  | * 19a8328 2014-09-03 | Six Commit in Second Branch
  | * e273e6c 2014-09-03 | Fifth Commit in Second Branch
  | * 8e2fe40 2014-09-03 | Fourth Commit in Second Branch
  | * 3290a23 2014-09-03 | Third Commit in Second Branch
  | * 0584a1c 2014-09-03 | Second Commit in Second Branch
  | * 38fab33 2014-09-03 | First Commit in Second Branch
  * | 8543256 2014-09-03 | Seventh Commit in Master Branch
  * | e852688 2014-09-03 | Six Commit in Master Branch
  * | d6ccde3 2014-09-03 | Fifth Commit in Master Branch
  * | c0d8e2f 2014-09-03 | Fourth Commit in Master Branch
  * | 7d2377a 2014-09-03 | Third Commit in Master Branch
  |/
  * b3e0f1f 2014-09-03 | Second Commit in Master Branch
  * be4e1f0 2014-09-03 | First Commit in Master Branch
  * ac2961a 2014-09-03 | Added git_branches
  * db9e01b 2014-09-03 | Initial commit

У меня осталась одна ветвь — .

gitbranch

Branching стратегии в Git — bool.dev

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

Branching & merging анти-паттерны:

• Merge Paranoia – когда девелоперы боятся мержить код, из-за последствий которые могут возникнуть (мерж конфликты) поэтому накапливается негативный эффект отложенной интеграции.
• Merge Mania – когда разработчики больше времени тратят на объединение изменений, чем на разработку.
• Big Bang Merge – В ветки не подмерживаются изменения, как следствие в конце происходит один гигантский мерж в конце.
• Never-Ending Merge – непрерывный мержинг, так как всегда есть что мержить.
• Wrong Way Merge – объединение более поздней бранчи с более ранней версией.
• Branch Mania – создание большого количества веток без видимой на то причины.
• Cascading Branches – создание веток без мержа их в mainline в конце разработки.
• Mysterious Branches – создание ветки без причины.
• Temporary Branches – создание ветки с изменяющейся причиной ее существования: ветка становится «permanent temporary workspac’ом».
• Volatile Branches – старт ветки в нестабильном состоянии или перенос нестабильных изменений в другие ветки.
• Development Freeze – остановка всей разработки для создания веток, объединения или создания релизов.
• Berlin Wall – использование веток для разделения людей в команде, вместо разделения на таски/фичи, над которыми они работают.

Git Flow (Feature Based Development)

Схематично Git Flow можно описать так:

Git Flow — одна из первых крупных стратегий ветвления, которая завоевала популярность. Git Flow описывает несколько веток для разработки, релизов и взаимодействия между ними.

Главные ветки:

По сути модель перекочевала с других существующих моделей. Репозиторий содержит 2 главные ветки:

master — дефолтная ветка знакомая каждому, кто работал с гитом. Параллельно в этой концепции существует еще одна ветка develop.

Master в этой концепции всегда содержит стабильный код, а develop бранча существует для того чтобы от нее бранчеваться и сливать туда уже готовые фичи для последующего мержа в master. Как следствие master выступает релизной (иногда) и stable бранчей в этой концепции.

В Git Flow мы можем использовать следующие типы веток:

• Feature branches
• Release branches
• Hotfix branches

Feature branches

1. Могут бранчеватся от develop
2. Должны вмержится в develop
3. Naming convention: любые названия кроме master, develop, release-*, или hotfix-*

Release branches

1. Могут бранчеватся от develop
2. Должны вмержится в develop и master
3. Naming convention: release-*

Помните, до того как вмержить код в релиз ветку, необходимо добавить ей тег с версией релиза (например «0.9 hotfix»)

Hotfix branches

1. Могут бранчеватся от master
2. Должны вмержится в develop и master
3. Naming convention: hotfix-*

Плюсы и минусы Git Flow:

Плюсы:

1. Git Flow используется многими распределенными командами, в тч и open source команды, которые имеют разные уровни квалификации. Сопровождающие проекта могут проводить код ревью и утверждать каждую строку кода в релизы.
2. Git Flow хорошо подходит для «традиционной модели релизов», где релизы делаются раз в месяц или раз в пару недель.
3. Git Flow также хорошо работает при работе с установленным продуктом или несколькими версиями в производстве.

Минусы:

1. Git Flow может замедлять работу, когда приходится ревьювить большие пулл реквесты, когда вы пытаетесь выполнить итерацию быстро.
2. Релизы сложно делать чаще, чем раз в неделю.
3. Большие функции могут потратить дни на мерж и резолв конфликтов и форсировать несколько циклов тестирования.
4. История проекта в гите имеет кучу merge commits и затрудняет просмотр реальной работы.
5. Может быть проблематичным в CI/CD сценариях.

GitHub Flow

Он выглядит почти так же как и Git Flow, но фиксированная ветка всего одна — master; всё остальное принадлежит тематическим ветвям. Тематические ветви, в свою очередь, создаются в форках — клонированных копиях репозитория. То есть центральный репозиторий тематических веток не содержит. В том числе и после слияния, так как метки веток при этом снимаются и их головы становятся анонимными.

GitLab Flow

Как и в GitHub Flow, фиксированная ветка всего одна — master, всё остальное принадлежит тематическим ветвям. Однако, если в том случае релизы размещались в коммитах master-a, то здесь для каждого релиза создаётся своя, отдельная ветка. Причём никакого мержа этих веток с parent’ом не производится. Если ветка отбранчевалась, значит она будет жить своей жизнью, получая исправления ошибок в виде отдельных коммитов (возможно, портированных из head/master с учётом накопившейся разницы в функционале между ветками).

Environment branches в GitLab flow

Release branches в GitLab flow

Trunk Based Development (TBD)

На официальном сайте эта концепция отображается такой схемой:

Лично для меня, когда я стал изучать эту концепцию эта схема показалась совсем не понятной и не раскрывала суть этой концепции. Давайте же разберемся подробнее простым языком  в чем суть Trunk Based Development.

Что такое Trunk Based Development (TBD) ?

TBD прозволяет бизнесу тестировать бизнес-гипотезы «As soon as possible». Тк позволяет очень быстрыми итерациями релизить код на продакшн.

В Trunk Based Development можно выделить следующие особенности:

1. Ветки живут максимум 2 дня
2. Feature Flags
3. Branch By Abstraction
4. Continuous Code Review (это концепция из экстримального программирования которая говорит о том, что код который попадает на ревью, должен ревьювится как можно быстрее)
5. master всегда готов к деплою, даже если в нем есть не готовые фичи

Feature Flags

Feature Flags — это концепция в которой у нас есть файл конфигурации, где прописано какая из фич включена/выключена и в коде существует проверка которая позволяет пропускать какую-то логику, например

if (configurationManager.getParameter("someFuncIsEnabled")) {
    // do some stuff
} else {
    // do default logic
}

Приемущества использования Feature Flags

• Можем мержить и деплоить код, который еще не готов
• A/B тесты
• Шаринг кода между недоработанными фичами, за счет мержа всего кода в master

Branch By Abstraction

Trunk Based Development предлагает вместо создание ветки для фич, создавать ветку на изменение одной абстракции.

Представим, что у нас есть объект Car, у которой есть абстракция “передние колоса” и “задние колеса”, которые мы хотим заменить на другой тип колес. В случае с feature branch, мы бы разработали реализацию нового типа колес в 1 бранче, с Branch By Abstraction все немного сложнее.

Рассмотрим рисунок и шаги которые нам помогут раскрыть порядок действий при TBD подходе

1. Создаем ветку, оборачиваем переднее колесо в абстракцию, отправляем Pull Request, мержим
2. Создаем ветку, описываем новый тип передних колес и добавляем feature flag переключения типов колес, отправляем Pull Request, мержим
3. Создаем ветку, оборачиваем заднее колесо в абстракцию, отправляем Pull Request, мержим
4. Создаем ветку, описываем новый тип задних колес и добавляем feature flag переключения типов колес, отправляем Pull Request, мержим
5. Включили в проде новый тип колес, убедились, что все ок
6. Удаляем старые колеса отдельными Pull Request`ами

И что нам это дало?

• Частые интеграции! Мы уже пришли ранее к тому что нужно часто интегрировать маленькие кусочки кода(CI), теперь при таком подходе можно делать «микрокусочки».
• Постепенное изменение/рефакторинг кода. Вместо переделки всего разом, меняем постепенно, шарим изменения до того как закончим большую задачу.
• Возможность переключения на другие фичи. В случае, если нужно переключиться на другую задачу, мы можем смежить последнее изменения и вернуться к доработке потом.

Continuous Code Review

Ревьювим чужие pull requests, сразу после того как отправили свой. Из-за этого что пулл реквесты маленькие(изменение одной абстракции), их ревью занимает не более чем пару минут, Если от создания пулл реквеста до аппрува прошло 10 минут, то это приемлемый результат, если больше 1 часа, то это считается очень плохим результатом.

Что нам дает концепт Continuous Code Review

• Шаринг знаний. Все понимают как меняется сервис, переиспользуют код, подсказывают друг-другу лучшие практики.
• Снижение тех долга за счет того что мы все рефракторим на ходу.
• Ускорение деплоя. (пулл реквест весит не пару дней, а несколько минут и может сразу отправляться в прод)

Плюсы и минусы Trunk Based Development

Плюсы:

• Позволяет быстро выполнять итерации и при этом поддерживать качество.
• Хорошо работает в сценариях CI/CD.
• Можно релизиться как можно чаще, в том числе несколько раз в день.

Минусы:

• Лучше всего работает когда у вас команда состоит с опытных разработчиков.
• Наполовину готовые функции, неправильно реализованными feature flag’ами, может вызвать проблемы.
• Изначально может вызвать некоторые проблемы, если нет хорошего покрытия тестами или уверенности в стабильности системы.

Git: Branches — Kagarlickij Dmitriy

Branch, или ветка одна из самых удобных и, соответственно, востребованных фич.

С помощью ветвления можно не только реализовать классическое деление на dev, staging и production, но и организовать командную работу.

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

Мы хотим внести изменения в данное решение, для этого мы создадим новую ветку командой git checkout -b dev и проверим результат командой git branch –list :

 

Обратите внимание, звёздочкой отмечена ветка в которой мы сейчас находимся, переключится на другую ветку можно командой git checkout :

 

Итак, вернёмся обратно в ветку dev и добавим к проекту ещё один файл:

 

Посмотрим содержимое dev ветки командой ls -la , переключимся в ветку master и убедимся что в ней файла devFile1.txt нету:

 

Синхронизируем нашу локальную ветку с “основным репозиторием” используя знакомую команду git push (комментарий по синтаксису – git push  <REMOTENAME> <LOCALBRANCHNAME>:<REMOTEBRANCHNAME>):

 

Проверим результат:

 

Предположим, наш эксперимент в ветке dev закончился удачно и теперь нам нужно распространить изменения на production который у нас в master ветке (в мастер, фактически, добавится файл devFile1.txt).

Для этого инициируем процесс, который называется branch merge.

Переключимся в ветку master и выполним git merge –no-ff dev (–no-ff необходимо для генерации merge commit, dev – указываем содержимое какой ветки будет сливать с master):

 

Убедимся что файл, который раньше был только в dev, сейчас уже и в master:

 

Разумеется, если файл уже был в master, затем был дополнен (изменён) в dev, затем dev был смерджен в master, то в master будет обновлённая версия файла.

 

Кроме того, можно посмотреть наглядную картинку в SourceTree:

 

Рассмотрим чуть более сложный, но более распространённый сценарий, когда наш проект передаётся после окончания разработки на тестирование (staging) и только потом в production (master).

Создадим ветку stg, добавим файл в ветку dev, сделаем merge dev в stg, проведём тестирование, и если все ок, то сделаем merge stg в master:

git checkout -b stg
git checkout dev
echo «devFile4 content» > devFile4.txt
git add devFile4.txt
git commit —message «Adding new file to dev branch»
git checkout stg
git merge —no-ff dev
git checkout master
git merge —no-ff stg
git push —all origin




git checkout -b stg git checkout dev echo «devFile4 content» > devFile4.txt git add devFile4.txt git commit —message «Adding new file to dev branch» git checkout stg git merge —no-ff dev git checkout master git merge —no-ff stg git push —all origin

 

Надеюсь из этого материала понятно, насколько ответственно нужно подходить к процессу merge веток.

К счастью используя BitBucket у администратора есть возможность настроить права доступа к веткам:

 

Оглавление цикла статей по Git.

Надеюсь озвученная информация будет полезной, а если нужна будет помощь — используйте форму на главной странице моего сайта.

Related

Git — документация git-branch

-d
— удалить

Удалить ветку. Ветвь должна быть полностью объединена в ее
восходящая ветвь или HEAD , если восходящий поток не был установлен с
- трек или - установка восходящего потока на .

-D

Ярлык для --delete --force .

— создать-reflog

Создайте рефлог ветки. Это активирует запись
все изменения, внесенные в ссылку ветки, что позволяет использовать дату
основанные на выражениях sha1, например «<имя-ветки> @ {вчера}». Обратите внимание, что в репозиториях, отличных от голых, рефлоги обычно
по умолчанию включен параметром конфигурации core.logAllRefUpdates .
Отрицательная форма --no-create-reflog заменяет только предыдущую.
--create-reflog , но в настоящее время не отменяет настройку
core.logAllRefUpdates .

-ф
— сила

Сбросить <имя-ветки> на <начальную точку>, даже если <имя-ветки> существует
уже. Без -f , git branch отказывается изменять существующую ветку.В сочетании с -d (или --delete ) разрешить удаление
филиал независимо от его объединенного статуса. В комбинации с
-m (или --move ), разрешить переименование ветки, даже если новое
имя ветки уже существует, то же самое относится к -c (или --copy ).

-м
— переехать

Переместить / переименовать ветку и соответствующий журнал ссылок.

-М

Ярлык для --move --force .

-c
— копия

Скопируйте ветку и соответствующий рефлог.

-C

Ярлык для --copy --force .

— цвет [= ]

Цветные ветви для выделения текущих, локальных и
ветки удаленного отслеживания.
Значение должно быть всегда (по умолчанию), никогда или автоматически.

— бесцветный

Отключить цвета ветвей, даже если файл конфигурации
по умолчанию — цветной вывод.То же, что и --color = never .

-i
— игнорирование

Ветви сортировки и фильтрации нечувствительны к регистру.

—колонка [= <параметры>]
— без столбца

Показать список ветвей в столбцах. См. Переменную конфигурации
column.branch для синтаксиса опции. - столбец и - без столбца
без опций эквивалентны всегда и никогда соответственно.

Эта опция применима только в режиме без подробностей.

-r
— пульты

Перечислить или удалить (если используется с -d) ветки удаленного отслеживания.
Комбинируйте с --list , чтобы сопоставить необязательный шаблон (ы).

-а
— все

Перечислите ветки удаленного отслеживания и локальные филиалы.
Комбинируйте с --list для сопоставления необязательных шаблонов.

-л
— список

Список ветвей.С дополнительным ... , например мерзавец
branch --list 'maint- *' , перечислить только те ветви, которые соответствуют
узор (ы).

—просмотр

Вывести имя текущей ветки. В отдельном состоянии HEAD,
ничего не печатается.

-v
-vv
— вербальный

В режиме списка
показать sha1 и зафиксировать строку темы для каждой главы вместе с
отношение к восходящей ветке (если есть).Если дано дважды, выведите
путь к связанному рабочему дереву (если есть) и имя вышестоящего
ветку (см. также git remote show ). Обратите внимание, что
HEAD текущего рабочего дерева не будет печатать свой путь (он всегда будет
быть вашим текущим каталогом).

-q
— тихий

Будьте тише при создании или удалении ветки, подавляя
сообщения об ошибках.

—abbrev =

В подробном листинге, показывающем имя объекта фиксации,
показать самый короткий префикс, который должен быть не менее шестнадцатеричных цифр
long, однозначно относящийся к объекту.Значение по умолчанию — 7 и может быть изменено ядром . Abbrev
вариант конфигурации.

— без сокращения

Показывать полные sha1 в выходном списке, а не сокращать их.

-т
— трек

При создании новой ветки настройте ветку . <имя> .remote и
branch. .merge записей конфигурации, чтобы отметить
ветвь начальной точки как «восходящая» от новой ветки.Этот
конфигурация скажет git показать взаимосвязь между
две ветки в git status и git branch -v . Более того,
он направляет git pull без аргументов для извлечения из
вверх по течению, когда новая ветка будет проверена.

Это поведение используется по умолчанию, если начальной точкой является ветвь удаленного отслеживания.
Установите для переменной конфигурации branch.autoSetupMerge значение false , если вы
хотите, чтобы git switch , git checkout и git branch всегда вели себя так, как будто --no-track
были даны.Всегда устанавливайте , если вы хотите, чтобы такое поведение было
начальная точка — это локальная ветвь или ветвь удаленного отслеживания.

— без колеи

Не настраивайте «восходящую» конфигурацию, даже если
Переменная конфигурации branch.autoSetupMerge имеет значение true.

— установка восходящего потока

Поскольку у этой опции запутанный синтаксис, она больше не поддерживается.
Вместо этого используйте --track или --set-upstream-to .

-u <восходящий поток>
—set-upstream-to =

Настройте информацию отслеживания , чтобы
считается восходящей ветвью .Если нет
указан, то по умолчанию используется текущая ветвь.

— восходящий поток

Удалите информацию о восходящем потоке для . Если нет ветки
указано, что по умолчанию используется текущая ветка.

— редактировать-описание

Откройте редактор и отредактируйте текст, чтобы объяснить, что это за ветка.
for, для использования другими различными командами (например, format-patch ,
запрос-вытягивание и слияние (если включено)).Многострочные объяснения
может быть использовано.

— содержит []

Перечислить только ветки, содержащие указанную фиксацию (HEAD
если не указано). Подразумевает - список .

—no-contains []

Показывать только те ветки, которые не содержат указанную фиксацию.
(ГОЛОВА, если не указано). Подразумевает - список .

— объединено []

Показывать только ветки, подсказки которых доступны из
указанный коммит (HEAD, если не указан).Подразумевает - список .

— без объединения []

Перечислять только ветки, подсказки которых недоступны из
указанный коммит (HEAD, если не указан). Подразумевает - список .

<название компании>

Имя ветви, которую нужно создать или удалить.
Новое имя ветки должно пройти все проверки, определенные
git-check-ref-format [1]. Некоторые из этих проверок
может ограничивать символы, разрешенные в имени ветки.

<начальная-точка>

Новый заголовок ветки будет указывать на эту фиксацию.Это может быть
задано как имя ветки, идентификатор фиксации или тег. Если это
опция опущена, вместо нее будет использоваться текущий HEAD.

<старая ветвь>

Имя существующей ветки, которую нужно переименовать.

<новое отделение>

Новое имя существующей ветки. Те же ограничения, что и для
применить.

—sort = <ключ>

Сортировка по заданному ключу. Префикс - для сортировки по убыванию
порядок значения.Вы можете использовать опцию —sort =
несколько раз, и в этом случае последний ключ становится первичным
ключ. Поддерживаемые ключи такие же, как в git.
для каждой ссылки . По умолчанию для порядка сортировки используется значение, настроенное для
branch.sort Переменная , если существует, или для сортировки на основе
полное имя (включая префикс refs / ... ). В этом списке
сначала отсоединенный HEAD (если есть), затем локальные ветки и
наконец, ветки удаленного отслеживания. См. Git-config [1].

—points-at <объект>

Только перечислить ветви данного объекта.

—format <формат>

Строка, которая интерполирует % (имя поля) из отображаемой ссылки ветки.
и объект, на который он указывает. Формат такой же, как
это git-for-each-ref [1].

Git — документация git-branch

Если задано --list , или если нет аргументов, не являющихся опциями, существующие
перечислены филиалы; текущая ветка будет выделена значком
звездочка. Опция -r вызывает список ветвей удаленного отслеживания,
а опция -a показывает как локальные, так и удаленные ветви.Если <шаблон>
задан, он используется как подстановочный знак оболочки, чтобы ограничить вывод
соответствующие ветви. Если дано несколько шаблонов, будет показана ветвь, если
он соответствует любому из шаблонов. Обратите внимание, что при предоставлении
, вы должны использовать --list ; в противном случае команда интерпретируется
как создание филиала.

С - содержит , показывает только те ветки, которые содержат названный коммит.
(другими словами, ветви, вершина которых фиксируется, являются потомками
названный коммит).С - слился , только ветви слились в названный
фиксации (т.е. ветки, чьи вершины фиксируются, достижимы из именованных
commit) будут перечислены. С - без объединения — только ветки, не объединенные в
будет перечислен названный коммит. Если аргумент отсутствует
по умолчанию HEAD (т.е. вершина текущей ветви).

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

Обратите внимание, что это создаст новую ветку, но не переключит
рабочее дерево к нему; используйте «git checkout «, чтобы переключиться на
новая ветка.

Когда локальная ветвь запускается из ветки удаленного отслеживания, Git настраивает
ветка (в частности ветка . <имя> .remote и ветка . <имя> .merge
записи конфигурации), так что git pull будет соответствующим образом слиться из
ветвь удаленного отслеживания. Это поведение можно изменить с помощью глобального
филиал.Флаг конфигурации autoSetupMerge . Эта настройка может быть
переопределено с помощью параметров --track и --no-track , и
позже изменился с использованием git branch --set-upstream-to .

С опцией -m или -M <старая ветвь> будет переименована в <новая ветка>.
Если имел соответствующий журнал ссылок, он переименовывается в соответствии с
, и создается запись reflog, чтобы запомнить ветку
переименование. Если существует, необходимо использовать -M для принудительного переименования
произойдет.

С опцией -d или -D будет удалено <название ветки> . Ты можешь
укажите более одной ветви для удаления. Если ветка в настоящее время
Если есть рефлог, рефлог также будет удален.

Используйте -r вместе с -d для удаления ветвей удаленного отслеживания. Обратите внимание, что это
имеет смысл удалять ветки удаленного отслеживания, только если они больше не существуют
в удаленном репозитории или если git fetch был настроен так, чтобы не получать
их снова.См. Также подкоманду prune команды git-remote [1] для
способ очистить все устаревшие ветки удаленного отслеживания.

Git — git-for-each-ref Документация

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

Для всех объектов можно использовать следующие названия:

refname

Имя ссылки (часть после $ GIT_DIR /).
Для недвусмысленного краткого имени ссылки добавьте : short .Параметр core.warnAmbiguousRefs используется для выбора строгого
режим сокращения. Если lstrip = ( rstrip = ) добавлено, полосы
компоненты пути, разделенные косой чертой, начиная с передней (задней) ссылки
(например, % (refname: lstrip = 2) превращает refs / tags / foo в foo и
% (refname: rstrip = 2) превращает refs / tags / foo в refs ).
Если — отрицательное число, удалите столько компонентов пути, сколько
необходимо с указанного конца оставить - компонентов пути
(е.грамм. % (refname: lstrip = -2) ходов
ссылок / тегов / foo в тегов / foo и % (refname: rstrip = -1)
превращает refs / tags / foo в refs ). Когда реф не имеет
достаточно компонентов, результат становится пустой строкой, если
удаление с положительным , или оно становится полным ссылочным именем, если
зачистка с минусом . Это тоже не ошибка.

strip может использоваться как синоним lstrip .

тип объекта

Тип объекта ( blob , tree , commit , tag ).

размер объекта

Размер объекта (такой же, как git cat-file -s reports).
Добавьте : disk , чтобы получить размер в байтах, который занимает объект
диск. См. Примечание о размерах на диске в разделе CAVEATS ниже.

имя объекта

Имя объекта (также известное как SHA-1).
Для однозначного сокращения имени объекта добавьте : короткий .
Для сокращения имени объекта желаемой длины добавьте
: short = , где минимальная длина MINIMUM_ABBREV.В
длина может быть превышена для обеспечения уникальных имен объектов.

deltabase

Расширяется до имени объекта дельта-базы для
данный объект, если он хранится как дельта. В противном случае это
расширяется до имени нулевого объекта (все нули).

восходящий поток

Имя локальной ссылки, которая может считаться восходящей.
из отображаемого исх. Уважает : short , : lstrip и
: rstrip так же, как refname выше.Кроме того
уважает : трек , чтобы показать «[впереди N, позади M]» и
: укоротите , чтобы показать краткую версию: «>» (впереди), «<" (сзади), «<>» (впереди и сзади) или «=» (синхронно). : трек
также выводит «[ушел]» всякий раз, когда неизвестная исходная ссылка
столкнулся. Приложение : трек, без скобок для отображения трекинга
информация без скобок (т.е. «впереди N, позади M»).

Для любой ветви удаленного отслеживания % (восходящий поток) , % (восходящий поток: удаленное имя)
и % (upstream: remoteref) относятся к имени удаленного и
имя отслеживаемого удаленного реф. соответственно.Другими словами,
ветка удаленного отслеживания может быть обновлена ​​явно и индивидуально с помощью
используя refspec % (upstream: remoteref):% (upstream) для выборки из
% (вверх по течению: удаленное имя) .

Не действует, если ссылка не имеет связанной с отслеживанием информации.
с этим. Все опции, кроме nobracket , являются взаимоисключающими,
но при совместном использовании выбирается последний вариант.

нажмите

Имя местной ссылки, которая представляет номер @ {push} .
место для отображаемого исх.Респект : короткий , : lstrip ,
: rstrip , : дорожка , : trackhort , : удаленное имя и : remoteref
варианты, как это делает восходящий поток . Если нет @ {push} , выдает пустую строку
ref настроен.

ГОЛОВА

* , если HEAD совпадает с текущим ref (проверенная ветка), »
иначе.

цвет

Изменить цвет вывода.За ним следует : , где цвет
имена описаны в разделе «Значения» в «ФАЙЛЕ КОНФИГУРАЦИИ»
раздел git-config [1]. Например,
% (цвет: жирный красный) .

выровнять

Выровнять содержимое по левому, среднему или правому краю между
% (выровнять:…) и% (конец). За «align:» следует
ширина = <ширина> и позиция = <позиция> в любом порядке
через запятую, где <позиция> либо слева,
справа или посередине, по умолчанию слева и <ширина> — это общее
длина содержимого с выравниванием.Для краткости
Префиксы «width =» и / или «position =» могут быть опущены, а
Вместо этого используются и . Например,
% (выровнять: <ширина>, <позиция>) . Если длина содержимого больше
чем ширина, то выравнивание не выполняется. Если используется с
--quote все, что находится между% (выровнять:…) и% (конец), является
цитируется, но если они вложены, то выполняется только самый верхний уровень
цитирование.

, если

Используется как% (если)…% (затем)…% (конец) или
% (если)…% (затем)…% (иначе)…% (конец).Если есть атом с
значение или строковый литерал после% (если), то все после
печатается% (then), иначе, если используется атом% (else), то
все после% (else) напечатано. Мы игнорируем пространство, когда
оценка строки до% (затем), это полезно, когда мы
используйте атом% (HEAD), который выводит либо «*», либо «», и мы
хотите применить , если условие только на HEAD ref.
Добавьте «: equals = » или «: notequals = » для сравнения
значение между атомами% (если:…) и% (затем) с
данная строка.

symref

Ссылка, на которую ссылается данный символический номер. Если не
символическая ссылка, ничего не печатается. Уважает : короткий ,
: lstrip и : параметры rstrip так же, как refname
над.

рабочий путь

Абсолютный путь к рабочему дереву, в котором проверяется ссылка
out, если он разрегистрирован в любом связанном рабочем дереве. Пустой строкой
иначе.

В дополнение к вышесказанному, для объектов фиксации и тегов заголовок
имена полей ( дерево , родительский , объект , тип и тег ) могут
использоваться для указания значения в поле заголовка.Поля tree и parent также можно использовать с модификатором : short и
: short = точно так же, как имя объекта .

Для объектов фиксации и тегов специальные creatordate и creator
поля будут соответствовать соответствующей дате или кортежу имя-электронная почта-дата
из полей коммиттера или tagger в зависимости от типа объекта.
Они предназначены для работы с аннотированными и облегченными тегами.

Поля, значение которых имеет кортеж имя-адрес электронной почты-даты ( автор ,
committer и tagger ) могут быть дополнены суффиксом name , email ,
и дата для извлечения названного компонента. Для полей электронной почты ( authoremail ,
committeremail и taggeremail ), : trim можно добавить, чтобы получить электронное письмо
без угловых скобок и : localpart , чтобы получить часть перед символом @
из обрезанного электронного письма.

Сообщение в фиксации или объекте тега - , содержимое , из которого
содержимое: может использоваться для извлечения различных частей из:

содержимое: размер

Размер сообщения фиксации или тега в байтах.

содержание: тема

Первый абзац сообщения, обычно
одна строка, принимается как "тема" коммита или
сообщение тега.
Вместо содержания : тема , поле тема также можно использовать для
получить такие же результаты.: sanitize можно добавить к subject для
строка темы подходит для имени файла.

содержание: тело

Остаток фиксации или последующее сообщение тега
"предмет".

содержание: подпись

Необязательная подпись GPG тега.

содержание: строки = N

Первые N строк сообщения.

Кроме того, трейлеры, интерпретируемые git-interp-trailers [1]
получаются как трейлеров [: options] (или с использованием исторического псевдонима
содержание: прицепы [: опции] ).Допустимые значения [: option] см. В прицепах .
раздел git-log [1].

Для сортировки поля с числовыми значениями сортируются в числовом порядке
( объектов размером , authordate , committerdate , creatordate , taggerdate ).
Все остальные поля используются для сортировки в порядке значений байтов.

Также есть возможность сортировки по версиям, это можно сделать с помощью
имя поля версия: refname или его псевдоним v: refname .

В любом случае имя поля, которое относится к полю, не применимому к
объект, на который ссылается ссылка, не вызывает ошибки. Это
вместо этого возвращает пустую строку.

В качестве особого случая для полей типа даты вы можете указать формат для
дату, добавив : , за которым следует имя формата даты (см.
значения параметра --date для git-rev-list [1] принимает).

Некоторые атомы, такие как% (align) и% (if), всегда требуют совпадения% (end).
Мы называем их «открывающимися атомами» и иногда обозначаем их как% ($ open).

Когда действует цитирование, специфичное для языка сценариев, все
между открывающим атомом верхнего уровня и его совпадающим% (концом) оценивается
в соответствии с семантикой открывающего атома и только его результатом
с верхнего уровня цитируется.

Git - документация git-branch

-d
- удалить

Удалить ветку. Ветвь должна быть полностью объединена в ее
восходящая ветвь или HEAD , если восходящий поток не был установлен с
- трек или - установить восходящий .

-D

Ярлык для --delete --force .

-л
- создать-reflog

Создайте рефлог ветки. Это активирует запись
все изменения, внесенные в ссылку ветки, что позволяет использовать дату
основанные на выражениях sha1, например "<имя-ветки> @ {вчера}".
Обратите внимание, что в репозиториях, отличных от голых, рефлоги обычно
по умолчанию включен параметром конфигурации core.logallrefupdates .
Отрицательная форма --no-create-reflog заменяет только предыдущую.
--create-reflog , но в настоящее время не отменяет настройку
ядро.logallrefupdates .

-ф
- сила

Сбросить <имя-ветки> на <начальную точку>, если <имя-ветки> существует
уже. Без -f git branch отказывается изменять существующую ветку.
В сочетании с -d (или --delete ) разрешить удаление
филиал независимо от его объединенного статуса. В комбинации с
-m (или --move ), разрешить переименование ветки, даже если новое
название ветки уже существует.

-м
- переехать

Переместить / переименовать ветку и соответствующий журнал ссылок.

-М

Ярлык для --move --force .

- цвет [= ]

Цветные ветви для выделения текущих, локальных и
ветки удаленного отслеживания.
Значение должно быть всегда (по умолчанию), никогда или автоматически.

- бесцветный

Отключить цвета ветвей, даже если файл конфигурации
по умолчанию - цветной вывод.То же, что и --color = never .

-i
- игнорирование

Ветви сортировки и фильтрации нечувствительны к регистру.

--колонка [= <параметры>]
- без столбца

Показать список ветвей в столбцах. См. Переменную конфигурации
column.branch для синтаксиса опции. - столбец и - без столбца
без опций эквивалентны всегда и никогда соответственно.

Эта опция применима только в режиме без подробностей.

-r
- пульты

Перечислить или удалить (если используется с -d) ветки удаленного отслеживания.

-а
- все

Перечислите ветки удаленного отслеживания и локальные филиалы.

- список

Активировать режим списка. git branch попытается создать ветку,
используйте git branch --list для перечисления соответствующих веток.

-v
-vv
- вербальный

В режиме списка
показать sha1 и зафиксировать строку темы для каждой главы вместе с
отношение к восходящей ветке (если есть). Если дано дважды, выведите
также имя восходящей ветки (см. также git remote
показать ).

-q
- тихий

Будьте тише при создании или удалении ветки, подавляя
сообщения об ошибках.

--abbrev = <длина>

Измените минимальную длину отображения sha1 в листинге вывода.Значение по умолчанию - 7 и может быть изменено ядром . Abbrev
вариант конфигурации.

- без сокращения

Показывать полные sha1 в выходном списке, а не сокращать их.

-т
- трек

При создании новой ветки настройте ветку . <имя> .remote и
branch. .merge записей конфигурации, чтобы отметить
ветвь начальной точки как "восходящая" от новой ветки.Этот
конфигурация скажет git показать взаимосвязь между
две ветки в git status и git branch -v . Более того,
он направляет git pull без аргументов для извлечения из
вверх по течению, когда новая ветка будет проверена.

Это поведение используется по умолчанию, если начальной точкой является ветвь удаленного отслеживания.
Установите для переменной конфигурации branch.autoSetupMerge значение false , если вы
хотите, чтобы git checkout и git branch всегда вели себя так, как будто --no-track
были даны.Всегда устанавливайте , если вы хотите, чтобы такое поведение было
начальная точка - это локальная ветвь или ветвь удаленного отслеживания.

- без колеи

Не настраивайте "восходящую" конфигурацию, даже если
Переменная конфигурации branch.autoSetupMerge имеет значение true.

- установка восходящего потока

Если указанная ветка еще не существует или если --force
Учитывая, действует точно так же, как - track . В противном случае настраивает конфигурацию
как - track будет при создании ветки, за исключением того, где
точки ветвления не изменены.

-u <восходящий поток>
--set-upstream-to =

Настройте информацию отслеживания , чтобы
считается восходящей ветвью . Если нет
указан, то по умолчанию используется текущая ветвь.

- восходящий поток

Удалите информацию о восходящем потоке для . Если нет ветки
указано, что по умолчанию используется текущая ветка.

- редактировать-описание

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

- содержит []

Перечислить только ветки, содержащие указанную фиксацию (HEAD
если не указано). Подразумевает - список .

- объединено []

Показывать только ветки, подсказки которых доступны из
указанный коммит (HEAD, если не указан). Подразумевает - список .

- без объединения []

Перечислять только ветки, подсказки которых недоступны из
указанный коммит (HEAD, если не указан). Подразумевает - список .

<название компании>

Имя ветви, которую нужно создать или удалить.
Новое имя ветки должно пройти все проверки, определенные
git-check-ref-format [1]. Некоторые из этих проверок
может ограничивать символы, разрешенные в имени ветки.

<начальная-точка>

Новый заголовок ветки будет указывать на эту фиксацию.Это может быть
задано как имя ветки, идентификатор фиксации или тег. Если это
опция опущена, вместо нее будет использоваться текущий HEAD.

<старая ветвь>

Имя существующей ветки, которую нужно переименовать.

<новое отделение>

Новое имя существующей ветки. Те же ограничения, что и для
применить.

--sort = <ключ>

Сортировка по заданному ключу. Префикс - для сортировки по убыванию
порядок значения.Вы можете использовать опцию --sort =
несколько раз, и в этом случае последний ключ становится первичным
ключ. Поддерживаемые ключи такие же, как в git.
для каждой ссылки . По умолчанию используется порядок сортировки на основе
полное имя (включая префикс refs / ... ). В этом списке
сначала отсоединенный HEAD (если есть), затем локальные ветки и
наконец, ветки удаленного отслеживания.

--points-at <объект>

Только перечислить ветви данного объекта.

Git Checkout | Учебник Atlassian Git

На этой странице рассматривается команда git checkout . В нем будут рассмотрены примеры использования и крайние случаи. В терминах Git «оформление заказа» - это акт переключения между различными версиями целевой сущности. Команда git checkout работает с тремя отдельными объектами: файлами, коммитами и ветвями. В дополнение к определению «checkout» фраза «check out» обычно используется для обозначения действия по выполнению команды git checkout .В теме «Отмена изменений» мы увидели, как git checkout можно использовать для просмотра старых коммитов. В центре внимания большей части этого документа будут операции оформления заказа в филиалах.

Извлечение веток аналогично извлечению старых коммитов и файлов в том смысле, что рабочий каталог обновляется в соответствии с выбранной веткой / ревизией; однако новые изменения сохраняются в истории проекта, то есть это не операция только для чтения.

Проверка филиалов


Команда git checkout позволяет перемещаться между ветвями, созданными git branch .Проверка ветки обновляет файлы в рабочем каталоге, чтобы они соответствовали версии, хранящейся в этой ветке, и сообщает Git о необходимости записи всех новых коммитов в этой ветке. Думайте об этом как о способе выбора, над каким направлением развития вы работаете.

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

Команду git checkout иногда можно спутать с git clone . Разница между этими двумя командами заключается в том, что clone работает для извлечения кода из удаленного репозитория, в качестве альтернативы checkout работает для переключения между версиями кода, уже существующими в локальной системе.

Использование: Существующие филиалы


Предполагая, что репо, в котором вы работаете, содержит уже существующие ветки, вы можете переключаться между этими ветвями с помощью git checkout .Чтобы узнать, какие ветки доступны и каково текущее имя ветки, выполните git branch .

  $> мастер ветки git another_branch feature_inprogress_branch $> git checkout feature_inprogress_branch  

В приведенном выше примере показано, как просмотреть список доступных ветвей, выполнив команду git branch , и переключиться на указанную ветку, в данном случае feature_inprogress_branch .

Новые отделения


Git checkout работает рука об руку с веткой git .Команду git branch можно использовать для создания новой ветки. Если вы хотите запустить новую функцию, вы создаете новую ветку от master , используя git branch new_branch . После создания вы можете использовать git checkout new_branch , чтобы переключиться на эту ветку. Кроме того, команда git checkout принимает аргумент -b , который действует как удобный метод, который создаст новую ветку и немедленно переключится на нее. Вы можете работать с несколькими функциями в одном репозитории, переключаясь между ними с помощью git checkout .

  git checkout -b  

В приведенном выше примере одновременно создается и проверяется . Параметр -b - это вспомогательный флаг, который сообщает Git запускать git branch перед запуском git checkout .

  git checkout -b  

По умолчанию git checkout -b будет основывать new-branch на текущем HEAD . Необязательный дополнительный параметр ветки можно передать в git checkout .В приведенном выше примере передается , которое затем основывает new-branch на existing-branch вместо текущего HEAD .

Коммутация филиалов


Переключение ветвей - несложная операция. Выполнение следующего направит HEAD на вершину .

  git checkout  

Git отслеживает историю операций оформления заказа в журнале регистрации. Вы можете выполнить git reflog , чтобы просмотреть историю.

Git Checkout для удаленного филиала


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

  git fetch - все  

В современных версиях Git вы можете проверить удаленную ветку как локальную ветку.

  git checkout  

Более старые версии Git требуют создания новой ветки на основе удаленного .

  git checkout origin /  

Кроме того, вы можете проверить новую локальную ветвь и сбросить ее до последней фиксации удаленной ветки.

  git checkout -b git reset --hard origin /  

ГОЛОВКИ ОТДЕЛЬНЫЕ


Теперь, когда мы рассмотрели три основных варианта использования git checkout в ветвях, важно обсудить состояние «detached HEAD» .Помните, что HEAD - это способ Git ссылаться на текущий снимок. Внутренне команда git checkout просто обновляет HEAD , чтобы указать либо на указанную ветвь, либо на фиксацию. Когда он указывает на ветку, Git не жалуется, но когда вы проверяете фиксацию, он переключается в состояние «отключенная HEAD» .

Это предупреждение о том, что все, что вы делаете, «отделено» от остальной части разработки вашего проекта. Если бы вы начали разработку функции в отдельном состоянии HEAD , не было бы ветви, позволяющей вам вернуться к ней.Когда вы неизбежно проверяете другую ветку (например, чтобы объединить свою функцию), не будет возможности сослаться на вашу функцию:

Дело в том, что ваша разработка всегда должна происходить в ветке, а не в отдельной HEAD . Это гарантирует, что у вас всегда будет ссылка на ваши новые коммиты. Однако, если вы просто смотрите на старую фиксацию, не имеет особого значения, находитесь вы в отсоединенном состоянии HEAD или нет.

Сводка


Эта страница посвящена использованию команды git checkout при смене ветвей.Таким образом, git checkout при использовании в ветвях изменяет цель HEAD ref. Его можно использовать для создания веток, переключения ветвей и проверки удаленных веток. Команда git checkout - важный инструмент для стандартной работы Git. Это аналог git merge . Команды git checkout и git merge являются важными инструментами для включения рабочих процессов git .

git branch - Создание, удаление и отображение веток

Команда «ветвь» помогает создавать, удалять и перечислять ветки.

Это незаменимая команда, когда дело доходит до управления любым аспектом ваших веток - независимо от того, в вашем локальном репозитории или на ваших пультах.

Важные опции

-v -a

Предоставляет дополнительную информацию о всех ваших филиалах. По умолчанию в списке ваших веток будут отображаться только имен локальных веток .

• Добавление флага «-a» гарантирует, что удаленные ветки также включены в список.
• Добавление флага «-v» сделает команду более «подробной» и включит хеши SHA-1, а также темы последних коммитов в ваших ветках.

- без объединения

Возвращает все ветки, у которых , а не , были объединены в вашу текущую ветвь HEAD. Это поможет вам понять, какие изменения еще не были интегрированы в ваш текущий рабочий контекст. Обратите внимание, что вы также можете запросить все ветки, которые уже имеют , которые были объединены в вашем текущем HEAD, используя вместо этого параметр «--merged».

-d

<филиал>

Удаляет указанную ветку.

• Если указанная ветвь еще не была полностью объединена, вам нужно будет использовать флаг с заглавной буквы «-D». Однако будьте осторожны: удаление веток, содержащих несвязанные данные, не должно производиться легкомысленно.
• Если вы хотите удалить удаленную ветку, добавьте флаг «-r» в дополнение к «-d».

<новый филиал>

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

Шпаргалка по Git

Не нужно запоминать все эти команды и параметры: получите нашу популярную «Шпаргалку по Git» - бесплатно!

Примеры использования

Вы можете перечислить все ветки (как локальные, так и удаленные), включая хэши SHA-1 и коммиты, на которые в настоящее время указывают эти ветки:

  $ git branch -a -v
  * master 609d1ee Новые иконки для страницы «Команды»
    feature / login 82a0f21 Добавить тестовые примеры
  

Используя опцию «--no-merged», вы можете узнать, в каком из ваших локальных филиалов , а не , интегрировано в текущую ветку HEAD, но:

  $ git branch --no-merged
  особенность / учетные записи
  

Если вы хотите очистить и удалить ветки, которые уже были интегрированы, вы можете использовать «--merged», чтобы найти эти ветки, а затем удалить их с помощью «-d»:

  $ git branch --merged
  функция / логин
  функция / информационный бюллетень
$ git branch -d функция / функция входа / информационный бюллетень
  

Чтобы создать новую ветку, просто укажите имя - и, возможно, начальную точку, если вы не хотите, чтобы она запускалась в текущем состоянии ветки HEAD:

  $ функция ветки git / выход из системы b84f02e
  

Подсказка

Использование перетаскивания для управления ветвями

Клиент Tower Git позволяет создавать, объединять, перемещать, перемещать и извлекать ваши ветки - просто с помощью перетаскивания!

Попробуйте бесплатно в течение 30 дней и узнайте, почему 100 000 разработчиков по всему миру используют Tower , чтобы работать с Git более продуктивно!

Узнать больше

Успешная модель ветвления Git »nvie.com

Записка отражения

(5 марта 2020 г.)

Эта модель была задумана в 2010 году, сейчас более 10 лет назад, и не очень
спустя долгое время после появления самого Git. За эти 10 лет git-flow (
модель ветвления, изложенная в этой статье) стала чрезвычайно популярной во многих
команда разработчиков программного обеспечения до такой степени, что люди начали относиться к нему как
своего рода стандарт - но, к сожалению, также как догма или панацея.

За эти 10 лет Git захватил мир штурмом, и
самый популярный тип программного обеспечения, разрабатываемого с помощью Git, сдвигается
больше в отношении веб-приложений - по крайней мере, в моем пузыре фильтров.Веб-приложения обычно
непрерывно доставляется, без отката, и вам не нужно поддерживать
несколько версий программного обеспечения, работающих в «дикой природе».

Это не тот класс программного обеспечения, о котором я имел в виду, когда писал блог.
пост 10 лет назад. Если ваша команда занимается непрерывной поставкой программного обеспечения,
Я бы предложил использовать гораздо более простой рабочий процесс (например, GitHub
поток) вместо того, чтобы пытаться
включите git-flow в свою команду.

Если, однако, вы создаете программное обеспечение с явной версией, или если
вам нужно поддерживать несколько версий вашего программного обеспечения в дикой природе, тогда
git-flow может по-прежнему подходить для вашей команды так же хорошо, как и для людей
за последние 10 лет.В таком случае, пожалуйста, продолжайте читать.

В заключение, всегда помните, что панацеи не существует. Считайте свой собственный
контекст. Не ненавидь. Решайте сами.

В этом посте я представляю модель разработки, которую я представил для некоторых из
мои проекты (как рабочие, так и частные) около года назад,
быть очень успешным. Я уже давно хотел об этом написать,
но до сих пор у меня никогда не было времени на это основательно. Я не буду
говорить о любых деталях проекта, просто о стратегии ветвления
и управление выпусками.

Почему мерзавец? ¶

За подробное обсуждение плюсов и минусов Git по сравнению с централизованным
системы управления исходным кодом, см.
Интернет. Есть много пламени
там идут войны. Как разработчик, я предпочитаю Git всем остальным инструментам.
сегодня. Git действительно изменил представление разработчиков о слиянии и ветвлении.
Из классического мира CVS / Subversion, из которого я пришел, слияние / ветвление всегда
считается немного пугающим («остерегайтесь конфликтов слияния, они вас кусают!») и
то, что вы делаете только время от времени.

Но с Git эти действия чрезвычайно дешевы и просты, и они
действительно считается одной из основных частей вашего ежедневного рабочего процесса . Например,
в книгах CVS / Subversion, ветвление и слияние
впервые обсуждается в следующих главах (для опытных пользователей), а в
каждый
Git
книга, она уже рассмотрена в главе
3 (основы).

Вследствие своей простоты и повторяемости, ветвление и слияние
больше не чего бояться. Инструменты контроля версий должны
помочь в разветвлении / слиянии больше всего на свете.

Довольно об инструментах, давайте перейдем к модели разработки. Модель, которая
Я собираюсь представить здесь, по сути, не более чем набор процедур, которые
каждый член команды должен следовать, чтобы прийти к управляемому ПО
процесс разработки.

Децентрализованный, но централизованный ¶

Настройка репозитория, которую мы используем и которая хорошо работает с этой моделью ветвления,
это то, что с центральным репо «истины». Обратите внимание, что это репо только считается
быть центральным (поскольку Git - это DVCS, не существует такой вещи, как центральный
репо на техническом уровне).Мы будем называть это репо origin , поскольку это
имя знакомо всем пользователям Git.

Каждый разработчик тянет и подталкивает к origin. Но помимо централизованного
двухтактные отношения, каждый разработчик также может получать изменения от других партнеров
формировать подкоманды. Например, это может быть полезно для совместной работы с двумя
или несколько разработчиков над большой новой функцией, прежде чем отправлять незавершенную работу в
происхождение преждевременно. На рисунке выше представлены подкоманды Алисы и Боба,
Алиса и Дэвид, Клер и Дэвид.

Технически это означает не что иное, как то, что Алиса определила удаленный Git,
с именем bob , указывающим на репозиторий Боба, и наоборот.

Основные филиалы ¶

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

Ветвь master в origin должна быть знакома каждому пользователю Git. Параллельный
в ветку master существует еще одна ветка под названием develop .

Мы считаем origin / master основной веткой, где исходный код
HEAD всегда отражает состояние готово к производству .

Мы считаем origin / develop основной веткой, где исходный код
HEAD всегда отражает состояние с последними внесенными изменениями в разработку
для следующего выпуска. Некоторые назвали бы это «интеграционной ветвью». Это
откуда строятся любые автоматические ночные сборки.

Когда исходный код в ветке develop достигает стабильной точки и
готов к выпуску, все изменения должны быть объединены обратно в master
каким-то образом, а затем помечен номером версии.Как это делается подробно будет
будет обсуждаться далее.

Следовательно, каждый раз, когда изменения объединяются обратно в master , это новый
выпуск продукции по определению . Мы очень строги в этом вопросе, чтобы
теоретически мы могли бы использовать скрипт-перехватчик Git для автоматической сборки и
развертывать наше программное обеспечение на наших производственных серверах каждый раз при фиксации
мастер .

Вспомогательные филиалы 45

Рядом с основными ветвями master и development , наша модель разработки использует
множество вспомогательных веток для помощи в параллельной разработке между командами
участников, упростите отслеживание функций, подготовьтесь к выпуску продукции и
помочь в быстром устранении проблем с живым производством.В отличие от основных веток,
у этих веток всегда есть ограниченное время жизни, так как они будут удалены
в итоге.

Мы можем использовать следующие типы веток:

• Функциональные ветви
• Отводы выпуска
• Ветви исправлений

Каждая из этих ветвей имеет определенную цель и подчиняется строгим правилам, как
какие ветви могут быть их исходной ветвью и какие ветви должны быть
их цели слияния. Мы пройдемся по ним через минуту.

Эти отрасли ни в коем случае не являются «особенными» с технической точки зрения. В
Типы веток классифицируются по тому, как мы используем их . Они, конечно, старые добрые
Ветки Git.

Разделы функций ¶

Может ответвляться от:

разработка

Должен снова объединиться с:

разработка

Соглашение об именах филиалов:

все, кроме master , develop , release- * или hotfix- *

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

Функциональные ветки обычно существуют только в репозиториях разработчиков, а не в origin .

Создание ветки функции ¶

При начале работы над новой функцией, отделитесь от ветки develop .

 $ git checkout -b myfeature develop
Перешел на новую ветку "myfeature"
 

Включение готовой функции при разработке ¶

Готовые функции могут быть объединены в ветку develop , чтобы обязательно добавить
их к предстоящему выпуску:

 $ git checkout develop
Перешли в ветку "разработка"
$ git merge --no-ff myfeature
Обновление ea1b82a..05e9557
(Сводка изменений)
$ git branch -d myfeature
Удалена ветка myfeature (было 05e9557).
$ git push origin develop
 

Флаг --no-ff заставляет слияние всегда создавать новый объект фиксации, даже
если бы слияние могло быть выполнено с перемоткой вперед. Это позволяет избежать потери
информация об историческом существовании функциональной ветки и групп
вместе все коммиты, которые вместе добавили функцию. Сравнить:

В последнем случае невозможно увидеть из истории Git, какая из
зафиксировать объекты вместе реализовали функцию - вам придется вручную
прочтите все сообщения журнала.Отмена всей функции (т. Е. Группы коммитов),
- настоящая головная боль в последней ситуации, тогда как это легко сделать, если
- использовался флаг no-ff .

Да, он создаст еще несколько (пустых) объектов фиксации, но выигрыш намного
больше, чем стоимость.

Разделы выпуска ¶

Может ответвляться от:

разработка

Должен снова объединиться с:

разработка и мастер

Соглашение об именах филиалов:

релиз- *

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

Ключевой момент для отделения новой ветки выпуска от develop - это когда
develop (почти) отражает желаемое состояние нового релиза. По крайней мере все
функции, предназначенные для будущего выпуска, должны быть объединены с
разрабатывает на данный момент.Все функции, предназначенные для будущих выпусков, могут
нет - они должны подождать, пока ветвь выпуска не будет разветвлена.

Именно в начале ветки выпуска следующий выпуск получает
присвоили номер версии - не ранее. До этого момента развивали
ветка отражала изменения для «следующего выпуска», но неясно,
«Следующий выпуск» в конечном итоге станет 0.3 или 1.0, пока ветвь выпуска не будет
началось. Это решение принимается в начале ветки выпуска и
выполняется в соответствии с правилами проекта по неровности номеров версий.

Создание ветки выпуска ¶

Ветки выпуска создаются из ветки develop . Например, скажите
версия 1.1.5 является текущим производственным выпуском, и у нас есть большой выпуск
приближается. Состояние разработки готово к «следующему выпуску», и у нас есть
решил, что это будет версия 1.2 (а не 1.1.6 или 2.0). Итак, мы
ответвите и дайте ветке выпуска имя, отражающее новую версию
номер:

 $ git checkout -b релиз-1.2 развить
Перешел на новую ветку "релиз-1.2"
$ ./bump-version.sh 1.2
Файлы успешно изменены, версия повышена до 1.2.
$ git commit -a -m "Увеличен номер версии до 1.2"
[release-1.2 74d9424] Увеличен номер версии до 1.2.
1 файл изменен, 1 вставка (+), 1 удаление (-)
 

После создания новой ветки и переключения на нее мы увеличиваем номер версии.
Здесь bump-version.sh - это вымышленный сценарий оболочки, который изменяет некоторые файлы в
рабочая копия для отражения новой версии.(Это, конечно, может быть руководство
change - дело в том, что некоторые файлы меняются.) Затем, измененная версия
номер совершается.

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

Завершение ветки выпуска ¶

Когда состояние ветки релиза готово стать настоящим релизом, некоторые
действия должны быть выполнены. Сначала ветка выпуска объединяется с
master (поскольку каждая фиксация на master является новым выпуском по определению ,
Помните). Затем эта фиксация на master должна быть помечена для облегчения будущего.
ссылка на эту историческую версию. Наконец, изменения, внесенные в релиз
ветку необходимо объединить обратно в , разработать , чтобы в будущих выпусках также
содержат эти исправления ошибок.

Первые два шага в Git:

 $ мастер проверки $ git
Перешел на ветку master
$ git merge --no-ff релиз-1.2
Слияние выполнено рекурсивно.
(Сводка изменений)
$ git tag -a 1.2
 

Релиз готов и помечен для использования в будущем.

Изменить: Вы также можете использовать флаги -s или -u для подписи
ваш тег криптографически.

Чтобы сохранить изменения, сделанные в ветке выпуска, нам нужно объединить их обратно
в , тем не менее, разработайте .В Git:

 $ git checkout develop
Перешли в ветку "разработка"
$ git merge --no-ff релиз-1.2
Слияние выполнено рекурсивно.
(Сводка изменений)
 

Этот шаг вполне может привести к конфликту слияния (возможно, даже, поскольку у нас
изменил номер версии). Если да, исправьте это и сделайте коммит.

Теперь мы действительно закончили, и ветвь выпуска может быть удалена, поскольку мы не
нужно больше:

 $ git branch -d релиз-1.2
Удалена ветка release-1.2 (была ff452fe).
 

Ветви исправлений ¶

Может ответвляться от:

главный

Должен снова объединиться с:

разработка и мастер

Соглашение об именах филиалов:

исправление - *

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

Суть в том, что работа членов команды (на ветке разработка ) может
продолжайте, пока другой человек готовит быстрое производственное исправление.

Создание ветки исправлений ¶

Ветви

Hotfix создаются из основной ветки .Например, скажем, версия
1.2 - текущий производственный выпуск, работающий вживую и вызывающий проблемы из-за
серьезная ошибка. Но изменения на , развитие пока нестабильны. Затем мы можем разойтись
ветку с исправлениями и приступайте к устранению проблемы:

 $ git checkout -b hotfix-1.2.1 master
Перешел на новую ветку "хотфикс-1.2.1"
$ ./bump-version.sh 1.2.1
Файлы успешно изменены, версия повышена до 1.2.1.
$ git commit -a -m "Номер версии увеличен до 1.2.1"
[hotfix-1.2.1 41e61bb] Номер версии увеличен до 1.2.1
1 файл изменен, 1 вставка (+), 1 удаление (-)
 

Не забудьте увеличить номер версии после разветвления!

Затем исправьте ошибку и зафиксируйте исправление одним или несколькими отдельными коммитами.

 $ git commit -m "Устранена серьезная производственная проблема"
[hotfix-1.2.1 abbe5d6] Устранена серьезная производственная проблема.
Изменено 5 файлов, 32 вставки (+), 17 удалений (-)
 

Завершение ветки исправлений ¶

Когда закончите, исправление необходимо снова объединить с master , но также необходимо
быть объединенным обратно в , разработать , чтобы гарантировать, что исправление ошибки
также включен в следующий выпуск.Это полностью похоже на то, как выпускают
ветки закончены.

Сначала обновите master и отметьте выпуск.

 $ мастер проверки $ git
Перешел на ветку master
$ git merge --no-ff hotfix-1.2.1
Слияние выполнено рекурсивно.
(Сводка изменений)
$ git tag -a 1.2.1
 

Изменить: Вы также можете использовать флаги -s или -u для подписи
ваш тег криптографически.

Затем включите исправление в develop также:

 $ git checkout develop
Перешли в ветку "разработка"
$ git merge --no-ff hotfix-1.2.1
Слияние выполнено рекурсивно.
(Сводка изменений)
 

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

Наконец, удалите временную ветку:

 $ git branch -d исправление-1.2.1
Удалено исправление ветки 1.2.1 (было abbe5d6).
 

Сводка ¶

Хотя в этой разветвленной модели нет ничего шокирующего нового, «большой
картинка », с которой начался этот пост, оказалась чрезвычайно
полезно в наших проектах.

No related posts.