какие модели предлагает github для pull request оф
Практическое занятие «Процесс Pull request на GitHub»
На предыдущем занятии Используем клиент GitHub для десктопа, мы использовали Github Desktop для управления рабочим процессом коммитов, ветвления и слияния. На этом занятии мы будем выполнять аналогичные действия, но с использованием браузерного интерфейса, который предоставляет Github, вместо использования терминала или Github Desktop.
Понимание процесса Pull request является важным для анализа изменений в опен-сорс проекте с несколькими участниками. Использование интерфейса GitHub также удобно, если рецензенты не знакомы с терминалом или Github Desktop.
Создание изменение в отдельной ветке
По умолчанию в новом репозитории есть одна ветка с именем «Master». Обычно, когда при внесении изменений или просмотра / редактировании, создается новая ветка и вносятся все изменения в ветку. Затем, по окончании, владелец репо объединяет изменения из новой ветки в «Master» через «pull request».
Для создания изменений в отдельной ветке:
При создании новой ветки, содержимое из главной (или любой другой ветки, которая сейчас просматривается) копируется в новую ветку. Процесс похож на «Сохранить как» с существующим документом.
Рецензенты могут продолжать вносить изменения таким образом, пока не закончат просмотр всей документации. Все изменения делаются в этой новой ветке, а не в мастере.
Создание Pull request
Для создания Pull request:
Когда мы сравниваем ветку с мастером, мы увидим список всех изменений. Мы можем просмотреть изменения в двух режимах просмотра: Unified или Split (это вкладки, показанные справа от содержимого). Unified показывает правки вместе в одной области содержимого, тогда как split показывает два файла рядом.
Владелец репозитория увидит pull request и сможет принять меры для его объединения.
Процесс Pull request
Теперь посмотрим на процесс со стороны владельцем проекта, который получил новый Pull request. Владельцу нужно обработать Pull request и объединить ветку sme-review с “Master”.
Также стоит обратить внимание, что если запрос на извлечение выполняется для более старой версии мастера, где исходное содержимое мастера больше не существует или перемещено в другое место, процесс слияния будет более трудным для выполнения.
Ветка sme-review объединяется с мастером. Теперь “Master” и ветка sme-review совпадают (ветки “смержены”).
Если посмотреть на список веток, то после удаления ветка sme-review больше не отображается.
Добавление участников в проект
Иногда необходимо добавлять соавторов в проект Github, чтобы они могли вносить изменения в ветку. Если другие участники проекта, не являясь соавторами, захотят внести изменения, они получат сообщение об ошибке. (Inviting collaborators to a personal repository)
Человек без прав на запись, может “форкнуть” (скопировать) репо, а не вносить изменения в ветку в том же проекте. Однако копирование проекта клонирует весь репозиторий, а не создает ветку в том же репозитории. Форк (копия) будет существовать в учетной записи пользователя GitHub. Можно объединить форкнутый репозиторий (это типичная модель для опен-сорс проектов со многими внешними участниками), но этот сценарий, вероятно, менее распространен для технических писателей, работающих с разработчиками в тех же проектах.
Для добавления соавторов в проект:
Совместная разработка в команде на GitHub
GitHub стал краеугольным камнем для всего программного обеспечения с открытым исходным кодом. Разработчики любят его, сотрудничают с ним и постоянно создают новые великолепные проекты с помощью него. Помимо хостинга вашего кода, главная привлекательность GitHub заключается в использовании его в качестве инструмента совместной работы. В этом уроке давайте рассмотрим некоторые из наиболее полезных функций GitHub, особенно полезных для работы в командах, что делает его еще более эффективным, продуктивным и, самое главное, забавным!
Github разработка в команде
В этом руководстве предполагается, что вы уже знакомы с Git, распределенной системой управления версиями с открытым исходным кодом, созданной Линусом Торвальдсом в 2005 году. Если вам нужна ревизия или поиск в Git, посетите наш предыдущий курс скринкастов или даже несколько статей на эту тему. Кроме того, у вас уже должна быть учетная запись Github, а также некоторые базовые функции, такие как создание репозитория и внесение изменений в Github. Если нет, обратитесь к предыдущим учебникам.
В мире разработки при создании своего проекта работа в команде будет неизбежной. В этом руководстве по совместной разработке на Github мы изучим некоторые из наиболее распространенных инструментов, которые нам обычно нужны при работе с командами разработчиков программного обеспечения. Обсуждаемые инструменты:
Предпочитаете скринкаст?
Если вы предпочитаете скринкаст, то прыгайте чуть ниже, чтобы просмотреть его, а этот учебник используйте в качестве сопутствующих заметок:
Инструмент 1 : Добавление членов команды
Как правило, существует два способа настройки Github для совместной работы:
Organizations
Если вы контролируете несколько команд и хотите установить разные уровни доступа для каждой команды с различными членами и добавить каждого участника в разные репозитории, то организация будет для вас наилучшим вариантом. Любая учетная запись пользователя Github уже может создавать бесплатные организации для репозиториев с открытым исходным кодом. Чтобы создать организацию, просто перейдите на страницу настроек своей организации:
Соавторы
Коллабораторы (соавторы) используются для предоставления возможности «читать + писать» в один репозиторий, принадлежащий личной учетной записи. Чтобы добавить Collaborators (другие личные учетные записи Github), перейдите на страницу https://github.com/[username]/[repo-name]/settings/collaboration :
Инструмент 2: Pull Requests
Давайте теперь рассмотрим основные шаги для pull request.
Инициирование pull request
В Github есть две модели для pull request:
Здесь мы видим рабочий процесс между двумя пользователями ( repo-owner и forked-repo-owner ) для модели Fork and Pull:
Слияние пул реквеста
Если вы являетесь владельцем оригинального репозитория, существует два способа слияния входящего пул реквеста:
Существуют различные модели создания веток, используемые для управления версиями в командах разработки программного обеспечения. Вот две популярные модели рабочего процесса git: (1) рабочий процесс Github, который имеет простую ветвящуюся модель и использует запросы на pull, и (2) Gitflow, который имеет более обширное разветвление. Модель, которая в конечном итоге будет выбрана, определенно будет меняться в зависимости от команды, проекта и ситуации.
Инструмент 3: Отслеживание ошибок
Давайте рассмотрим некоторые особенности проблем:
Инструмент 4: Аналитика
Понятно, что мы можем тесно связать наш список задач и обновления с нашими кодами.
Графики
Графики предоставляют подробную аналитику, такую как:
Network
Инструмент 5: Управление проектами
Github и Trello
Trello обеспечивает простой, визуальный способ управления задачами. Используя Agile Software Development, карточки Trello могут эмулировать простую виртуальную Kanban Board. В качестве примера мы автоматически создадим карточку Trello всякий раз, когда будет появляться новый пул реквест с помощью Github Service Hooks. Давайте пройдем через все шаги!
Github и Pivotal Tracker
С примерами Trello и Pivotal Tracker ясно, что мы можем тесно связать наш список задач и обновления с нашими коммитами. Это огромная экономия времени при работе в команде, и это повышает точность при связывании задач с точными фиксациями. Хорошей новостью является то, что если вы уже используете другие инструменты управления проектами, такие как Asana, Basecamp и другие, вы также можете создать Service Hooks аналогичным образом. Если для вашего текущего инструмента управления проектами нет существующих сервисных хуков, вы даже можете их создать сами!
Инструмент 6: Непрерывная интеграция
Непрерывная интеграция (CI) является важной частью всех проектов разработки программного обеспечения, с которыми работают команды разработчиков. CI гарантирует, что, когда разработчик выкатывает свой код, автоматическая сборка (включая тесты) быстро обнаруживает ошибки интеграции. Это определенно уменьшает ошибки интеграции и делает быструю итерацию намного более эффективной. В этом примере мы увидим, как можно использовать Travis CI вместе с Github для CI для обнаружения ошибок, а также для рекомендаций слияния, когда проходят все тесты.
Настройка Travis CI
Мы будем использовать простой проект «hello world» для node.js вместе с grunt.js в качестве инструмента сборки для настройки Travis CI проекта. Вот файлы, находящиеся в проекте:
Travis CI и пул реквесты
Раньше, без какого-либо CI в процессе пул реквеста, этапы выполнялись примерно так: 1) создание запроса (2) слияние (3), тестируем все ли работает. Когда Travis CI подключится к пул реквесам, мы сможем инвертировать шаги 2 и 3, что еще больше ускорит принятие решений о том, следует ли сливать изменения, так как Travis даст нам статус билда для каждого пул реквеста. Давайте посмотрим, как это сделать.
Travis CI с Github чрезвычайно полезен для команд из-за автоматических сборок и немедленного уведомления. Это, безусловно, делает цикл исправления ошибок намного короче. Если вы используете Jenkins, еще один популярный инструмент CI, то вы тоже можете настроить сервисные хуки Github.
Инструмент 7: Обзор кода
С каждой фиксацией изменений Github позволяет использовать чистый интерфейс для общих комментариев или даже конкретных комментариев к отдельной строчке кода. Возможность делать комментарии или задавать вопросы по каждой отдельной строке кода очень полезна при проведении обзоров строка за строкой. Чтобы просмотреть встроенные комментарии, установите флажок в верхней части каждой фиксации.
Давайте рассмотрим некоторые шаблоны URL-адресов, которые могут быть использованы, чтобы помочь нам в обзоре кода, быстро предоставив нам различия между фиксациями:
Инструмент 8 : документация
В этом разделе мы рассмотрим два метода создания документации:
Github Wiki
В каждом репозитории может быть создана Github Wiki, и это может оказаться очень удобно иметь в одном репозитории как исходный код, так и документацию для него. Чтобы создать Wiki, просто перейдите на вкладку Wiki в главном заголовке, и вы готовы к созданию страниц с информацией. Сама Wiki имеет собственное управление версиями, и данные могут быть клонированы на наш локальный компьютер для обновлений или даже автономного доступа.
Затем добавьте wiki-подмодуль git в основной репозиторий кода:
Теперь Wiki будет выглядеть как подмодуль в основном проекте с исходным кодом.
Github Hubot
Если коротко, Hubot может сделать процесс ведения документации гораздо приятнее, добавляя уведомление командных обсуждений о важных коммитах.
Итак давайте начнем с настройки Hubot, размещенным на Heroku, и ботом с интерфейсом чата Campfire! Для обоих и Heroku и Campfire есть бесплатные версии, с которым можно начать.
Ознакомьтесь с другими скриптами Hubot, связанными с Github, или если вы хотите написать один, есть крутой учебник по этому поводу! Короче говоря, Hubot может значительно добавить веселья в документировании и уведомлении командных дискуссий о важных коммитах, проблемах и действиях, происходящих с нашими репозиториями на Github. Попробуйте его!
В качестве заключительной заметки о командной работе на Github, вот несколько советов по производительности:
Использование Github не для разработки
Большинство думает использовать Github только для программных проектов. В конце концов, Github был создан специально для создания кода. Но есть некоторые классные репозитории Github, которые используются для проектов, не связанных с кодом, и они были одинаково великолепны для сотрудничества и обсуждения. Поскольку эти проекты также доступны с открытым исходным кодом, и каждый может внести свой вклад, быстро исправлять ошибки, легко сообщать об ошибках и эффективно сотрудничать с единомышленниками. Просто ради интереса, вот некоторые из них:
И интересно, что думает об этом команда Github?
«Мы кайфуем от использования GitHub»
Дополнительные ресурсы
Получайте больше удовольствия от совместной работы!
Таким образом, это был набор инструментов для совместной работы в Github. Большинство из них служат быстрыми аналитическими инструментами или даже автоматизацией, что помогает сэкономить время при работе с двумя или несколькими товарищами по команде. У вас есть больше советов Github для команд? Давайте поделимся ниже!