Как интеграция bug tracker/version control работает с типичными рабочими процессами git?

Большой Вопрос.
Для ответа на него вам нужно посмотреть, что оба этих инструмента (BugTracker.NET, который вы хорошо знаете, очевидно ;) и Git, сделано изначально для Linux в 2005) являются на самом деле пытается решить.

• BugTracker.NET: веб-трекер, для ошибки (или почти любого другого "элемента", который вы хотите отслеживать, так как вы можете определить свои пользовательские поля, Статус и рабочий процесс)
• Git: по своей сути, это Patch integrator, сделанный для применения множества патчей от множества людей (не все из них известны или с определенными ролями) к большому количеству файлов. быстро.

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

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

но если вы следуете этому пути (контролируете один репозиторий, действующий как "официальный ссылочный", имея свободный распределенный рабочий процесс слияния ниже этого одного РЕПО), вам нужно повторно определить, что такое пользователь и его роль.
Особенно, когда дело доходит до интеграции Git с централизованным инструментом отслеживания ошибок на основе ролей.

Если вы смотреть презентация Git Лайнуса в Google, около 18 ' 35, вы получите к проход, где вы понимаете, что использование Git означает не иметь все пользователи, идентифицированные и прикрепленные к роли.

вот несколько быстрых кавычек / точек, которые иллюстрируют этот факт:

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

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

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

• из той же презентации вы также понимаете, что "весь репозиторий" может быть частью жизненного цикла кода (в отличие от ветвей "интеграция", "тестирование", "быть выпущенным" или ярлыков " release1.0',...):

" одна из вещей для коммерческих компаний: распределенная модель также помогает в процессе выпуска.
У вас может быть команда проверки, которая имеет свое собственное дерево. И они тянут из людей и они проверьте это, и они проверили это, они могут подтолкнуть его к команде релиза и сказать: "Эй. Теперь мы проверили наши версия, и люди развития, они могут продолжать, играя с их головой, вместо того, чтобы создавать теги, ветви, все, что вы делаете, чтобы попытаться держать друг от друга пальцы.
Опять же, вы держитесь подальше друг от друга, просто каждая группа может иметь свое собственное дерево, и отслеживать свою работу и то, что они хотят сделать. ".

, которые усиливают предыдущий момент: если вы отслеживаете только одно РЕПО, вы можете только мониторные коммиты от ограниченного числа людей.
И это добавляет поворот:
Пока вы не можете контролировать все РЕПО там, вы можете не захотеть контролировать только одно РЕПО: если отслеживание ошибок перекрывает несколько фаз (а именно "contrinous integration", "функциональное тестирование", "проверка пользователя", "предварительное производство",...), каждый из них потенциально имеет свое собственное дерево, и каждый из них является потенциальным источником заполнение отчета об ошибке.
В этом отношении "поддержка филиала Git Redmine" (пересмотр 2840) по-прежнему выполняется с установкой "централизованного РЕПО", где вы используете ветку для моделирования жизненного цикла разработки (где вы выполняете задачи и по развитие, вместо того, чтобы делать фактические "усилия по развитию", что и должно быть в отрасли).

где все это оставить вас?

• либо навязывания строгая модель центрального репозитория (каждый должен нажать на одно РЕПО), которая, по моему опыту, никогда не бывает хорошей, когда инструмент пытается заставить вас работать в одну сторону, а не позволяет адаптировать инструмент к тому, как вы хотите работать.

• или переопределение управления жизненным циклом ошибок с учетом:

  • потенциально несколько деревьев, каждое из которых является потенциальным шагом в разрешении ошибки.
  • пользователи, которые будут зарегистрированы как работающие над ошибкой, но без полное история кода: т. е. отслеживаемый код может быть не напрямую связанные с ними, так как разрешение может быть сделано в частных ветвях на репозиториях разработчика, в то время как отслеживаемый код сделан из нескольких слияний одним "интегратором" на выделенных репозиториях.
  • интеллектуальная отчетность, способная рассказать, какие ошибки обнаружены / исправлены в "официальной редакции" кода, ограничиваясь указанием на происхождение тех изменения (это происходит от слияния таких удаленных ветвей, для такого удаленного РЕПО)

короче говоря, это не тривиальная задача.

вопросы остаются:

• рабочий процесс публикации Git, который является inter-repo (push/pull), а также intra-repo (merge/rebase): какие из них вы хотите отслеживать?
• git частное ветвление: не все история кода когда-либо будет видна и не должна отслеживаться. Только публичные ветви (которые вытягиваются/выталкиваются, но также изменяются в их собственном РЕПО некоторым слиянием или перебазированием) должны отслеживаться
• пользователи Git: в соответствии с их местом в "сети доверия" у них разные роли, которые должен отражать трекер.

Эхо ответа MichaelM, а в Redmine имеет хорошую интеграцию с Git. Он следует за сообщениями фиксации для ключевых слов, таких как ссылки. исправляет etc и номер трекера формы #1234.

Это правда, что поддержка ветви еще не совсем там, но она вошла в ствол месяц назад, и предназначен для версии 0.9. Redmine в настоящее время поддерживается в SVN, но есть также зеркало на Github

ссылка на Redmine trunk указывает на выход трекера для репозиториев Git с различиями в том, как перемещаются ветви.

$ git log

может использоваться для анализа сообщений фиксации, авторов и изменений для использования в любом трекере, если это необходимо.

Edit: Из-за распределенного характера Git против централизованного характера SVN, для каждого пользователя или копии репозитория вполне возможно иметь разные ветви. В exisitnig трекеров, как правило, имеют локальную копию репозитория это используется как центральная ссылка ("благожелательный диктатор"), которую можно рассматривать как рабочую копию для всех пользователей.

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

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

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

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

там же открыть интеграции источник С Fogbugz, на GitHub, конечно.

посмотрите, как Launchpad делает это: отслеживание состояния ошибки в разных местах.

ниже я процитирую Марк Шаттлворт:

действительно распределенное отслеживание ошибок (где список ошибок следует за кодом везде) очень интересно, и может быть долгосрочным решением. В промежуточный, вы можете адресовать его с просто отслеживать состояние жучок в нескольких разных местах. Canonical финансирует работу по Bugzilla, Trac and другие баг-трекеры, чтобы было проще разговаривать их программно, так что мы можем держать разработчиков в курсе автоматически.

У нас есть "централизованное представление о статусе распределенной ошибки" в Launchpad, что помогает нам отслеживать статус вопроса вверх по течению, в Debian, или в других дистрибутивах. Например, проверьте эти ошибки:

https://bugs.launchpad.net/moblin-applets/+bug/209870
https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/214041
https://bugs.launchpad.net/ubuntu/+source/tuxmath/+bug/220319
https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.22/+bug/123920
https://bugs.launchpad.net/ubuntu/+source/warsow/+bug/131582

в каждом случае, вы сможете увидеть, как ошибка связан с отчетами в других bug trackers, а затем статус обновляется автоматически. Как маленький следовательно, вы можете подписаться на любой отчет об ошибке на любом трекере ошибок (из поддерживаемых типов) через LP.

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

Redmine уже интегрируется с Git, и это opensource. Может быть, вы можете взглянуть на их интеграцию идей.

возможно, я немного наивен, но будет ли отслеживание ошибок действительно отличаться в git, чем в svn? Репозиторий, используемый системой, будет иметь ту же структуру (ветви и теги), что и в subversion, верно?

Я могу себе представить, что вам нужно хорошее графическое представление того, как взаимодействуют ветви, но кроме этого...