Использование git для обзоров кода?
Я хотел бы разработать легкий процесс обзора кода, который похож на тот, который я использовал, когда работал в MSFT.
Это общий план процесса:
- разработчик делает изменения.
- разработчик пакеты изменений в какой-то архивный файл
- разработчик отправляет файл в команду разработчиков
- случайный член команды разработчиков, автоматически открывает файл изменений в утилите diffing, делает заметки
- если код хорошо, случайный член говорит так, иначе отвечает с запрошенными заметками
просто для ясности: я знаю , как изменить код (:D) и отправить электронную почту. Я хотел бы узнать, есть ли прямой способ создать архив изменений и легко просмотреть их в инструменте diff с помощью git. Я думаю, что могу создать git patch и отправьте это по электронной почте, но это только 1/2 истории. Могу ли я легко просмотреть, что патч б сделать в коде?
I хочу сделать это как можно более легким, потому что в противном случае маловероятно, что обзоры кода будут сделаны, и я твердо верю, что простой процесс обзора кода повысит качество кода.
9 ответов
использовать Github. Рабочий процесс немного меняется:
- разработчик вносит изменения
- разработчик фиксирует код
- разработчик нажимает на Github
- разработчик отправляет запрос pull в team lead / reviewer
- Reviewer принимает изменения и объединяет код в основной репозиторий
Github не бесплатно, но учитывая, что он делает для вас, это дешево. Вы можете легко комментировать delta (single изменение) или в строке перед принятием или отклонением изменения. Вы также можете получить код в локальном репозитории и просматривать, компилировать, запускать, запускать модульные тесты или что угодно.
Что касается рецензентов, делающих слияния, я не думаю, что есть простой способ сделать это. Однако вы можете заблокировать "благословенный" репозиторий, чтобы только избранные люди могли нажать на него (рецензенты). Таким образом, проверки кода будут принудительными. В системе электронной почты, даже если у вас есть файлы исправлений, рецензент еще предстоит пройти процесс применения патча и слияния. Отправка запросов pull-это шаг вперед от патчей, потому что git может использовать историю слияния ветви, чтобы сделать более обоснованное предположение; поэтому слияние в git, как правило, проще.
Это очень распространенная ситуация. Люди часто хотят принудительных обзоров кода, и github делает это бесспорно легко. На самом деле, многие люди начинают использовать github просто для принудительных обзоров кода.
Я не понимаю, почему вы хотите обойти свою систему управления версиями, отправляя патчи по электронной почте и пытаясь отслеживать, какие патчи были или не были объединены, когда у вас есть модель ветвления git.
вместо отправки патчей по электронной почте почему бы не нажать удаленную ветку и не попросить рецензента взять на себя ответственность за ее слияние с вашей основной веткой разработки? Таким образом, вы можете положиться на свой репозиторий, чтобы показать, какой код был или не был объединен в ваш главная ветвь (git branch -r --no-merged). Вы можете легко перебазировать ветви функций, нуждающиеся в обзоре, чтобы держать их впереди вашей основной ветви, позволяя обзору выполнять быстрое слияние и не беспокоиться о конфликтах слияния. Вы также можете воспользоваться любыми инструментами git-aware diff для просмотра изменений.
лично я бы предложил также, чтобы ваши рецензенты объединяли ветви функций с помощью --no-ff для создания фиксации слияния, чтобы вы получили историю, которая выглядит что-то например:
git log --graph
* commit 84b9...
|\ Merge: 8d56... f301...
| | Author: Reviewer <reviewer@here.example>
| | Date: Tue Mar 15 15:53:20 2011 -0700
| |
| | Merge branch 'feature-foobar'
| |
| * commit f301...
| | Author: Developer <dev@here.example>
| | Date: Mon Mar 14 16:53:21 2011 -0700
| |
| | Add more foobars
| |
| * commit c867...
|/ Author: Developer <dev@here.example>
| Date: Mon Mar 14 10:09:12 2011 -0700
|
| Add foobar feature
|
* commit 74e6...
|\ Merge: 4232... 8d0e...
вы получаете хорошую чистую историю функций, объединенных в вашу основную ветвь, видимость работы, выполненной в каждой ветви функций, и можете видеть, кто рассмотрел код, как он был объединен.
Я искренне рекомендую критик, система обзора Git, разработанная и используемая в Opera Software. W3C также использует его для просмотра тестов.
С критиком нормальная работа выглядит так:
- написать код, commit
- нажмите на пульт критика (у вас обычно есть
originиcritic) - критик отправляет электронные письма тем, чьи фильтры соответствуют вашим измененным файлам, им назначаются эти файлы
- некоторые из этих люди заходят и просматривают файлы, к которым они прикреплены.
- когда обзор сделан на 100% (критик отслеживает его), вы можете интегрировать свою ветку
удивительная вещь, что любой вопросы вы создаете при просмотре is автоматически на имя когда вы нажимаете новые коммиты, которые обращаются к ним. Рецензент также получает красиво отформатированное письмо о новых изменениях (хотя я предпочитаю просто перейти на веб-интерфейс), чтобы просмотреть новый изменения.
все изменения должны быть рассмотрены до рассмотрения принимается. Так что это включает исправления.
типичный сценарий:
100% reviewed, 2 issues
затем, когда они исправлены одним или двумя исправлениями, эти исправления, конечно, должны быть рассмотрены, поэтому обзор будет идти:
98% reviewed, 0 issues
и когда кто-то видел через это, он обновляется до 100% снова, а затем Review Accepted.
ему не хватает продвижения и блеска, но это reeaally приятно работать. Мы также должны использовать Gerrit для наших обзоров Chromium (я работаю в Opera), и мы использовали ReviewBoard очень короткое время (неудовлетворенность RB была фактически прямой причиной, почему критик был создан в первую очередь).
у нас также есть несколько расширений, написанных для него, например, вы можете отправить код в commit-queue (который проверяет изменение и фиксирует его, если хорошо) после того, как вы получили принятый обзор.
вы можете создать git "bundle" это эффективно сохраняет последовательность коммитов. Это лучше, чем файл исправления, поскольку он может содержать более одной фиксации (для использования файлов исправлений потребуется один файл исправления на фиксацию).
любой может легко вытащить пакет в свой собственный репозиторий, на временной ветке "обзор", Если хотите, и посмотреть, каков эффект коммитов. Если вы потянете пакет на ту же самую ревизию, с которой начал разработчик, то нет возможности конфликтов, поэтому рецензенту не нужно делать ничего особенного.
Я бы также предложил взглянуть на обзорную доску:
Review Board был первоначально разработан несколькими инженерами в моей компании (VMware, Inc.) и используется большим количеством корпоративных программных компаний с рабочим процессом, очень похожим на то, что вы описываете. В настоящее время требуется настройка центрального сервера (это довольно стандартное приложение MVC на основе Django AFAIK), однако они также работают на хостинге обслуживание:
вместо того, чтобы отправлять исправления по электронной почте, он фактически предоставляет (очень ловкий) веб-интерфейс, который отражает то, что предлагаемое изменение будет делать с текущей кодовой базой; он поддерживает навигацию по клавиатуре, позволяет прикреплять скриншоты, автоматически разбивать на страницы для очень больших изменений, позволяет отвечать обратной связью по строкам и поддерживает рабочие процессы" изменение на изменение", где исходный патч дополненные и рецензенты могут сосредоточиться на отличиях от предыдущей версии того же патча. Он имеет базовую поддержку Git, о которой вы можете узнать больше в FAQ:
http://www.reviewboard.org/docs/manual/dev/faq/
Я использовал совет с момента его создания. До его появления мы использовали систему почтовых патчей, очень похожую на то, что вы описываете, и обзор Совета был большим шагом вперед.
SmartGit обеспечивает облегченный код рассматривая функциональность которую можно настроить быстро. Он работает локально (метаданные являются частью самого репозитория Git) и, следовательно, не требует дополнительных серверных компонентов.
другие ответы указали вам на существующие инструменты для обзора кода, и это, вероятно, то, что вы действительно хотите.
но для полноты, так как вы попросили способ работы с электронной почтой:
на передающей стороне,git отправить по электронной почте позволяет отправить патч по электронной почте. Просто отправка исправления недостаточно, так как он не передает метаданные, такие как сообщение журнала. Если
git send-emailне работает для вас, формат git-патч can создайте патч с метаданными, которые вы можете отправить так, как хотите.на конце приемника, git am позволяет взять набор исправлений по электронной почте в формате mbox и применить его к репозиторию. Некоторые почтовики позволяют запускать произвольную команду в сообщении: затем выполняется
git amв сообщении применяется. Альтернативой является сохранение исправлений по электронной почте в файл mbox и запускgit amна нем из командной строки. Обзор можно сделать либо прочитав патч или применяя патч к ветви throwable и читая историю на этой ветви.
FYI, вот как разработан сам инструмент Git (см. SubmittingPatches для получения дополнительной информации).
могу ли я легко просмотреть, что патч сделает с текущей базой кода?
Git 2.17.x (Q1 2018) может помочь с git format-patch:
"git format-patch " научился давать 72-cols diffstat, который является
в соответствии с другими ограничениями длины линии, которые подкоманда использует для
его вывод предназначался для электронной почты.
посмотреть совершить 071dd0b (01 Feb 2018), и совершить 43662b2 (25 янв 2018) by Nguyễn Thái Ng Duc Duy (pclouds).
(слитый Junio C Hamano -- gitster -- на совершить e469e9c, 21 февраля 2018)
format-patch: уменьшите ширину diffstat заплаты до 72патчи, генерируемые format-patch предназначены для обмена в качестве электронной почты, большую часть времени.
И поскольку все согласны с тем, что текст в письмах должен быть обернут вокруг 70 столбцов или около того, убедитесь, что эти diffstat следуют конвенции (особенно при использовании--cover-letterпоскольку мы уже по умолчанию оборачиваем 72 столбца). Значение по умолчанию по-прежнему можно переопределить с помощью параметров командной строки.