Практическое занятие «процесс pull request на github»

How it works

Pull requests can be used in conjunction with the Feature Branch Workflow, the Gitflow Workflow, or the Forking Workflow. But a pull request requires either two distinct branches or two distinct repositories, so they will not work with the Centralized Workflow. Using pull requests with each of these workflows is slightly different, but the general process is as follows:

1. A developer creates the feature in a dedicated branch in their local repo.

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.

The rest of this section describes how pull requests can be leveraged against different collaboration workflows.

Feature Branch Workflow With Pull Requests

The Feature Branch Workflow uses a shared Bitbucket repository for managing collaboration, and developers create features in isolated branches. But, instead of immediately merging them into , developers should open a pull request to initiate a discussion around the feature before it gets integrated into the main codebase.

There is only one public repository in the Feature Branch Workflow, so the pull request’s destination repository and the source repository will always be the same. Typically, the developer will specify their feature branch as the source branch and the branch as the destination branch.

After receiving the pull request, the project maintainer has to decide what to do. If the feature is ready to go, they can simply merge it into and close the pull request. But, if there are problems with the proposed changes, they can post feedback in the pull request. Follow-up commits will show up right next to the relevant comments.

It’s also possible to file a pull request for a feature that is incomplete. For example, if a developer is having trouble implementing a particular requirement, they can file a pull request containing their work-in-progress. Other developers can then provide suggestions inside of the pull request, or even fix the problem themselves with additional commits.

Gitflow Workflow With Pull Requests

The Gitflow Workflow is similar to the Feature Branch Workflow, but defines a strict branching model designed around the project release. Adding pull requests to the Gitflow Workflow gives developers a convenient place to talk about a release branch or a maintenance branch while they’re working on it.

The mechanics of pull requests in the Gitflow Workflow are the exact same as the previous section: a developer simply files a pull request when a feature, release, or hotfix branch needs to be reviewed, and the rest of the team will be notified via Bitbucket.

Features are generally merged into the branch, while release and hotfix branches are merged into both and . Pull requests can be used to formally manage all of these merges.

Forking Workflow With Pull Requests

In the Forking Workflow, a developer pushes a completed feature to their own public repository instead of a shared one. After that, they file a pull request to let the project maintainer know that it’s ready for review.

The notification aspect of pull requests is particularly useful in this workflow because the project maintainer has no way of knowing when another developer has added commits to their Bitbucket repository.

Since each developer has their own public repository, the pull request’s source repository will differ from its destination repository. The source repository is the developer’s public repository and the source branch is the one that contains the proposed changes. If the developer is trying to merge the feature into the main codebase, then the destination repository is the official project and the destination branch is .

Pull requests can also be used to collaborate with other developers outside of the official project. For example, if a developer was working on a feature with a teammate, they could file a pull request using the teammate’s Bitbucket repository for the destination instead of the official project. They would then use the same feature branch for the source and destination branches.

The two developers could discuss and develop the feature inside of the pull request. When they’re done, one of them would file another pull request asking to merge the feature into the official master branch. This kind of flexibility makes pull requests very powerful collaboration tool in the Forking workflow.

Завершение работы

После вливания PR нужно прибраться в репозитории. Если ваши изменения
самодостаточны и после PR не требуется продолжать работу дальше,стоит удалить
ветку. Как вы помните,мы создали её раньше,чтобы удобнее управлять
изменениями.

Но сначала лучше обновить вашу локальную master-ветку — тогда убедится,
что ваша ветка уже влита в , и не будет предупреждать,что вы можете
потерять свои изменения.

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

1

git remote add upstream https://github.com/ruRust/rustycrate.ru.git

URL в конце — это URL того репозитория,который вы форкнули.(На всякий случай —
он написан в небольшом поле справа от переключателяHTTPS-SSH», правее зелёной
кнопкиNew pull request».)

Добавив его,можно обновить наш локальный :

1
2

git checkout master
git pull --rebase upstream/master

А теперь можно удалить нашу ветку локально:

1

git branch -d fix-protobaz

и на сервере:

1

git push --delete origin fix-protobaz

Теперь у нас чистый,обновлённый репозиторий. Можно начинать работу над новым
PR.

Если у вас что-то не получилось сделать,или непонятно написано —
пишите об этом в чате или
создавайте задачи в нашем
репозитории.

Если в какой-то момент возникают ошибки — сделайте . Очень
часто сам подсказывает,что можно сделать и как это сделать.
Если всё равно не получилось — обращайтесь в чат,поможем.

После этой публикации остаются неотвеченные вопросы: как поступать,если
случайно закоммитил не в ту ветку; что делать,если кажется,что потерял
ваши изменения; как работать с сервисом code review ; как
рецензировать чужие изменения и,возможно,другие.

С этими вопросами можно обращаться в чат,а в будущем мы постараемся написать
руководства и по этим темам.

Хороших вам коммитов,пусть проект собирается и тесты проходят.
Присылайте ваши Pull
Request’ы!

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

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

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

Форк проекта

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

К примеру, репозиторий проекта node-chakracore принадлежит nodejs, значит, ссылка GitHub будет выглядеть так:

где nodejs – имя пользователя, node-chakracore – имя репозитория.

Выберите проект, в котором вы хотите принять участие, и откройте его репозиторий на GitHub.

На главной странице проекта вы увидите кнопку Fork под вашим значком пользователя.

Чтобы начать форк репозитория, нажмите кнопку Fork. В окне браузера появится следующее сообщение:

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

Теперь можно клонировать репозиторий и получить локальную копию кода.

Клонирование репозитория

Чтобы создать локальную копию кода проекта, откройте терминальное окно. Используйте команду git clone и укажите ссылку на форк репозитория.

Эта ссылка почти такая же, как и предыдущая, и отличается только тем, что заканчивается расширением .git, например:

Скопировать эту ссылку можно с помощью зелёной кнопки Clone or download на странице репозитория. Справа от ссылки появится кнопка, с помощью которой можно скопировать ссылку.

Теперь можно добавить скопированный URL в команду git clone:

Пример

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

В данном примере Мэри — разработчик, а Джон — человек, занимающийся поддержкой проекта. У обоих есть собственные публичные репозитории Bitbucket, и в репозитории Джона находится официальный проект.

Мэри создает форк официального проекта

Чтобы начать работу над проектом, Мэри сначала должна создать форк репозитория Джона в Bitbucket. Для этого ей нужно войти в Bitbucket, перейти к репозиторию Джона и нажать кнопку Fork (Создать форк).

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

Мэри клонирует свой репозиторий Bitbucket

Затем Мэри должна клонировать репозиторий Bitbucket, который она только что создала с помощью форка. Так она получит собственную рабочую копию проекта на своей локальной машине. Она может сделать это с помощью следующей команды:

Помните, что команда автоматически создает удаленный репозиторий , который указывает на репозиторий Мэри, созданный с помощью форка.

Мэри разрабатывает новый функционал

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

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

Мэри помещает функциональную ветку в свой репозиторий Bitbucket

Закончив работу, Мэри помещает функциональную ветку в свой репозиторий Bitbucket (а не в официальный репозиторий проекта) с помощью простой команды :

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

Мэри создает запрос pull

После добавления функциональной ветки в Bitbucket Мэри из своего аккаунта Bitbucket может создать запрос pull. Для этого ей нужно перейти в свой репозиторий, созданный с помощью форка, и нажать кнопку Pull request (Запрос pull) в верхнем правом углу. Отобразится форма, в которой репозиторий Мэри автоматически будет указан в качестве исходного. Мэри останется указать исходную ветку, а также репозиторий и ветку назначения.

Мэри хочет выполнить слияние функциональной ветки с основной базой кода, поэтому исходная ветка — ее функциональная ветка, репозиторий назначения — публичный репозиторий Джона, а ветка назначения — . Мэри потребуется ввести заголовок и описание запроса pull. Если код Мэри должен одобрить кто-то помимо Джона, таких участников можно указать в поле Reviewers (Проверяющие).

После создания запроса pull Джону будет отправлено уведомление через Bitbucket и (опционально) по электронной почте.

Джон просматривает запрос pull

Джон может увидеть все созданные другими разработчиками запросы pull, перейдя на вкладку Pull request (Запрос pull) в своем репозитории Bitbucket. Нажав на запрос pull Мэри, он увидит его описание, историю коммитов функциональной ветки и все изменения в запросе pull.

Если Джон считает функцию готовой к слиянию, ему достаточно нажать кнопку Merge (Слить), чтобы одобрить запрос pull и выполнить слияние функциональной ветки Мэри со своей веткой .

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

Мэри добавляет дополняющий коммит

Если у Мэри есть какие-либо вопросы по поводу отзыва Джона, она может ответить внутри запроса pull, используя его как форум для обсуждения функции.

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

Джон принимает запрос pull

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

Создание issues из TODO-комментариев

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

Интеграция TODO
to Issue помогает нам решать проблему
забытых TODO. Каждый раз, когда вы отправляете
в репозиторий код с такими комментариями,
они превращаются в GitHub issue.

При работе с TODO to Issue вы создаете
конфигурационный файл, где задаете
набор символов, которые используются
для отслеживаемых комментариев. Работает
с любыми языками.

Практическое применение

У нас принят довольно консервативный подход к принятию изменений в интеграционную ветку. Мы стараемся по максимуму протестировать изменение ещё на ветке фичи.

Вот некоторые задачи, которые мы решаем с помощью статусов PR, в рамках настраиваемых политик:

1. Все PRы должены быть оформлены в едином стиле. Поэтому первый контроль который был создан — оформление заголовка PR. Мы проверяем его на соответствие регулярному выражению.
2. Ветка PR не должена отставать от ветки куда ее вливают (проведена интеграция).
3. Если в рамках PR изменяются файлы проекта БД, то также должны присутствовать файлы автотестов.
4. Существует успешная сборка ветки по последнему изменению.
5. Такая сборка успешно выкачена на тестовый стенд и автотесты прошли.

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

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

Создаём Pull Request

Когда работа и проверка закончены,пора создавать Pull Request. Pull Request —
это запрос на вливание изменений из вашей ветки в основную ветку исходного
репозитория. Таким образом они попадут к хозяевам проекта.

Чтобы создать Pull Request, зайдём на страницу вашего форка. Справа от
выпадающего меню с выбором ветки есть кнопкаNew pull request».

Нажимаем её.

Вы попадаете в окно сравнения веток.

Вот элементы этого окна,по порядку:

1. Базовый репозиторий,в который будет создаваться PR. Это должен быть
   репозиторий,от которого вы делали форк. Если вы форкнули проект
   , а ваше имя пользователя GitHub — , то у вас
   будет проект .
2. Базовая ветка в этом репозитории,обычно .
3. Репозиторий,откуда должны вливаться изменения. Здесь должен быть выбран
   репозиторий в вашем аккаунте — .
4. Ветка,откуда будут вливаться изменения. Это должна быть ветка,которую мы
   создали в разделеСоздаём ветку».

Дальше просмотрите изменения — то ли это,что вы делали? Если да,то нажимайте
кнопкуCreate pull request». В моём примере её нет,т. к. ветки в форке и в
оригинале находятся в одинаковом состоянии. В вашем же случае внизу будет список
коммитов,которые попадут в исходный репозиторий,и,на других вкладках — сами
изменения и комментарии к изменениям.

После нажатия кнопки появится окно ввода сообщения Pull Request.

Сообщение PR — это описание того,что сделано и зачем. В отличие от сообщения
коммита,здесь уже нужно писать высокоуровневое описание того,какие изменения
сделаны. В частизачем», а также по формату самого сообщения — стоит
придерживаться тех же правил,что и в случае с коммитами. Короткий заголовок
(Title), в Comment — описание,а затем служебная информация().
Если вы писали команды закрытия задач в коммитах,здесь можно их не дублировать.
Если нет — напишите здесь.

Затем нажимаемCreate pull request». Он создаётся,о нём приходит уведомление
людям,поддерживающим проект,и он становится виден в исходном репозитории на
вкладкеPull requests». С этого момента начинается рецензирование изменений
(code review).

Подсказка: если сразу после того,как вы отправили ветку в свой репозиторий
() зайти на страницу репозитория,там будет предложение создать
Pull Request на вливание недавно отправленной ветки в master. Сделать это можно
как в вашем форке,так и в исходном репозитории. Это будет отдельная кнопка
вверху,и при её нажатии в качестве ветки для слияния будет указана та,куда вы
делали .

Автоматизация

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

HTML/CSS to Image

Вам нужен скриншот вашего сайта?
Интеграция с HTML/CSS
to Image позволит вам получать изображение
того, как ваш сайт будет выглядеть в
Google Chrome.

Mergify

Вам нужно реагировать на пул-реквесты?
Возможно, стоит автоматизировать мержинг
PR, соответствующих определенным
критериям? Вам поможет Mergify.
Это приложение позволит вам избавиться
от рутинной работы с пул-реквестами.
Если ваш проект активен и вам приходится
иметь дело с пул-реквестами ежедневно,
подумайте о возможности добавить
интеграцию вроде этой.

Сборка GitHub Pull Requests

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

С связке с Commit Status Publisher (который тоже входит в базовую поставку TeamCity) можно настроить ваш CI-сервер автоматически собирать пул-реквесты от, скажем, внешних авторов и публиковать статус билда обратно в GitHub. Получается красивая история: смотрите ее в действии в этом видео от antonarhipov:

Расширяемые статусы Pull Request

Статусы PR это флаги, определенные в рамках контекста (context). Контекст — уникальное сочетание имени (name) контекста и «жанра» (genre). Жанр, как правило, один на приложение, манипулирующий статусом.

Например:

Статус 1: genre = ‘my-policy’, name = ‘check-1’
Статус 2: genre = ‘my-policy’, name = ‘check-2’

Статус принимает одно из предустановленных значений. Для целей поддержки процесса нас будут интересовать два: succeeded и failed.

Статусы можно использовать при настройке политики бранча: выбранные флаги должны иметь статус succeeded, для того чтобы PR был принят. Ровно так же реализованны встроенные политики, проверяющие количество аппруверов, наличие прикреплённого тикета, итд.

Переходим в редактирование политики ветки. Добавляем внешнюю политику.

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

Добавленные статусы будут видны на странице пулл-реквеста в блоке проверок:
Если статус не используется в качестве политики — его значение выводится на странице в разделе Status. Если статус указан в качестве политики — он будет виден в верхней части блока.

Как улучшить процедуру подачи и одобрения пул-реквестов

Используйте инструменты
статического анализа

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

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

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

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

Я не хочу сказать, что не следует
отмечать стилистические несоответствия
в PR. Просто если какие-то замечания
встречаются слишком часто, подумайте
об использовании линтера: это позволит
заметить проблемные места до отправки
пул-реквеста. Если робот может сделать
что-то з вас (и даже лучше вас), зачем же
делать это самому? Кроме того, когда на
проблемы указывает робот, это не обидно.

Сделайте список вещей,
обязательных для одобрения PR

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

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

Например, если важны тесты, введите
правило, что исправление бага требует
нового теста или исправления существующего.

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

Как можно раньше прекращайте
длинные треды дискуссий

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

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

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

Геймифицируйте процесс

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

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

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

Добавление участников в проект

Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)

Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.

Для добавления соавторов в проект:

• В репозитории проекта переходи на вкладку “Settings”.
• Нажимаем на кнопку в левой части.
• Вводим имена пользователей Github тех, кому хотим дать доступ в области Collaborator.
• Нажимаем на кнопку .

Создаём ветку

Ветка
по умолчанию — . Чтобы изменениями было проще управлять и они не
смешивались друг с другом,создадим отдельную ветку,где и будем работать. При
этом ветку стоит назвать так,чтобы имя говорило о её назначении.

Например,мы хотим исправить ошибку в реализации протокола , так что
наша ветка будет называться .

Теперь заходим в наш склонированный репозиторий и
создаём ветку:

1
2

cd foobar
git checkout -b fix-protobaz

Вторая команда создаст ветку и перейдёт на неё(сделает checkout).

Если после этого выполнить , он покажет

1
2

On branch fix-protobaz
nothing to commit, working directory clean

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

Техническая реализация выполнения политик

На данный момент логика политик реализована в виде скриптов powershell. За счёт высокоуровневых командлетов и хорошей объектной модели данных, код скрипта получается очень компактным. А возможность запускать скрипт по шагам интерактивно и ковыряться в переменных — существенно упрощает процесс разработки и отладки.

Кстати, после выпуска powershell core — скрипты можно выполнять и на других платформах (проверял на MacOS).

Запускаем скрипты в специальном релизе VSTS по расписанию примерно раз в пару часов. Может быть начнем запускать через шедулер почаще.

Такой подход, конечно, дает существенно более медленную реакцию, чем если реализовать то же самое в виде Azure Function и связать ее с VSTS через web hook. Но для нас было важнее реализовать проверки и посмотреть как это будет работать в процессе (MVP). Оперативность выполнения проверок пока не важна. Это будет на следующем этапе.

Реализация библиотек работы с VSTS REST API, которые использованы в проверках, плюс небольшой пример, реализующий некоторые из указанных политик можно посмотреть в репозитории на GitHub. Надеюсь, кому-нибудь окажется полезным.

Боты

Bit.dev (BitDevBot)

Bit.dev это популярный
облачный хаб компонентов. Это место,
где вы можете публиковать, документировать
и упорядочивать JS-компоненты (React,
Angular, Vue и т. д.).

Когда вы пользуетесь Bit, вы можете
публиковать отдельные компоненты из
любой кодовой базы (репозитория). То
есть, это инструмент не только для
проектирования систем, но и для совместной
работы над компонентами.

Недавно Bit выпустил новый BitDevBot —
GitHub-бот, автоматизирующий пул-реквесты
в репозитории с импортированными
компонентами. Таким образом, при
обновлении какого-либо компонента все
релевантные репозитории получают
предложение влить новые изменения.

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

Slack

Еще одна платформа, подходящая для
такого рода интеграций, это Slack. Многие
компании используют чат-румы, чтобы
сотрудники могли общаться и делиться
информацией (для каждой «комнаты»
отводится отдельная тема).

Разработчики GitHub поняли, что интеграция
со Slack позволит пользователям
просматривать детали ссылок на
репозитории, подписываться на репозиторий
путем введения простой команды или
управлять issues, как если бы они просто
общались с коллегой.

Что такое ветки?

Чаще всего ветки (branch — ответвление, ветвь, филиал) бывают
тематическими. Например, при общей разработке, когда у всех участников
есть право записи в репозиторий. В этом случае ветки используются для
отделения изменений, сделанных одним из разработчиков, от общего репозитория.
Ветки могут пригодиться и в случае с созданием pull-request’а.

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

Новые ветки создаются не только из master, берите любую!

Находясь в только что созданной ветке, вы можете приступить к работе.
Вносите в код свои изменения, а когда закончите просто переключитесь
обратно к своей основной ветке. Вы можете отправить pull request,
выбрав ветку или же прежде слить изменения из неё в
основную ветку разработки. Рассмотрим это подробнее:

Если нужно отправить в свой удалённый репозиторий вновь созданную
ветку (не сливать её с master), делаем следующее:

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

Удалить все локальные ветки, которые были смержены (то есть код которых теперь есть)
в ветках develop или master:

С чего начать?

А для начала этот самый репозиторий нужно форкнуть (fork — вилка, ответвление).
Разберём это нехитрое действо на примере веб-сервиса для хостинга IT-проектов,
название которому GitHub. Разумеется, кроме GitHub есть и другие: BitBucket,
например. Выбирать по вкусу.

Примечание

Для успешного проведения нижеизложенных операций у вас (что естественно) должен быть установлен git

Заходим на страницу интересующего проекта, жмём кнопку , ищем
на своей странице URL для клонирования.

В консоли в зависимости от входных данных набираем нечто подобное:

Отлично. Уже можно вносить свои изменения в код проекта.

Тот репозиторий, что теперь лежит на вашем жёстком диске, независим от
основного. В нём отслеживаются только ваши наработки. Но как следить за
изменениями, происходящими в первоисточнике, откуда вы «стянули»
репозиторий? Добавить удаленный репозиторий в отслеживаемые. Например, так:

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

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

У нас есть основной репозиторий с веткой и недавно добавленный нами
— с . Команда, данная выше, забирает всё новое из ветки
и сливает изменения в . Так, мы всегда можем получить последние наработки.

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

Допустим, мы написали, что хотели и сделали коммит. Забираем изменения (но не сливаем их, fetch) из .
Затем вручную сливаем изменения из удалённой ветки к себе (merge),
разрешаем конфликты (если есть) и снова делаем коммит.

Если репозиторий огромен, а забирать его весь не хочется, клонируем только нужную ветку:

Отправляем изменения

Добрались таки до ответа на поставленный вопрос: что такое pull request,
зачем оно нужно и как его достичь. Как предложить владельцу репозитория свои изменения?

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

Перед тем как сделать запрос вы имеете возможность добавить комментарий,
просмотреть то, какие файлы будут изменены, какие коммиты добавлены.
В верхнем углу окна добавления запроса обратите внимание откуда куда и что
вы сливаете. Если необходимо слить основные ветки выбор падёт на репозиторий
, если отдельную ветку (вспоминаем branch) — так и указывайте её

А дальше… ждать. Пока придёт владелец оригинального репозитория и
примет/отклонит ваши изменения.

Ну вот, мы его достигли. Просветления то есть 🙂