Стандартные команды при работе с репозиторием (git)
В данном разделе мы собрали решение типовых задач, которые могут вам при работе с git репозиторием. В своих проектах мы используем обычную сборку git и GitLab. Поэтому в данных примерах могут быть примеры описанные при работе с данными программами.
Генерация и настройка ключей git для деплоя
- Для того чтобы сгенерировать deploy key, нужно подключиться к серверу по ssh. Затем выполнить команду ssh-keygen.
- В консоли появится диалог, в котором нужно будет ввести название файла, где будет сохранен ключ. Этот шаг можно пропустить, тогда ключ будет сохранен в файл с именем по умолчанию (id_rsa).
- После этого будет предложено ввести кодовую фразу для дополнительной защиты, этот шаг можно пропустить (чтобы не вводить фразу каждый раз, когда идет обращение к гиту).
- После этого ключ будет сгенерирован, и будет создано 2 файла с приватным и публичным ключами.Теперь нужно лишь скопировать публичный ключ и добавить его в гит репозиторий. Выполняем команду cd ~/.ssh и переходим в директорию, где сохранен наш ключ. Для того чтобы вывести его в консоль, выполняем команду cat (по умолчанию id_rsa.pub). ОБратите внимание, что нужен именно файл с расширением .pub (публичный ключ). Копируем содержимое файла.
- Далее в GitLab можно настроить репозитория.
- А в разделе настроек выбрать пункт Deploy keys.
- Далее нажимаем “New Deploy Key” и попадаем в форму создания нового ключа. Вставляем ключ в поле Key, заполняем название (Title) ключа (в названии желательно указать имя пользователя и ip сервера, где был сгенерирован ключ).
- А в разделе настроек выбрать пункт Deploy keys.
Обновление проекта на git с сервера
Данная действие требуется, когда на сервере, где установлен проект, вносились правки напрямую (например, через sftp или ssh, а не через git).
Для обновления необходимо проделать следующие операции:
- Подключиться к серверу, на котором уже развернут проект, подключение производим через SSH.
- Убедиться, что мы находимся в нужной ветке, для этого вводим команду — “git branch”. Мы находимся в ветке “master”.
- Далее вводим команду — “git status”.
- Далее нужно убедиться в том, что есть изменения в файлах. Обычно Git помечает их красным цветом.
- Эти файлы необходимо добавить к индексируемым, следовательно вводим команду — “git add .” “Точка” говорит нам о том, что будут добавлены все файлы. Либо можно добавлять файлы через пробел “git add file1.php file2.php”.
- Снова проверяем статус репозитория “git status”, добавленные файлы должны быть быть отмечены зеленым цветом.
- Затем можно создать коммит — “git commit -m ‘your message here’”.
- Далее делаем “git pull origin master”, принимаем изменения из удаленного репозитория той ветки, в которой находимся.
- Далее отправляем наши изменения той ветки, в которой находимся — “git push origin master”.
- Проверяем статус локального репозитория — “git status”, в ответ получаем “On branch master. nothing to commit, working directory clean”.
Какие ветки создавать на новые проекты
Для работы над новым проектом по умолчанию git создаёт ветку master. Если у проекта будет 2 версии (тестовая и боевая), то вам перед началом разработки необходимо создать новую ветку — dev. Для этого нужно:
- Либо создать ветку с именем dev, локально выполнив команду “git checkout -b dev” находясь в ветке master;
- Либо создать новую верстку в репозитории посредством GitLab: Project — Branches — New Branch.
Как залить обновления на сервер с git
Если проект имеет только боевую версию (prod):
- Подключаемся по ssh (вводим логин, пароль, хост).
- Переходим в директорию с проектом cd (обычно cd var/www/site.ru — если не знаете, то уточните у Менеджера).
- Выполняем команду “git pull”.
Если проект имеет 2 версии: dev (тестовую версию) и prod (боевой проект)
Если у нас используется 2 версии проекта, то обновления заливаются в 2 ветки: dev и prod.
- Для выгрузки обновления подключаемся по ssh (вводим логин, пароль, хост).
- Переходим в директорию с тестовым или боевым проектом cd (обычно cd var/www/dev.site.ru или var/www/site.ru — если не знаете, то уточните у Менеджера).
- Далее проверяем, что мы находимся в dev ветке, для этого выполняем команду git branch, в результате получаем master или dev (если увидели не то, то выполняем команду для переключения в нужную ветку “git checkout ”).
- Если вы находитесь в нужной ветке, то выполняете “git pull”.
Как откатить коммит?
Если требуется отменить изменения в уже созданном коммите, допустим, вы что-то забыли дописать в коде, то нужно выполнить:
- Внимание! Данная операция не затронет внесённых изменений.
- Выполняем команду “git reset —soft HEAD^”.
- Отменяется последний коммит, далее мы вносим изменения в коде.
- Далее создаем новый коммит командой “git commit -m ‘add some code’ ”.
- И отправляем изменения в репозиторий командой “git push origin master”.
Если требуется откатить залитые правки до предыдущего коммита, то нужно выполнить:
- Осторожно! Эта команда безвозвратно удаляет несохраненные текущие изменения.
- Для начала нужно узнать хэш последнего коммита. Для этого выполняем команду “git show-ref —heads —hash master”.
- Далее вводим команду “git revert e882466”, где e882466 — первые 7 символов хэша текущего коммита.
- Далее нужно подтвердить откат коммита. Нужно ввести название коммита или оставить уже введенный автоматически текст Revert “add one more object” (это пример).
- Далее отправляем коммит в репозиторий командой “git push origin master” (если текущая ветка master).
Как перенести новый проект клиента в свой git?
В том случае, если проект редактировался напрямую через ftp или ssh, то требуется обновить версию проекта, размещенного на git. Для этого необходимо выполнить следующие шаги:
- Необходимо получить исходные файлы проекта, путем скачивания через FTP-клиент на свой компьютер.
- Необходимо получить базу данных проекта. Обычно выкачивается через через PhpMyAdmin, через SSH командой mysqldump или с помощью поддержки системного администратора (можно уточнить у Менеджера).
- Далее нужно сообщить Менеджеру, чтобы он создал новый репозиторий в GitLab для данного проекта.
- Далее клонируем пустой репозиторий к себе на локальный компьютер, например, в папку C:\Projects\foobar с помощью команды ‘git clone полный-путь-до-репозитория.git ’.
- Скачанный проект нужно поместить в папку с клонированным пустым репозиторием (который находится, например, в папке C:\Projects\foobar).
- Создать файл .gitignore и указать там необходимые файлы и директории, которые не должны попасть в git.
- Далее нужно отправить в гит файлы проекта, выполнив команду “git push origin master”.
- Далее нужно запросить у Менеджера доступный для это проекта домен (или поддомен) для разработки, а также доступы к SSH сервера, доступы для подключения к СУБД и выделенную базу данных для этого проекта, на котором будет вестись доработка проекта или обычное расположение.
- Необходимо зайти на сервер под полученными доступами SSH
- Начать развертывание проекта из git.
- Перейти в указанную Менеджером папку с поддоменом с помощью команды cd (обычно cd var/www/site.ru).
- Сгенерировать и настроить deploy keys (см. пункт 1).
- Выполнить команду ‘git clone полный-путь-до-репозитория.git ’.
- Заказать на сервер дамп базы данных с помощью команды scp с указанием размещения на сервере пути для дампа БД (она похожа на команду ssh).
- Развернуть дамп БД на сервере выполнить mysql -u USER -pPASSWORD DATABASE < /path/to/dump.sql.
- Если проект основан на фреймворке (Yii2, Symfony ¾, Laravel, Zend или другой), то необходимо подтянуть зависимости PHP пакетов (расширений).
- Нужно установить composer.phar в папку проекта, выполнив команды, указанные по этому адресу https://getcomposer.org/download/.
- Выполнить команду composer.phar update.
- Загрузить файлы и директории, которые ранее добавили в .gitignore.
- Проверить работоспособность проекта, пройдя по поддомену/домену.
Отправка проекта в Git, если будет выполнятся code review
Code review — процесс проверки кода на предмет технических не соответсвий и ошибок.
Для удобного просмотра изменений бновления нужно вгрузить в ветку master через Merge Request (не путать с консольной командой merge) в панели управления репозиторием GitLab.
Для этого выполните следующие действия:- В разделе Merge Requests в панели управления репозиторием GitLab перейти в раздел “New Merge Request”.
- Далее в качестве Source branch выбрать ветку dev, а в качестве Target branch соответственно master ветку.
- После нажатия на кнопку Compage branches and continue отобразится следующая форма:
В качестве Title необходимо указать ID и наименование задачи из багтрекера, а также необходимо закрепить merge request за проверяющим порграммистом выбрав его в поле Assignee.
После того как проверяющий проверил реализованный код, то необходимо произвести git pull на сервере в продакшн версии проекта.
Code review в Gitlab CE: если Merge request approvals нет, но очень хочется
Одной из самых нужных функций, которой нет в бесплатной версии GitLab, является возможность
голосования против обнуления репозиторияконтролировать Merge request (MR), используя обязательный code review.Сделаем минимальный функционал сами — запретим Merge, пока несколько разработчиков не поставят «палец вверх» на MR.
Зачем это вообще?
Наша организация вполне может позволить себе купить лицензию GitLab. Но, так как разработка ведется в закрытом контуре без доступа в интернет, и есть жесткое планирование бюджета, закупка лицензий self-managed с нужным функционалом может затянуться на многие месяцы, а работать нужно уже сейчас.
В итоге приходится:
- либо совсем запрещать Merge в защищенные ветки для части разработчиков, но тогда разработчики, имеющие право на Merge, получают конфликты при слиянии чужих MR как бонус;
- либо давать возможность делать бесконтрольные слияния с вашей мастер-веткой без code review, даже если это Junior, устроившийся только вчера.
Общая схема работы
В качестве примера настроим Merge request approvals на тестовом репозитории myapp:
- Создадим токен для доступа к API GitLab (через него будем получать информацию о количестве голосов «за» и «против»)
- Добавим токен в переменные GitLab
- Запретим Merge при ошибках в пайплайне (если голосов «за» недостаточно)
- Настроим проверку голосов как часть пайплайна CI/CD
- Запретим делать коммиты в защищенные ветки, все изменения проводим только через MR
- Проверим, что получилось в итоге
1. Создаем токен для доступа к API
Заходим в Настройки пользователя → Токены доступа и записываем токен:
Учетная запись для получения токена
Доступ к API позволяет делать практически все с вашими репозиториями, поэтому советую создать отдельную учетную запись Gitlab, дать ей минимальные права на ваши репозтории (например, Reporter) и получить токен для этой учетной записи.
2. Добавляем токен в переменные Gitlab
Например, на предыдущем шаге мы получили токен QmN2Y0NOUFlfeXhvd21ZS01aQzgK
Открываем Настройки → CI/CD → Переменные → Добавить переменную → GITLAB_TOKEN_FOR_CI
В итоге получим:
Это можно сделать как на одном репозитории, так и на группе репозиториев.
3. Ставим запрет на Merge, если не получены одобрения коллег после проведенного code review
В нашем случае запретом на Merge будет являться то, что сборочный конвейер вернет ошибку при недостаточном количестве голосов.
Заходим в Настройки → Основные → Запросы на слияние → Проверки слияния и включаем опцию Сборочные линии должны успешно выполниться.
4. Настраиваем пайплайн
Если вы еще не делали CI/CD конвейер для вашего приложения
Создаем в корне репозитория файл .gitlab-ci.yml с простейшим содержанием:
stages: - build - test variables: NEED_VOTES: 1 include: - remote: "https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml" run-myapp: stage: build script: echo "Hello world"Отдельный репозиторий для конфигурации CI/CD
Я бы рекомендовал сделать отдельный репозиторий, в котором необходимо создать файл myapp.gitlab-ci.yml для настройки конвейера. Так вы сможете лучше контролировать доступ участников, которые могут изменить конвейер сборки и получить токен доступа.
Расположение нового файла конвейера нужно будет указать, зайдя в репозиторий myapp — Настройки — CI/CD — Сборочные линии — Пользовательский путь конфигурации CI — указать новый файл, например myapp.gitlab-ci.yml@gitlab-ce-mr-approvals/Ci
Совет: используйте линтер для внесения изменений в файлы GitLab CI
Даже если вы работаете один, хорошим помощником выступит работа через MR, прогоняя все ваши изменения файлов пайплайна через линтер. Если вы ошибетесь в синтаксисе YAML-файла, это не даст вам сломать рабочий конвейер, а просто заблокирует Merge.
Пример контейнеров с линтерами, которые вы можете встроить в ваш пайплайн:
И пример стадии проверки:
stages: - lint lint: stage: lint image: sebiwi/gitlab-ci-validate:1.3.0 variables: GITLAB_HOST: https://gitlab.com script: - CI_FILES=(./*.yml) - for f in "$"; do gitlab-ci-validate $f; done;Осталось добавить в ваш пайплайн несколько параметров, чтобы все заработало:
variables:
NEED_VOTES: 1include:
— remote: «https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml»Переменная NEED_VOTES определяет сколько «пальцев вверх» должно быть у MR, чтобы был доступен Merge. Значение, равное единице, означает, что вы сами можете одобрить свой MR, «лайкнув» его.
include подключает стадию test, проверяющую количество «лайков».
Простейший пайплайн на примере myapp.gitlab-ci.yml
stages:
— build
— testvariables:
NEED_VOTES: 0include:
— remote: «https://gitlab.com/gitlab-ce-mr-approvals/ci/-/raw/master/check-approve.gitlab-ci.yml»run-myapp:
stage: build
image: openjdk
script:
— echo CI_MERGE_REQUEST_TARGET_BRANCH_NAME $CI_MERGE_REQUEST_TARGET_BRANCH_NAME
— java HelloWorld.javaСодержание check-approve.gitlab-ci.yml
ci-mr:
stage: test
script:
— echo $
— echo «CI_PROJECT_ID $»
— echo «CI_COMMIT_SHA $»
— «export MR_ID=$(curl —silent —request GET —header \»PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\» $/projects/$/merge_requests | jq \».[] | if .sha == \\\»$\\\» then .id else <> end\» | grep —invert-match <>)»
— «export MR_TITLE=$(curl —silent —request GET —header \»PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\» $/projects/$/merge_requests | jq \».[] | if .sha == \\\»$\\\» then .title else <> end\» | grep —invert-match <>)»
— «export MR_WIP=$(curl —silent —request GET —header \»PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\» $/projects/$/merge_requests | jq \».[] | if .sha == \\\»$\\\» then .work_in_progress else <> end\» | grep —invert-match <>)»
— «export MR_UPVOTES=$(curl —silent —request GET —header \»PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\» $/projects/$/merge_requests | jq \».[] | if .sha == \\\»$\\\» then .upvotes else <> end\» | grep —invert-match <>)»
— «export MR_DOWNVOTES=$(curl —silent —request GET —header \»PRIVATE-TOKEN: $GITLAB_TOKEN_FOR_CI\» $/projects/$/merge_requests | jq \».[] | if .sha == \\\»$\\\» then .downvotes else <> end\» | grep —invert-match <>)»
— MR_VOTES=$(expr $ — $)
— NEED_VOTES_REAL=$
— echo «MR_ID $ MR_TITLE $ MR_WIP $ MR_UPVOTES $ MR_DOWNVOTES $»
— echo «MR_VOTES $ Up vote = 1, down vote = -1, MR OK if votes >=$»
— if [ «$» -ge «$(expr $)» ];
then
echo «MR OK»;
else
echo «MR ERROR Need more votes»;
exit 1;
fi
image: laptevss/gitlab-api-util
rules:
— if: ‘$CI_MERGE_REQUEST_TARGET_BRANCH_NAME == «master» || $CI_MERGE_REQUEST_TARGET_BRANCH_NAME =~ /^release\/.*$/’Подробнее о том, что происходит при проверке:
- установлено ограничение, что проверка будет только при создании MR в ветки master или release/*
- используя API GitLab, получаем количество «лайков» и «дизлайков»
- вычисляем разность между положительными и отрицательными откликами
- если разность меньше заданного нами значения в NEED_VOTES, то блокируем возможность сделать слияние
5. Запрещаем коммиты в защищенные ветки
Определяем ветки, для которых мы должны проводить code review и указываем, что работать с ними можно только через MR.
Для этого заходим в Настройки → Репозиторий → Protected Branches:
6. Проверяем
Зададим NEED_VOTES: 0
Делаем MR и ставим «дизлайк».
Теперь ставим «лайк» и запускаем повторную проверку:
Выполнение запроса pull
Pull requests are a feature that makes it easier for developers to collaborate using Bitbucket. They provide a user-friendly web interface for discussing proposed changes before integrating them into the official project.
В упрощенном виде запросы pull — это механизм, с помощью которого разработчик уведомляет участников команды о том, что он подготовил некий функционал. Закончив работу над функциональной веткой, разработчик создает запрос pull с помощью аккаунта Bitbucket. Так все участники процесса узнают, что требуется проверить код и выполнить слияние с главной веткой ( main ).
Однако запрос pull — это не просто уведомление, а специальный форум для обсуждения предлагаемой функции. Если с изменениями возникли какие-либо проблемы, участники команды могут публиковать в запросе pull отзывы и даже изменять функцию с помощью дополнительных коммитов. Все эти действия отслеживается непосредственно внутри запроса pull.
По сравнению с другими моделями совместной работы это формальное решение для обмена коммитами обеспечивает гораздо более упорядоченный рабочий процесс. SVN и Git могут автоматически отправлять уведомления по электронной почте с помощью простого скрипта; однако когда дело доходит до обсуждения изменений, разработчикам обычно приходится вести диалог по электронной почте. Такой подход может внести путаницу, особенно если начинается обмен дополняющими коммитами. Запросы pull помещают все эти функции в удобный веб-интерфейс рядом с репозиториями Bitbucket.
Структура запроса pull
Создавая пул-реквест, вы всего лишь просите другого разработчика (например, человека, занимающегося поддержкой проекта) забрать ветку из вашего репозитория в его репозиторий. Поэтому для создания пул-реквеста необходимо указать 4 параметра: исходный репозиторий, исходную ветку, репозиторий назначения и ветку назначения.
Для многих параметров сервис Bitbucket определяет нужные значения по умолчанию. Однако в зависимости от того, как налажен процесс совместной работы команды, может потребоваться указать другие значения. На приведенной выше схеме показан запрос pull о слиянии функциональной ветки с официальной главной веткой, однако существует множество других способов использования запросов pull.
Порядок действий
Пул-реквесты можно применять в сочетании с процессами Feature Branch Workflow, Gitflow Workflow или Forking Workflow. При этом для использования пул-реквестов требуются две отдельные ветки или два отдельных репозитория. Поэтому пул-реквесты не будут работать при использовании процесса Centralized Workflow. Использование пул-реквестов в каждом из перечисленных процессов имеет свои нюансы, но общий подход описан ниже.
1. Разработчик создает функцию в отдельной ветке в своем локальном репозитории.
2. The developer pushes the branch to a public Bitbucket repository.
3. The developer files a pull request via Bitbucket.
4. The rest of the team reviews the code, discusses it, and alters it.
5. The project maintainer merges the feature into the official repository and closes the pull request.
Далее в этом разделе описывается, как запрос pull может использоваться в различных процессах совместной работы.
Связанные материалы
Расширенный журнал Git
СМ. РЕШЕНИЕ
Изучите Git с помощью Bitbucket Cloud
Использование запросов pull в рабочем процессе с функциональными ветками
В жизненном цикле функциональной ветки для организации совместной работы используется общий репозиторий Bitbucket, в котором разработчики создают новый функционал в изолированных ветках. Но вместо немедленного слияния кода с веткой main разработчики должны создать запрос pull, чтобы начать обсуждение функциональной ветки до ее включения в основную базу кода.
В процессе Feature Branch существует только один публичный репозиторий, поэтому исходный и целевой репозитории в запросе pull всегда будут совпадать. Обычно разработчик указывает свою функциональную ветку в качестве исходной, а ветку main — в качестве целевой ветки.
Получив запрос pull, человек, занимающийся поддержкой проекта, должен принять решение. Если функциональная ветка готова к использованию, можно выполнить слияние кода с веткой main и закрыть запрос pull. Но если в предлагаемых изменениях есть проблемы, можно оставить комментарии в запросе pull. Последующие коммиты будут отображаться рядом с соответствующими комментариями.
Кроме того, можно создать запрос pull для незавершенной функции. Например, если у разработчика возникают проблемы с реализацией определенного требования, он может создать запрос pull, содержащий его наработки. Другие разработчики могут оставить внутри этого запроса pull свои предложения или даже решить проблему, добавив дополнительные коммиты.
Использование запросов pull в рабочем процессе Gitflow
Рабочий процесс Gitflow похож на рабочий процесс с функциональными ветками, но устанавливает строгую модель ветвления, разработанную для релиза проекта. При добавлении запросов pull в рабочий процесс Gitflow разработчики получают удобное место для обсуждения ветки релиза или ветки сопровождения в ходе работы над ней.
Механизм запросов pull в рабочем процессе Gitflow аналогичен описанному выше: разработчик просто создает запрос pull, когда необходимо проверить функцию, релиз или ветку исправлений, а остальные участники команды получают уведомления через Bitbucket.
Слияние функциональных веток обычно выполняют с веткой разработки develop , а слияние веток релизов и исправлений выполняют и с веткой develop , и с веткой main . Запросы pull можно использовать в качестве инструмента формального управления всеми этими слияниями.
Использование запросов pull в рабочем процессе с форками
В процессе с использованием форков разработчик помещает завершенную функциональную ветку в собственный публичный репозиторий, а не в общий репозиторий. После этого разработчик создает пул-реквест, оповещая человека, занимающегося поддержкой проекта, о готовности кода к проверке.
Для этого рабочего процесса наличие уведомления в запросе pull особенно важно, иначе человек, занимающийся поддержкой проекта, не сможет узнать о том, что другой разработчик добавил коммиты в свой репозиторий Bitbucket.
Поскольку у каждого разработчика есть свой публичный репозиторий, исходный и целевой репозитории в запросе pull будут отличаться. Исходным будет публичный репозиторий разработчика, а исходной веткой — та, что содержит предлагаемые изменения. Если разработчик предлагает слить функциональную ветку с основной базой кода, целевым репозиторием будет официальный репозиторий проекта, а целевой веткой — главная ветка main .
Кроме того, пул-реквесты можно использовать для совместной работы с другими разработчиками за пределами официального репозитория проекта. Например, если разработчик работал над функциональной веткой вместе с коллегой, они могут создать пул-реквест, указав в качестве назначения репозиторий Bitbucket коллеги, а не официальный репозиторий проекта. Тогда они смогут указать в качестве исходной ветки и ветки назначения одну и ту же функциональную ветку.
Два разработчика могут обсуждать и разрабатывать функцию внутри запроса pull. По окончании разработки один из них создает новый запрос pull на слияние этой функции с официальной главной веткой. Такая гибкость делает запросы pull невероятно мощным инструментом совместной работы в рамках рабочего процесса с форками.
Пример
В приведенном ниже примере демонстрируется использование запросов pull в рабочем процессе с форками. Он одинаково применим как для разработчиков, работающих в маленьких командах, так и для независимых разработчиков, участвующих в проекте с открытым исходным кодом.
В данном примере Мэри — разработчик, а Джон — человек, занимающийся поддержкой проекта. У обоих есть собственные публичные репозитории Bitbucket, и в репозитории Джона находится официальный проект.
Мэри создает форк официального проекта
Чтобы начать работу над проектом, Мэри сначала должна создать форк репозитория Джона в Bitbucket. Для этого ей нужно войти в Bitbucket, перейти к репозиторию Джона и нажать кнопку Fork.
Указав имя и описание для репозитория, создаваемого с помощью форка, она получит копию серверной части проекта.
Мэри клонирует свой репозиторий Bitbucket
Затем Мэри должна клонировать репозиторий Bitbucket, который она только что создала с помощью форка. Так она получит собственную рабочую копию проекта на своей локальной машине. Она может сделать это с помощью следующей команды:
git clone https://user@bitbucket.org/user/repo.gitПомните, что команда git clone автоматически создает удаленный репозиторий origin , который указывает на репозиторий Мэри, созданный с помощью форка.
Мэри разрабатывает новый функционал
Прежде чем писать какой бы то ни было код, Мэри должна создать новую ветку для функции. Эту ветку она будет использовать в качестве исходной в запросе pull.
git checkout -b some-feature
# Edit some code
git commit -a -m "Add first draft of some feature"Мэри может выполнять сколько угодно коммитов во время работы над функциональной веткой. Если история создания функциональной ветки выглядит слишком запутанной, она может использовать интерактивную операцию rebase для удаления или склеивания ненужных коммитов. Такая очистка истории функциональной ветки в больших проектах помогает человеку, занимающемуся поддержкой проекта, быстрее понять, что включено в пул-реквест.
Мэри помещает функциональную ветку в свой репозиторий Bitbucket
Закончив свою задачу, Мэри помещает функциональную ветку в собственный репозиторий Bitbucket (не в официальный репозиторий проекта) с помощью простой команды git push :
git push origin some-branchТак изменения Мэри будут доступны человеку, занимающемуся поддержкой проекта (или любым другим участникам, которым может понадобиться доступ к этим изменениям).
Мэри создает запрос pull
После добавления своей функциональной ветки в Bitbucket Мэри из своего аккаунта Bitbucket может создать пул-реквест, перейдя в свой репозиторий, созданный с помощью форка, и нажав на кнопку Pull request в верхнем правом углу. Отобразится форма, в которой репозиторий Мэри автоматически будет указан в качестве исходного. Мэри останется указать исходную ветку, а также репозиторий и ветку назначения.
Мэри хочет выполнить слияние функциональной ветки с основной базой кода. При этом исходной веткой будет ее функциональная ветка, целевым репозиторием — публичный репозиторий Джона, а целевой веткой — ветка main . Мэри потребуется ввести заголовок и описание запроса pull. Если кто-либо еще кроме Джона должен одобрить код Мэри, она может указать нужных людей в поле Reviewers (Проверяющие).
После создания запроса pull Джону будет отправлено уведомление через Bitbucket и (опционально) по электронной почте.
Джон просматривает запрос pull
Джон может увидеть все созданные другими разработчиками пул-реквесты, перейдя на вкладку Pull request в своем репозитории Bitbucket. Нажав на пул-реквест Мэри, он увидит описание пул-реквеста, историю коммитов функциональной ветки и все изменения в пул-реквесте.
Если Джон считает функционал готовым к слиянию с проектом, ему достаточно нажать кнопку Merge (Слияние), чтобы одобрить запрос pull и выполнить слияние функционала Мэри со своей веткой main .
Но для примера представим, что Джон нашел небольшой баг в коде Мэри и хочет, чтобы он был исправлен перед слиянием. Джон может либо опубликовать комментарий к запросу pull в целом, либо выбрать определенный коммит в истории функциональной ветки и прокомментировать его.
Мэри добавляет дополняющий коммит
Если у Мэри есть какие-либо вопросы по поводу отзыва Джона, она может ответить внутри запроса pull, используя его как форум для обсуждения функции.
Для исправления ошибки Мэри добавляет другой коммит в свою функциональную ветку и помещает этот коммит в свой репозиторий Bitbucket, как и в первый раз. Коммит автоматически добавится в исходный запрос pull, и Джон сможет снова просмотреть изменения прямо рядом с его исходным комментарием.
Джон принимает запрос pull
В конечном счете Джон принимает изменения, выполняет слияние функциональной ветки с главной и закрывает запрос pull. Функциональная ветка включена в проект. И теперь каждый разработчик проекта может скопировать изменения в свой локальный репозиторий, выполнив стандартную команду git pull .
Куда можно перейти отсюда
Теперь у вас есть все необходимые инструменты, чтобы начать использование пул-реквестов в текущем рабочем процессе. Помните, что пул-реквесты не заменяют процессы совместной работы в Git, а лишь дополняют их, облегчая взаимодействие всех членов команды.
Как работать с GitLab
Сегодня поговорим об азах взаимодействия с одной из самых популярных git-систем.
Что такое GitLab
Сейчас почти никто не пишет код в одиночку. Команды инженеров и разработчиков растут, как на дрожжах. Работая в группах, программисты используют системы управления исходным кодом на базе git, специального инструмента, позволяющего хранить данные разрабатываемого проекта в сети и совместно редактировать его с учетом определенных правил и методик взаимодействия. Самый известный подобный сервис – GitHub. А GitLab – это его собрат, выполняющий те же функции, но устроенный несколько иначе.
GitLab позволяет управлять репозиториями с кодом, отслеживать ошибки в разрабатываемых программах, публиковать код и тестировать его. Это незаменимый инструмент для каждого, кто программирует не в одиночку.
Комьюнити теперь в Телеграм
Подпишитесь и будьте в курсе последних IT-новостейРазница между GitLab и GitHub
Оба сервиса – системы управления репозиториями на базе git. Принципиальных отличий между ними нет. GitHub появился раньше и стал чуть ли не синонимом git, поэтому он популярнее и для многих является единственной системой для управления репозиториями.
Но GitLab есть что предложить с точки зрения функциональности, поэтому все чаще наблюдается переход пользователей с GitHub на GitLab. В частности, это касается разработчиков-новичков, которые пока еще не «приросли» к GitHub.
В связи с растущей популярностью GitLab я и решил познакомить вас с этим сервисом поближе.
Инструкция по использованию GitLab
Перед началом работы с сервисом, нужно создать учетную запись. Процедура эта весьма тривиальна:
- Заходим на официальный сайт GitLab.
- В верхнем левом углу находим кнопку Login и жмем по ней.
- Через пару секунд перед вам откроется форма входа в систему, а под ней будет ссылка на форму регистрации (Register now). Переходим по ней.
- Заполняем данные для регистрации (классические данные: адрес электронной почты, пароль, логин и т.п.). Жмем на кнопку Register.
- В течение пары минут на указанную при регистрации почту «упадет» сообщение со ссылкой для подтверждения создания аккаунта. Переходим по ней.
Учетная запись готова. Теперь можно переходить непосредственно к знакомству с GitLab.
Как создать проект
Проектом в GitLab считается глобальное рабочее пространство, в котором будет размещен репозиторий с файлами ваших сайтов и приложений. А также в нем можно взаимодействовать с коллегами и использовать другие возможности сервиса.
Поэтому при первом входе под своей учетной записью GitLab попросит вас указать род деятельности, наличие или отсутствие команды, имя рабочей группы и название проекта.
После формирования проекта можно переходить непосредственно к созданию репозиториев, загрузке программ в GitLab и т.п.
Как создать репозиторий
Чтобы воспользоваться репозиторием, нужно создать новый проект:
- Кликаем по иконке со значком + в панели управления.
- Выбираем пункт New project/repository.
- Затем кликаем по Create blank project.
- Указываем его имя и другие запрашиваемые параметры (можно указать, публичным будет репо или приватным) и нажимаем на кнопку Create Project.
Вместе с проектом сформируется новый git-репозиторий. Теперь можно с ним взаимодействовать, то есть загружать файлы, делать коммиты, создавать различные ветки для разработки продукта и мерджить их при необходимости.
Как загрузить файлы сайта/приложения в GitLab
Тут есть 3 пути.
Первый – используем веб-интерфейс GitLab
- На главной странице проекта ищем строку The repository for this project is empty, а под ней кнопку Upload File и нажимаем на нее.
- GitLab предложит выбрать файлы проекта для загрузки и последующей работы с ними. Выбираем все файлы, что используем при разработке и выгружаем.
Также можно использовать WebIDE, встроенную в GitLab, чтобы прямо в браузере писать код и создавать файлы для своего приложения/сайта.
Второй – используем командную строку
Тут все сложнее, но на самом GitLab опубликована короткая и доходчивая инструкция по подключению к сервису через командную строку, используя классический git-клиент.
Третий – используем сторонний git-клиент
Существуют приложения в духе Tower и Sublime Merge, позволяющие управлять репозиториями, делать коммиты и пушить изменения в проекты при помощи удобного графического интерфейса. Можно подключиться к GitLab с помощью одной из таких программ.
Как добавить SSH-ключ для подключения к репозиторию
SSH-ключи можно использовать для авторизации в GitLab и для управления репозиториями по протоколу Secure Shell. Чтобы это сделать:
- Генерируем ключ с помощью команды ssh-keygen (вводим ее в терминал).
- Генератор предложит сохранить получившийся ключ. Менять директорию, куда сохраняется ключ, необязательно.
- Затем утилита попросит ввести пароль. Его тоже можно не вводить. Просто жмем на Enter.
- В указанной на втором этапе папке появится файл с ключом в формате .pub. В нем лежит ключ. Нужно скопировать его.
- Возвращаемся на сайте GitLab. Открываем раздел SSH-keys, вставляем ключ в специально отведенное для этого поле и нажимаем на кнопку Add key.
Как работать с ветками
Ветки – это инструмент для создания дополнительных вариаций приложения/сайта, которые позволяют вести разработку новых функций, не затрагивая при этом основное приложение, доступное для пользователей.
По умолчанию в GitLab доступна только одна ветка – master. Но ее чаще используют не для разработки, а для публикации готовых сборок проекта, которые нестрашно превратить в релиз для масс.
Поэтому принято создавать новые ветки для разработки дополнительных функций, а уже потом объединять их с основной.
Как создавать ветки
Ветки – не уникальная для GitLab функция. Это часть git, поэтому, как и в случае с репозиториями, тут можно пойти тремя путями:
- На сайте GitLab в окне управления репозиторием нажать на кнопку + справа от названия ветки, а потом выбрать пункт New branch в выпадающем меню.
- Можно создать новую ветку через git-клиент в терминале с помощью команды git checkout -b [название новой ветки].
- Или воспользоваться аналогичной функций в используем графическом git-клиенте (Tower, Sublime Merge, GitFox и т.п.).
Любой из способов позволит создавать новую ветку, в которую после этого можно будет отправлять коммиты и делать пуши.
Мерджинг веток
Мерджинг (или объединение) веток – это механизм слияния двух наборов функций одной программы, позволяющий переносить функции из дополнительных веток в основную ветку разработки, где лежит приложение. Результат увидят еще и пользователи, а не только разработчики.
Запрос на объединение веток будет появляться на сайте GitLab каждый раз, когда вы будете вносить изменения в код одной или нескольких веток.
Выглядит это следующим образом:
- На сайте появляется большая синяя кнопка Create merge request. Кликаем по ней.
- Затем рассказываем о своем запросе (поясняем, для чего он делается).
- Указываем автор запроса в поле Assignee.
- Указываем человека, который будет проверять запрос в поле Reviewer.
- Потом указываем Milestone (если используете их).
- Ставим теги.
- И нажимаем на Create merge request.
- Если с запросом все ок, то проверяющий нажмет на кнопку Merge, и весь код перекочует в основную ветку проекта (ну или ту, которую указал автор запроса).
Как добавлять пользователей в проект
К разработке своего приложения/сайта всегда можно привлечь людей со стороны:
- Для этого кликаем по кнопке Project information в боковой панели GitLab.
- Выбираем пункт Members.
- В графу GitLab member or Email address вписываем ник GitLab-пользователя или его email-адрес.
- Выбираем для него роль (гость, наблюдатель, разработчик).
- Также указываем время действия приглашения (в указанный день приглашенный будет исключен из проекта).
- А потом кликаем на Invite.
Если выбранный человек согласится присоединиться, то ваша команда расширится.
Как создавать баг-репорты
В git-системах есть инструменты, помогающие оповещать разработчиков об ошибках и обсуждать их как с пользователями, так и с коллегами.
Речь идет о разделе Issues. Если возникла проблема, то нужно сообщить о ней тут. Для этого:
- Открываем раздел Issues в боковой панели управления.
- Затем нажимаем на кнопку New issue.
- Даем имя обнаруженной проблеме, а затем подробно описываем ее в разделе Description.
- Затем назначаем ответственного в пункте Assignee и срок, в течение которого нужно найти решение найденной проблемы.
- А потом нажимаем на кнопку Create issue.
Как удалить проект
- Открываем настройки проекта и переходим во вкладку General.
- Листаем ее до пункта Advanced и справа от него ищем кнопку Expand, которая откроет доступ к дополнительным параметрам.
- Вновь пролистываем появившееся меню до упора вниз, пока не наткнемся на кнопку Delete project.
- Нажимаем на нее и вписываем название проекта, чтобы его удалить.
Вместо заключения
На этом все. Я рассмотрел базовые возможности GitLab и намеренно не затрагивал аналитические инструменты, интеграцию с Kubernetes и дополнительные функции, пытаясь сконцентрироваться на важнейших концептах GitLab и git. Это то, что вам необходимо для старта, независимо от того, пользовались вы ранее другими системами управлениями репозиториями или нет.