Как создать новую ветку в gitlab

GitLab – Создать ветку

Филиал является самостоятельной линией и частью процесса разработки. Создание филиала включает в себя следующие шаги.

Создание ветки

Шаг 1 – Войдите в свою учетную запись GitLab и перейдите к своему проекту в разделе « Проекты ».

Шаг 2 – Чтобы создать ветку, нажмите на опцию Ветви в разделе Репозиторий и нажмите кнопку Новая ветка .

Шаг 3 – На экране Новая ветка введите имя для ветви и нажмите кнопку Создать ветвь .

Шаг 4 – После создания ветки вы увидите экран, показанный ниже, вместе с созданной веткой.

22. Создание ветки

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

01 Создайте ветку

Пришло время сделать нашу страницу более стильной с помощью CSS. Мы будем развивать эту возможность в новой ветке под названием style .

Выполните

git switch -c style git status 

Старожилы могут возразить, что их учили создавать ветки командой git checkout -b style . Помните, я упоминал, что команда checkout перегружена функциями и флагами? Старый способ все еще работает, но он не рекомендуется. Новая команда git switch более выразительна и менее восприимчива к ошибкам. Кроме того, в ней меньше флагов и опций, поэтому ее легче запомнить.

Результат

$ git switch -c style Switched to a new branch 'style' $ git status On branch style nothing to commit, working tree clean 

Обратите внимание, что команда git status сообщает о том, что вы находитесь в ветке style .

02 Добавьте файл стилей style.css

Выполните

touch style.css 

Файл: style.css

h1   color: red; > 

Выполните

git add style.css git commit -m "Added css stylesheet" 

03 Измените основную страницу

Обновите файл hello.html , чтобы использовать стили style.css .

Файл: hello.html

 html>  head>  link type="text/css" rel="stylesheet" media="all" href="style.css" />  head>  body>  h1>Hello, World!h1>  body> html> 

Выполните

git add hello.html git commit -m "Included stylesheet into hello.html" 

04 Измените hello.html , чтобы он использовал style.css .

Файл: hello.html

 html>  head>  link type="text/css" rel="stylesheet" media="all" href="style.css" />  head>  body>  h1>Hello, World!h1>  body> html> 

Выполните

git add hello.html git commit -m "Included stylesheet into hello.html" 

05 Далее

Теперь у нас есть новая ветка под названием style с двумя новыми коммитами. Далее мы узнаем, как переключаться между ветками.

Стандартные команды при работе с репозиторием (git)

В данном разделе мы собрали решение типовых задач, которые могут вам при работе с git репозиторием. В своих проектах мы используем обычную сборку git и GitLab. Поэтому в данных примерах могут быть примеры описанные при работе с данными программами.

Генерация и настройка ключей git для деплоя

1. Для того чтобы сгенерировать deploy key, нужно подключиться к серверу по ssh. Затем выполнить команду ssh-keygen.
2. В консоли появится диалог, в котором нужно будет ввести название файла, где будет сохранен ключ. Этот шаг можно пропустить, тогда ключ будет сохранен в файл с именем по умолчанию (id_rsa).
3. После этого будет предложено ввести кодовую фразу для дополнительной защиты, этот шаг можно пропустить (чтобы не вводить фразу каждый раз, когда идет обращение к гиту).
4. После этого ключ будет сгенерирован, и будет создано 2 файла с приватным и публичным ключами.Теперь нужно лишь скопировать публичный ключ и добавить его в гит репозиторий. Выполняем команду cd ~/.ssh и переходим в директорию, где сохранен наш ключ. Для того чтобы вывести его в консоль, выполняем команду cat (по умолчанию id_rsa.pub). ОБратите внимание, что нужен именно файл с расширением .pub (публичный ключ). Копируем содержимое файла.
5. Далее в GitLab можно настроить репозитория.
   
   1. А в разделе настроек выбрать пункт Deploy keys.
      
   2. Далее нажимаем “New Deploy Key” и попадаем в форму создания нового ключа. Вставляем ключ в поле Key, заполняем название (Title) ключа (в названии желательно указать имя пользователя и ip сервера, где был сгенерирован ключ).

Обновление проекта на git с сервера

Данная действие требуется, когда на сервере, где установлен проект, вносились правки напрямую (например, через sftp или ssh, а не через git).
Для обновления необходимо проделать следующие операции:

1. Подключиться к серверу, на котором уже развернут проект, подключение производим через SSH.
2. Убедиться, что мы находимся в нужной ветке, для этого вводим команду — “git branch”. Мы находимся в ветке “master”.
3. Далее вводим команду — “git status”.
4. Далее нужно убедиться в том, что есть изменения в файлах. Обычно Git помечает их красным цветом.
5. Эти файлы необходимо добавить к индексируемым, следовательно вводим команду — “git add .” “Точка” говорит нам о том, что будут добавлены все файлы. Либо можно добавлять файлы через пробел “git add file1.php file2.php”.
6. Снова проверяем статус репозитория “git status”, добавленные файлы должны быть быть отмечены зеленым цветом.
7. Затем можно создать коммит — “git commit -m ‘your message here’”.
8. Далее делаем “git pull origin master”, принимаем изменения из удаленного репозитория той ветки, в которой находимся.
9. Далее отправляем наши изменения той ветки, в которой находимся — “git push origin master”.
10. Проверяем статус локального репозитория — “git status”, в ответ получаем “On branch master. nothing to commit, working directory clean”.

Какие ветки создавать на новые проекты

Для работы над новым проектом по умолчанию git создаёт ветку master. Если у проекта будет 2 версии (тестовая и боевая), то вам перед началом разработки необходимо создать новую ветку — dev. Для этого нужно:

1. Либо создать ветку с именем dev, локально выполнив команду “git checkout -b dev” находясь в ветке master;
2. Либо создать новую верстку в репозитории посредством GitLab: Project — Branches — New Branch.

Как залить обновления на сервер с git

Если проект имеет только боевую версию (prod):

1. Подключаемся по ssh (вводим логин, пароль, хост).
2. Переходим в директорию с проектом cd (обычно cd var/www/site.ru — если не знаете, то уточните у Менеджера).
3. Выполняем команду “git pull”.

Если проект имеет 2 версии: dev (тестовую версию) и prod (боевой проект)

Если у нас используется 2 версии проекта, то обновления заливаются в 2 ветки: dev и prod.

1. Для выгрузки обновления подключаемся по ssh (вводим логин, пароль, хост).
2. Переходим в директорию с тестовым или боевым проектом cd (обычно cd var/www/dev.site.ru или var/www/site.ru — если не знаете, то уточните у Менеджера).
3. Далее проверяем, что мы находимся в dev ветке, для этого выполняем команду git branch, в результате получаем master или dev (если увидели не то, то выполняем команду для переключения в нужную ветку “git checkout ”).
4. Если вы находитесь в нужной ветке, то выполняете “git pull”.

Как откатить коммит?

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

1. Внимание! Данная операция не затронет внесённых изменений.
2. Выполняем команду “git reset —soft HEAD^”.
3. Отменяется последний коммит, далее мы вносим изменения в коде.
4. Далее создаем новый коммит командой “git commit -m ‘add some code’ ”.
5. И отправляем изменения в репозиторий командой “git push origin master”.

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

1. Осторожно! Эта команда безвозвратно удаляет несохраненные текущие изменения.
2. Для начала нужно узнать хэш последнего коммита. Для этого выполняем команду “git show-ref —heads —hash master”.
3. Далее вводим команду “git revert e882466”, где e882466 — первые 7 символов хэша текущего коммита.
4. Далее нужно подтвердить откат коммита. Нужно ввести название коммита или оставить уже введенный автоматически текст Revert “add one more object” (это пример).
5. Далее отправляем коммит в репозиторий командой “git push origin master” (если текущая ветка master).

Как перенести новый проект клиента в свой git?

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

1. Необходимо получить исходные файлы проекта, путем скачивания через FTP-клиент на свой компьютер.
2. Необходимо получить базу данных проекта. Обычно выкачивается через через PhpMyAdmin, через SSH командой mysqldump или с помощью поддержки системного администратора (можно уточнить у Менеджера).
3. Далее нужно сообщить Менеджеру, чтобы он создал новый репозиторий в GitLab для данного проекта.
4. Далее клонируем пустой репозиторий к себе на локальный компьютер, например, в папку C:\Projects\foobar с помощью команды ‘git clone полный-путь-до-репозитория.git ’.
5. Скачанный проект нужно поместить в папку с клонированным пустым репозиторием (который находится, например, в папке C:\Projects\foobar).
6. Создать файл .gitignore и указать там необходимые файлы и директории, которые не должны попасть в git.
7. Далее нужно отправить в гит файлы проекта, выполнив команду “git push origin master”.
8. Далее нужно запросить у Менеджера доступный для это проекта домен (или поддомен) для разработки, а также доступы к SSH сервера, доступы для подключения к СУБД и выделенную базу данных для этого проекта, на котором будет вестись доработка проекта или обычное расположение.
9. Необходимо зайти на сервер под полученными доступами SSH
10. Начать развертывание проекта из git.
    1. Перейти в указанную Менеджером папку с поддоменом с помощью команды cd (обычно cd var/www/site.ru).
    2. Сгенерировать и настроить deploy keys (см. пункт 1).
    3. Выполнить команду ‘git clone полный-путь-до-репозитория.git ’.
    4. Заказать на сервер дамп базы данных с помощью команды scp с указанием размещения на сервере пути для дампа БД (она похожа на команду ssh).
    5. Развернуть дамп БД на сервере выполнить mysql -u USER -pPASSWORD DATABASE < /path/to/dump.sql.
    6. Если проект основан на фреймворке (Yii2, Symfony ¾, Laravel, Zend или другой), то необходимо подтянуть зависимости PHP пакетов (расширений).
    7. Нужно установить composer.phar в папку проекта, выполнив команды, указанные по этому адресу https://getcomposer.org/download/.
    8. Выполнить команду composer.phar update.
    9. Загрузить файлы и директории, которые ранее добавили в .gitignore.
    10. Проверить работоспособность проекта, пройдя по поддомену/домену.

    Отправка проекта в Git, если будет выполнятся code review

    Code review — процесс проверки кода на предмет технических не соответсвий и ошибок.
    Для удобного просмотра изменений бновления нужно вгрузить в ветку master через Merge Request (не путать с консольной командой merge) в панели управления репозиторием GitLab.
    Для этого выполните следующие действия:

    1. В разделе Merge Requests в панели управления репозиторием GitLab перейти в раздел “New Merge Request”.
       
    2. Далее в качестве Source branch выбрать ветку dev, а в качестве Target branch соответственно master ветку.
       
    3. После нажатия на кнопку Compage branches and continue отобразится следующая форма:
       
       В качестве Title необходимо указать ID и наименование задачи из багтрекера, а также необходимо закрепить merge request за проверяющим порграммистом выбрав его в поле Assignee.

    После того как проверяющий проверил реализованный код, то необходимо произвести git pull на сервере в продакшн версии проекта.

    3.2 Ветвление в Git — Основы ветвления и слияния

    Давайте рассмотрим простой пример рабочего процесса, который может быть полезен в вашем проекте. Ваша работа построена так:

    1. Вы работаете над сайтом.
    2. Вы создаете ветку для реализации новой функциональности в соответствии с пользовательской историей.
    3. Вы работаете в этой ветке.

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

    1. Переключиться на основную ветку.
    2. Создать ветку для добавления исправления.
    3. После тестирования слить ветку, содержащую исправление, с основной веткой.
    4. Переключиться назад в ветку для реализации пользовательской истории и продолжить работать.

    Основы ветвления

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

    

    Рисунок 18. Простая история коммитов

    Вы выбрали задачу #53 из какая-там-у-вас-система-отслеживания-задач. Чтобы создать ветку и сразу переключиться на неё, можно выполнить команду git checkout с параметром -b :

    $ git checkout -b iss53 Switched to a new branch "iss53"

    Это то же самое, что и:

    $ git branch iss53 $ git checkout iss53

    

    Рисунок 19. Создание нового указателя ветки

    Вы работаете над сайтом и делаете коммиты. Это приводит к тому, что ветка iss53 движется вперед, так как вы переключились на неё ранее ( HEAD указывает на неё).

    $ vim index.html $ git commit -a -m 'Create new footer [issue 53]'

    

    Рисунок 20. Ветка iss53 движется вперед

    И тут вы получаете сообщение об обнаружении на сайте уязвимости, и эту уязвимость устранить нужно немедленно. Благодаря Git вам не придётся ни пытаться реализовать исправление вместе с изменениями, которые вы сделали в ходе разработки iss53 , ни прилагать усилия для отката этих изменений и возвращения к исходному состоянию перед началом разработки исправления. Все, что вам нужно — переключиться на ветку master .

    Имейте в виду, что если рабочий каталог или индекс содержат незафиксированные изменения, конфликтующие с веткой, на которую вы хотите переключиться, то Git не позволит переключить ветки. Лучше всего переключаться из чистого рабочего состояния проекта: все изменённые файлы добавить в индекс и сделать коммит. Есть способы обойти это (припрятать изменения (stash) или добавить их в последний коммит (amend)), но об этом мы поговорим позже в разделе Припрятывание и очистка главы 7. Теперь предположим, что вы зафиксировали все свои изменения и можете переключиться на ветку master :

    $ git checkout master Switched to branch 'master'

    С этого момента ваш рабочий каталог имеет точно такой же вид, какой был перед началом работы над задачей #53, и вы можете сосредоточиться на работе над исправлением. Важно запомнить: когда вы переключаете ветки, Git возвращает состояние рабочего каталога к тому виду, какой он имел в момент последнего коммита в переключаемую ветку. Он добавляет, удаляет и изменяет файлы автоматически, чтобы состояние рабочего каталога соответствовало тому, когда был сделан последний коммит.

    Теперь вы можете перейти к написанию исправления. Давайте создадим новую ветку, в которой реализуем исправление.

    $ git checkout -b hotfix Switched to a new branch 'hotfix' $ vim index.html $ git commit -a -m 'Fix broken email address' [hotfix 1fb7853] Fix broken email address 1 file changed, 2 insertions(+)

    

    Рисунок 21. Ветка hotfix основана на ветке master

    Вы можете прогнать тесты, чтобы убедиться, что ваше уязвимость в самом деле исправлена. И если это так — выполнить слияние ветки hotfix с веткой master для включения изменений в продукт. Это делается командой git merge :

    $ git checkout master $ git merge hotfix Updating f42c576..3a0874c Fast-forward index.html | 2 ++ 1 file changed, 2 insertions(+)

    Заметили фразу «fast-forward» в этом слиянии? Git просто переместил указатель ветки вперед, потому что коммит C4 , на который указывает слитая ветка hotfix , был прямым потомком коммита C2 , на котором вы находились до этого. Другими словами, если коммит сливается с тем, до которого можно добраться, двигаясь по истории вперёд, Git упрощает слияние, просто перенося указатель ветки вперед, потому что в этом случае нет никаких разнонаправленных изменений, которые нужно было бы свести воедино. Это называется «fast-forward».

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

    

    Рисунок 22. master перемотан до hotfix

    После внедрения вашего архиважного исправления вы готовы вернуться к работе над тем, что были вынуждены отложить. Но сначала нужно удалить ветку hotfix , потому что она больше не нужна — ветка master указывает на то же самое место. Для удаления ветки выполните команду git branch с параметром -d :

    $ git branch -d hotfix Deleted branch hotfix (3a0874c).

    Теперь вы можете переключиться обратно на ветку iss53 и продолжить работу над задачей #53:

    $ git checkout iss53 Switched to branch "iss53" $ vim index.html $ git commit -a -m 'Finish the new footer [issue 53]' [iss53 ad82d7a] Finish the new footer [issue 53] 1 file changed, 1 insertion(+)

    

    Рисунок 23. Продолжение работы над iss53

    Стоит обратить внимание на то, что все изменения из ветки hotfix не включены в вашу ветку iss53 . Если их нужно включить, вы можете влить ветку master в вашу ветку iss53 командой git merge master , а можете отложить слияние этих изменений до завершения работы, и затем влить ветку iss53 в master .

    Основы слияния

    Предположим, вы решили, что работа по проблеме #53 закончена и её можно влить в ветку master . Для этого нужно выполнить слияние ветки iss53 точно так же, как вы делали это с веткой hotfix ранее. Все, что нужно сделать — переключиться на ветку, в которую вы хотите включить изменения, и выполнить команду git merge :

    $ git checkout master Switched to branch 'master' $ git merge iss53 Merge made by the 'recursive' strategy. index.html | 1 + 1 file changed, 1 insertion(+)

    Результат этой операции отличается от результата слияния ветки hotfix . В данном случае процесс разработки ответвился в более ранней точке. Так как коммит, на котором мы находимся, не является прямым родителем ветки, с которой мы выполняем слияние, Git придётся немного потрудиться. В этом случае Git выполняет простое трёхстороннее слияние, используя последние коммиты объединяемых веток и общего для них родительского коммита.

    

    Рисунок 24. Использование трёх снимков при слиянии

    Вместо того, чтобы просто передвинуть указатель ветки вперёд, Git создаёт новый результирующий снимок трёхстороннего слияния, а затем автоматически делает коммит. Этот особый коммит называют коммитом слияния, так как у него более одного предка.

    

    Рисунок 25. Коммит слияния

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

    $ git branch -d iss53

    Основные конфликты слияния

    Иногда процесс не проходит гладко. Если вы изменили одну и ту же часть одного и того же файла по-разному в двух объединяемых ветках, Git не сможет их чисто объединить. Если ваше исправление ошибки #53 потребовало изменить ту же часть файла что и hotfix , вы получите примерно такое сообщение о конфликте слияния:

    $ git merge iss53 Auto-merging index.html CONFLICT (content): Merge conflict in index.html Automatic merge failed; fix conflicts and then commit the result.

    Git не создал коммит слияния автоматически. Он остановил процесс до тех пор, пока вы не разрешите конфликт. Чтобы в любой момент после появления конфликта увидеть, какие файлы не объединены, вы можете запустить git status :

    $ git status On branch master You have unmerged paths. (fix conflicts and run "git commit") Unmerged paths: (use "git add . " to mark resolution) both modified: index.html no changes added to commit (use "git add" and/or "git commit -a")

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

    contact : email.support@github.com

 
please contact us at email.support@github.com
 

$ git mergetool This message is displayed because 'merge.tool' is not configured. See 'git mergetool --tool-help' or 'git help config' for more details. 'git mergetool' will now attempt to use one of the following tools: opendiff kdiff3 tkdiff xxdiff meld tortoisemerge gvimdiff diffuse diffmerge ecmerge p4merge araxis bc3 codecompare vimdiff emerge Merging: index.html Normal merge conflict for 'index.html': : modified file : modified file Hit return to start merge resolution tool (opendiff):

$ git status On branch master All conflicts fixed but you are still merging. (use "git commit" to conclude merge) Changes to be committed: modified: index.html

Merge branch 'iss53' Conflicts: index.html # # It looks like you may be committing a merge. # If this is not correct, please remove the file # .git/MERGE_HEAD # and try again. # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # On branch master # All conflicts fixed but you are still merging. # # Changes to be committed: # modified: index.html #