GIT Pull-запросы с использованием GitHub

Старые привычки

Мы работаем с Git больше года. СКМ был перенесен из SVN со всей своей историей. Наши привычки также были перенесены. Наш процесс (был) довольно прост: основная ветвь — это то место, где мы развертываем наш код. При работе с функцией мы создаем ветку элемента. Несколько человек могут работать в этой отрасли. Некоторые создают частные локальные филиалы. Некоторые нет. Проверка кода выполняется один на один. Один участник просит другого присоединиться и прогуливается по коду.

Представляем запрос на извлечение команды

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

Выгоды

1. Лучшее сотрудничество
   Когда человек вносит изменения и вызывает запрос на извлечение изменений, вся команда может видеть это изменение. Каждый может комментировать и давать замечания. Обсудите изменения, прежде чем они будут объединены с основной веткой.
2. Код собственности
   Все знают об изменениях, и каждый может проверить и прокомментировать. В результате каждый может «владеть» кодом. Это помогает каждому члену команды участвовать в кодировании и проверке любого фрагмента кода.
3. Филиальная организация
   Есть дополнительная редакция кода до его слияния. Ветви могут быть (ИМХО должны быть) удалены после объединения функции. история мерзавцев (журнал) понятнее. (Это полностью зависит от качества комментариев)
4. Улучшено качество кода
   Я вижу, что это улучшает качество кода еще до пересмотра кода. Люди не хотят вводить плохой код, зная, что каждый может его посмотреть.
5. Лучший обзор кода
   Мы занимаемся широким обзором кода с самого начала проекта. Однако, как я объяснил выше, мы сделали это один на один, что обычно писатель объяснял рецензенту код. С моей точки зрения, при этом мы упускаем преимущества обзора кода. Качество рецензирования кода снижается, когда автор объясняет материал рецензенту. Использование pull-запроса, если рецензент что-то не понимает, это означает, что, возможно, код недостаточно чист. Так что больше замечаний и комментариев, значит, лучше код.
6. Наставничество
   Когда старший делает обзор кода для младшего, один на один, никто другой не видит его. Старшему человеку сложнее продемонстрировать ожидания того, как должен выглядеть код и как должен выполняться анализ кода. (Конечно, есть и другие способы его передачи, например, dojos кода. И парное программирование, хотя это тоже один на один). Комментируя обзор в запросе на извлечение, команда может увидеть, что важно и как проверить. Каждый получает пользу от обзора других членов команды.
7. Улучшенные привычки использования git
   Когда кто-то сотрудничает со всей командой, он, вероятно, напишет лучшие комментарии. Коммиты будут меньше и чаще, так как никто не хочет читать огромное количество строк различий. Поэтому никто не хочет «расстраивать» команду. Использование pull-запросов заставляет использовать ветки, что улучшает историю git.

Возражения

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

1. Я уже получаю слишком много писем
   Ну, это правда. Используя pull-запрос, мы начинаем получать гораздо больше писем, что раздражает.
   Там слишком много шума. Я мог не заметить важные электронные письма.
   Ответ прост: если вы являетесь частью этой функции, это письмо важно, потому что в нем упоминаются изменения кода в некоторых частях, над которыми вы работаете. Если вы хотите прекратить получение писем по этому конкретному запросу, вы можете отключить его.
   

   Mute Thread

2. Если мы начнем писать по электронной почте, мы перестанем разговаривать друг с другом
   Я не согласен с этим утверждением. Это, вероятно, сократит количество переговоров один на один. Но по моему (короткому) опыту, это улучшило наши словесные дискуссии. Устное обсуждение началось после того, как рецензент наблюдал за изменением кода. Если рецензент чего-то не понял, только тогда она подойдет к разработчику. Обсуждения один на один намного эффективнее и «точнее».
3. Ааа! Мне нужно подумать о том, чтобы лучше комментировать. Теперь мне нужно больше думать о
   Это хорошо, не правда ли? Используя запросы извлечения, каждый из членов команды должен улучшить способ написания комментариев в коммитах. Это также улучшит привычки мерзавца. С точки зрения меньших коммитов в более короткие сроки.
4. Это сложнее понять. Я предпочитаю, чтобы другой разработчик объяснил мне намерения
   Разве мы не упускаем важные преимущества проверки кода, если прогуляемся от автора? Я имею в виду, если мне нужно объяснение того, что делает код, тогда нам лучше исправить этот код. Так что, если это трудно понять, я могу написать свои комментарии, пока они не улучшатся.

Как?

В этом разделе я кратко объясню, как мы решили использовать запросы на выборку. Снимки экрана сделаны с GitHub, хотя BitBucket также поддерживает его.

Ветвление От «главной» ветки

Я не писал «мастер» намеренно. Допустим, я работаю над некоторой функцией в ветке под названием FEATURE_A (для меня это основная ветка). Эта ветка была создана из мастера. Допустим, мне нужно реализовать некоторую подфункцию в FEATURE_A. Пример (очень простой): добавление toString в класс Person. Затем я создам ветку (локально вне FEATURE_A):

Выполнение запроса на вытягивание

После некоторой работы над веткой и отправки ее на GitHub, я могу попросить Pull Request. Есть несколько способов сделать это. Тот, который я считаю «крутым», использует кнопку / ссылку в GitHub для вызова pull-запроса. При входе в GitHub-репозиторий в сети, он показывает кликабельную запись для последней ветви, на которую я нажал. После отправки запроса на извлечение все члены команды получат электронное письмо. Вы также можете назначить конкретное лицо для этого запроса на извлечение, если вы хотите, чтобы он / она выполнял реальную проверку кода.

Сравнить и получить запрос

Назначить меню

Изменение ветки для различий

По умолчанию GitHub попросит сделать пул-запрос к основной ветке. Как объяснено выше, иногда (обычно?) Мы хотим использовать diff / merge для некоторой ветви объектов, а не для master. В диалоговом окне запроса на выбор вы можете выбрать, с какой веткой вы хотите сравнить свою рабочую ветку.

Редактировать Diff Branch

Обзор кода и обсуждение

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

Несколько коммитов в запросе Pull

Слияние и удаление ветки

После обсуждения и добавления push-кода все будут довольны, и этот код можно будет объединить. GitHub сообщит вам, можно ли объединить вашу рабочую ветку с основной (diff) веткой для этого запроса на извлечение. Иногда ветви не могут быть автоматически объединены. В этом случае мы сделаем слияние локально, исправим конфликты (если есть), а затем снова нажмем. Мы стараемся часто делать это, поэтому GitHub обычно говорит нам, что ветви могут автоматически объединяться.

Филиалы могут быть автоматически объединены

Подтвердите слияние

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

Опубликовать слияние / закрытый экран

Кто ответственный?

Люди спрашивали

• Кто должен слиться?
• Кто должен удалить ветку?

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

Полезные команды git

Вот список полезных команд Git, которые мы используем.

Ресурсы

https://help.github.com/articles/using-pull-requests
https://www.atlassian.com/git/workflows#!pull-request

Наслаждаться…