Дата и время публикации:
Дата и время модификации:
Назначение и использование
1. Назначение
Отличительной чертой Git стало использование ветвление рабочего процесса, позволящее не только наслаивать сделанные изменения в виде обновлений, именуемых "Commit...", но и создавать отдельные ветви для каждой новой разрабатываемой и отлаживаемой функции, устраняемой ошибки, а также в целях реорганизации и/или улучшения исходного кода проекта.
Давайте рассмотрим простой пример и создадим в репозитарии несколько веточек, как показано на схеме ветвления 1.1
Схема ветвления 1.1
┌──────────┐ ┌──────────┐
┌──>│ br00A │ ┌────────>│ *br02A │
│ └────────┐─┘ │ └──────────┘
│ │ ┌──────────┐ ║
x └────────>│ br01A │ ║
│ └──────────┘ ║
│ "br02A" U "Master/Main"
╔═════════════╗ ║
║ Master/Main ║<══════════════════════════════╝
╚═════════════╝
На которой показано поэтапное выполнение стратегии управления репозитарием от создание ветвей, начальной инициилизации ветви "Master/Main" до операции слияния, которая производится с последней созданной ветвью "br02A" на финальной части стратегии управления репозиторием и применяемая во время внесения изменений в исходный код репозитария repo, пример которой приведен на схеме ветвления 1.1
2. Использование
2.1 Получение списка ветвей репозитария
Команда git branch используется для отображение всех ветвей в репозитории, как показано в дампе 2.1
Дамп 2.1.1
$ git branch master br00A br01A * br02A
В котором показан вывод всех существующих ветвей в репозитарии. При этом звездочкой отмечена текущая активная "br02A" .
2.2 Создание начальной ветви
Первой веткой в списке дампа 2.1.1 указана "Master/Main", которая должна всегда инициализироваться в момент создания репозитария и реализуемой алгоритмом, раскрываемый ниже.
В командной оболочке или интерфейсе командной строки установить имя пользователя, в данном случае для Developer, как показано в дампе 2.2.1
Дамп 2.2.1
git config --global user.name "Developer"
Добавить адрес электронной почты, в данном случае для developer@example.org, как показано в дампе 2.2.2
Дамп 2.2.2
git config --global user.email "developer@example.org"
Проверить конфигурацию, как показано в дампе 2.2.3
Дамп 2.2.3
git config --global --list
Выполнить инициализацию ветви "Master/Main" репозитария, как показано в дампе 2.2.4
Дамп 2.2.4
git init
Добавляем адрес удаленного репозитария repo в gitlab-scm.remote.net, как показно в дапме 2.2.5
Дамп 2.2.5
git remote add origin git@gitlab-scm.remote.net:repo.git
И проверяем информацию о назначенном удаленном адресе, как показано в дампе 2.2.6
Дамп 2.2.6
$ git remote -v origin git@gitlab-scm.remote.net:repo.git (fetch) origin git@gitlab-scm.remote.net:repo.git (push)
На финальной стадии инициализации добаляем файл Readme.md и обновляем все привязанные объекты из локального в удаленный репозитарий git push origin, как показано в дамп 2.2.7
Дамп 2.2.7
echo "**Repo syncro date:** $(date +%Y.%m.%d' '%H:%M)" > Readme.md git add . git commit -m "initial commit" git push origin master
Как показано в дампе 2.2.7, последней командой git push origin производится сохранение всех сделанных изменений, в т.ч. и в организации хранения исходного кода в репозитарии.
2.3 Добавление новой ветви
В любом исходном коде рано или поздно требуется сделать какие-то улучшения, связанные с добавлением новых функций и/или устранения критических ошибок безопасности. Поэтому, перед каждым внесением значимых изменений в исходный код, будет разумно создавать отдельные ветви "br00A", "br01A", "br02A", которые показаны в схеме ветвления репозитария 1.1 . При этом создание только что перечисленных ветвей должно производится после инициализации начальной ветви "Master/Main" во избежание ошибки типа "src refspec master does not match any", как показано в дампе 2.3.1
Дамп 2.3.1
$ git push -u origin br00A error: src refspec master does not match any. error: failed to push some refs to 'git@gitlab-scm.remote.net:repo.git'
Соответственно, как это было ранее показано в п.2.2 настоящей статьи, после создания начальной ветви "Master/Main" можно создать последующие ветвь "br00A", так же как и "br01A", "br02A", как показано в дампе 2.3.2
Дамп 2.3.2
$ git checkout -b br00A Переключено на новую ветку "br00A"
Получаем текущее состояние ветви, на которую автоматически был переключен репозитарий, как показано в дампе 2.3.3
Дамп 2.3.1
$ git status На ветке warrior Ваша ветка обновлена в соответствии с "origin/ br00A".
2.4 Слияние с ветвью "Master/Main"
Рано или поздно в процессе улучшения исходного кода, хранящегося в репозитарии проекта, придется ставить точку или запятую в целях развития и/или извлечение коммерческой выгоды, которая требует зачастую "сохранять" исходный код в ветви "Master/Main", как показано в дампе 2.4.1
Дамп 2.4.1
$ git checkout master Переключено на ветку «master» $ git merge br02A Обновление 884e8dd..bb06086 Fast-forward CHANGES.rst | 4323 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ LICENSE | 19 + ...
2.5 Удаление избыточной ветви "br02A"
Прошедщую слияние ветвь «br02A» можно удалить, как показано в дампе 2.5.1, т.к. является избыточной .
Дамп 2.5.1
$ git branch -d br02A Ветка br02A удалена (была bb06086).
После чего, стоит посмотреть на оставшиеся ветви, как показано в дампе 2.5.2
Дамп 2.5.2
$ git branch * master br00A br01A
При этом, удаление ветви, как и её слияние может потребовать выполнить сохранение сделанных изменений в организации хранения исходного кода репозитария командой git push origin, как показано в дамп 2.5.3
Дамп 2.5.3
$ git push origin master
2.6 Результат применения стратегии управлением репозитарием
показывает организацию "творческого" процесса внесения изменений в исходный код репозитария, при котором снижаются риски потери исходного кода и возможность сделанных всех изменений в нем, как показано на схеме ветвления 2.6.1 .
Схема ветвления 2.6.1
┌──────────┐ ╔═════════════╗
┌──>│ br00A │ ┌────────>║ Master/Main ║
│ └────────┐─┘ │ ╚═════════════╝
│ │ ┌──────────┐
─ ─ ┘ └────────>│ br01A │
└──────────┘
На котором показан результат выполнение стратегии управления репозитарием от создание ветвей "br00A", "br01A", "br02A", до слияние последней с "Master/Main" и её удаления в виду завершения цикла внесения изменений в репозитарий .
2.7 Наглядное применения стратегии управлением репозитарием
В качестве наглядного примера приведу слияние ветви "next" с ветвью "coverity_scan" в реальном проекте rjaan/procps_ptree, как показано ниже .
1.На стороне клиента Git переключился на ветку с которой будет проводится слияние – "coverity_scan" – как показано в дампе 2.7.1
Дамп 2.7.1
~/Projects/procps_ptree$ git checkout coverity_scan Переключено на ветку «coverity_scan» Ваша ветка обновлена в соответствии с «origin/coverity_scan»
2. Затем, здесь же выполнил слияние, как показано в 2.7.2
Дамп 2.7.2
~/Projects/procps_ptree$ git merge next Обновление 28a80b6..6237b0c Fast-forward .gitignore | 4 ++++ .travis.yml | 3 ++- README.md | 2 +- src/main.c | 4 ++-- src/parser.c | 19 ++++++++++++------- 5 files changed, 21 insertions(+), 11 deletions(-)
Но, если речь идет о "GitHub", на этом мои приключения не закончились, потому что нужно было верифицировать только что выполненное на стороне клиента слияние и насколько оно является правильным, как показано на рисунке 2.7.3
Рисунок 2.7.3
Далее, нажал кнопку "Compare & pull request", как показано на рисунке 2.7.4, для открытия диалога "Open a pull request" .
Рисунок 2.7.4
В диалоге "Open a pull request" ввел (по желанию) комментарий причин выполняемого слияния и отправил слияемый код на проверку, нажатием клавиши "Create pull request" . Результаты проверки слияемой ветки были выведены в форме заключительного шага "Next #3", как показано на рисунке 2.7.5
Рисунок 2.7.5
Как показано на рисунке 2.7.5, проверка возможности слияния ветви "next" ошибок не выявила, поэтому мне только осталось нажать кнопку "Merge pull request", которая изминила свой вид на форму ввода данных, как показано на рисунке 2.7.6
Рисунок 2.7.6
Соответственно, после ввода комментария с причинами слияния, завершил сию процедуру нажатием "Confirm merge", результат которой показан на рисунке 2.7.7
Рисунок 2.7.7
В котором написано, что слияние прошло упешно и было предложно удалить ветку, что было мной сделано, нажатием кнопки "Delete ". В результате чего была удалена ветка, что показано на рисунке 2.7.8 и журнале изменений "GitHub" для проекта rjaan/procps_ptree
Рисунок 2.7.8
3. Библиография
3.1 Stackoverflow. Message 'src refspec master does not match any' when pushing commits in Git
3.2 Git Branching - Basic Branching and Merging