15

gitワークフローの例は次のとおりです。

バグトラッカーとバージョン管理システムの統合を利用したいとします。これらのワークフローのどこ/どのように適合しますか。トラッカーには実際に何が表示されますか？

私はBugTracker.NETの作成者であり、他の多くのバグトラッカー（Trac、Redmine、FogBugz）と同様にsvnと統合されています。私たちは皆、多かれ少なかれ同じ方法でそれを行います。しかし、gitを使用すると、gitとの統合がどのようになるか想像するのに苦労します。

編集：私はgithub-fogbugz統合の1つの試みを見てきましたが、その作者でさえ「FogBugzがより伝統的なCVS / SVN SCMシステムを念頭に置いて書かれたことはかなり明白です。そのため、コミットリストディスプレイは実際にはgitと連動しません。」

EDIT2： Redmine / gitワークフローに関するスレッド：最も一般的なセットアップは、Redmineが「中央」リポジトリと見なされるもののローカルクローンで動作するため、このクローンに到達したときに変更を確認することです。トリガーまたはスケジュールされたジョブは、Redmineのクローンへのプッシュを自動化します。

EDIT3：LinuxとLinusでも、最終的には、慈悲深い独裁者リポジトリと見なすことができるメインのgitリポジトリがあります。http：//git.kernel.org/？p = linux / kernel / git / torvalds/linux-2.6を参照してください。 .git; a = summary

エピローグ：みんなありがとう。皆さんからのガイダンスによると、私のBugTracker.NETにはgit統合が含まれています。

4

7 に答える 7

8

TracとRedmineはどちらもGitとの統合をサポートしています。Subversionのサポートとほぼ同じように見えます。バグトラッカーは、慈悲深い独裁者リポジトリとして1つのリポジトリを追跡します。その場所にある他のすべてのクローンについて、気にする必要はありません。

私が言及する価値があると思うことの1つは、バグトラッカーはgitブランチを適切にサポートする必要があるということです。ブランチでの作業はGit方法論の非常に重要な部分であり、バグトラッカーでサポートする必要があります。Redmineはパッチを介してこれを行うことができますが、最後に調べたところ（約1か月前）、メインのソースツリーにはありませんでした（マスターをフォローすることしかできませんでした）。

その他の便利な機能は、gitkの外観と同様に、ブランチがどのように作成およびマージされるかをグラフィカルに表現することです。この種の視覚化を行うバグトラッカーを私は知りません。

CoreyTragerによる編集。@Squelchの回答をここにコピーして貼り付けました（@Squelchも賛成しました）：

SVNの集中化された性質に対するGitの分散性により、すべてのユーザーまたはリポジトリーのコピーが異なるブランチを持つ可能性があります。既存のトラッカーには通常、すべてのユーザーの作業コピーと見なすことができる中央参照（「慈悲深い独裁者」）として使用されるリポジトリのローカルコピーがあります。

ユーザーがローカルコピーにトラッカーとは異なるブランチ構造を持つことは非常に現実的です。プライベートを維持するか、関心のあるリモートからブランチのみをプルするか、新しいブランチをリモート（トラッカー）にプッシュするかを選択できます。ユーザーは、リモートが決して見ることができないブランチを自分たちの間で共有することさえできます。

バグトラッカーは、実際にはアクセスできるリポジトリのみを参照できます。通常、これはトラッカーに対してローカルですが、トラッカーから離れたリポジトリからプルすることも可能であり、管理がはるかに困難です。リモートにアクセスしている場合は、知識のあるブランチのみを追跡でき、スケジュールされたタスク以外にこのタスクを開始する方法は実際にはありません。これは、ユーザーがローカルコピーも提供していることも前提としています。

すでに述べたように、スケジュールされたタスクまたはイベントフックを使用して、詳細についてコミットログを使用してトラッカーを更新できます。これらの詳細は、必要に応じて上記のように表示するためにトラッカーの問題と照合できます。

つまり、トラッカーは通常、現在アクセスできるブランチに加えられた変更をすべて確認します。フックを使用すると、新しいブランチの作成など、これらの変更がすぐに確認されます。ユーザー（オフライン）リポジトリに加えられた変更は、ユーザーがそれらの変更をプッシュするまで表示または追跡されません。

@Squelchの終わり

于 2009-09-28T07:54:35.670 に答える
8

素晴らしい質問です。
それに答えるには、これらのツール（BugTracker.NET、明らかに;）とGit（2005年にLinux用に最初に作成されたもの）の両方が実際に何を解決しようとしているのかを調べる必要があります。

  • BugTracker.NET：バグ用のWebベースのトラッカー（または、カスタムフィールド、ステータス、ワークフローを定義できるため、追跡するその他の「アイテム」のほとんどすべて）
  • Git：コアとなるのはパッチインテグレーターであり、多くの人（すべてが既知または特定の役割を持っているわけではありません）からの多くのパッチを多数のファイルに適用するように作られています。すぐに。

したがって、ここでは、中央参照ツールと分散コード集約ツールの間の不協和を見ることができます。

これら2つのモデルの最小公分母は、「慈悲深い独裁者ワークフロー」のままです。これは、監視するための中央リポジトリがまだある、最も分散されたワークフローです。

ただし、そのパスをたどる場合（1つのリポジトリが「公式参照」として機能し、その1つのリポジトリの下に緩い分散マージワークフローがある場合）、ユーザーとその役割を再定義する必要があります。
特に、Gitを一元化された役割ベースのバグ追跡ツールと統合する場合はそうです。

18'35頃にGoogleでLinusのGitのプレゼンテーションを見ると、Gitを使用するということは、すべてのユーザーが識別されて役割に関連付けられていないことを意味していることに気付くでしょう。

その事実を説明するいくつかの簡単な引用/ポイントを次に示します。

  • 「中央リポジトリがあるということは、そのプロジェクトに取り組んでいるすべての人が中央リポジトリに書き込む必要があることを意味します。
    つまり、ほとんどの人がモロンであるため、誰もが中央リポジトリに書き込みをしたくないので、表面上はモロンではないこのクラスの人々を作成します。」

したがって、すべての人が中央リポジトリにプッシュすることになるわけではなく、そこでの実際の作業のほとんど（小さな修正、検証、テストなど）は、とにかく限られた数の人によって行われます。

その「慈悲深い独裁者のワークフロー」は、あなたが「信頼のネットワーク」、つまり選ばれた人々のグループと協力することを意味します。繰り返しますが、すべての開発者が直接表示されるわけではありません。

  • 同じプレゼンテーションから、「すべてのリポジトリ」がコードのライフサイクルの一部になる可能性があることもわかります（ブランチの「統合」、「テスト」、「リリース予定」、または「release1.0」のラベルとは対照的です。 '、...）：

「営利企業にとって重要なことの1つは、分散モデルがリリースプロセスにも役立つことです。
独自のツリーを持つ検証チームを持つことができます。そして、人々から引っ張って検証し、検証した後、リリースチームにプッシュして、「ねえ。これでバージョンを検証しました。開発担当者は、頭を使って遊んでいきます。 、タグやブランチを作成する代わりに、お互いのつま先を寄せ付けないようにするために何をするにしても、
すべてのグループが独自のツリーを持つことができ、その作業と彼らが何をしたいのかを追跡することができます。 。」。

これは前のポイントを補強します。1つのリポジトリのみを監視する場合、限られた数の人々からのコミットのみを監視できます。
そしてそれはひねりを加えます：そこにあるすべて
のリポジトリ を監視することはできませんが、1つのリポジトリだけを監視したくない場合があります：バグ追跡が複数のフェーズ（つまり、「連続統合」、「機能テスト」、「ユーザー検証」、 「実動前」、...）、それぞれが潜在的に独自のツリーを持ち、それぞれがバグレポートを埋めるための潜在的なソースです。 その点で、「RedmineによるGitブランチのサポート」（リビジョン2840）は、依然として「集中型リポジトリ」の考え方で作成されています。
ブランチがすべてであるべきである実際の「開発努力」を行う代わりに、開発）。

それはどこにあなたを残しますか？

  • 厳密な中央リポジトリモデルを課す（誰もが1つのリポジトリにプッシュする必要があります）。これは、私の経験では、ツールを目的の方法に適合させるのではなく、ツールが強制的に一方向に機能させようとする場合には決して適切ではありません。 。

  • または、バグのライフサイクル管理を再定義して、次のことを考慮に入れます。

    • 潜在的に複数のツリー。それぞれがバグ解決の潜在的なステップです。
    • バグに取り組んでいると登録されるが、完全なコード履歴がないユーザー：つまり、監視対象のコードは開発者のリポジトリのプライベートブランチで実行できるため、監視対象のコードは直接関連付けられていない可能性があります。専用リポジトリでの1つの「インテグレータ」による複数のマージ。
    • コードの「公式リビジョン」で検出/修正されたバグを特定できるインテリジェントなレポートにより、これらの変更の原因を指摘するように制限されます（このようなリモートリポジトリの場合、このようなリモートブランチのマージに由来します）

要するに、これは簡単な作業ではありません。

問題は残っています：

  • リポジトリ間（プッシュ/プル）とリポジトリ内（マージ/リベース）のGitパブリケーションワークフロー：どちらを追跡しますか？
  • Gitプライベートブランチ：コードのすべての履歴が表示されるわけではないため、追跡しないでください。パブリックブランチ（プル/プッシュされているが、マージまたはリベースによって独自のリポジトリ内で変更されている）のみを追跡する必要があります
  • Gitユーザー：「信頼のネットワーク」内での位置に応じて、トラッカーが反映する必要のあるさまざまな役割があります。
于 2009-10-10T21:39:14.777 に答える
5

MichaelMの答えを反映するために、RedmineはGitとの統合が良好です。これは、参照などのキーワードのコミットメッセージの後に続きます。修正などとフォーム＃1234のトラッカー番号。

確かにブランチサポートはまだありませんが、約1か月前にトランクに入り、バージョン0.9に向けられています。Redmineは現在SVNで管理されていますが、Githubにもミラーがあります

Redmineトランクへのリンクは、Gitリポジトリのトラッカー出力を示していますが、ブランチのナビゲート方法が異なります。

$ git log

必要に応じて、任意のトラッカーで使用するために、コミットメッセージ、作成者、およびリビジョンを解析するために使用できます。

編集： SVNの集中化された性質に対するGitの分散性により、すべてのユーザーまたはリポジトリのコピーが異なるブランチを持つ可能性があります。既存のトラッカーには通常、すべてのユーザーの作業コピーと見なすことができる中央参照（「慈悲深い独裁者」）として使用されるリポジトリのローカルコピーがあります。

ユーザーがローカルコピーにトラッカーとは異なるブランチ構造を持つことは非常に現実的です。プライベートを維持するか、関心のあるリモートからブランチのみをプルするか、新しいブランチをリモート（トラッカー）にプッシュするかを選択できます。ユーザーは、リモートが決して見ることができないブランチを自分たちの間で共有することさえできます。

バグトラッカーは、実際にはアクセスできるリポジトリのみを参照できます。通常、これはトラッカーに対してローカルですが、トラッカーから離れたリポジトリからプルすることも可能であり、管理がはるかに困難です。リモートにアクセスしている場合は、認識しているブランチのみを追跡でき、スケジュールされたタスク以外にこのタスクを開始する方法は実際にはありません。これは、ユーザーがローカルコピーも提供していることも前提としています。

すでに述べたように、スケジュールされたタスクまたはイベントフックを使用して、詳細についてコミットログを使用してトラッカーを更新できます。これらの詳細は、必要に応じて上記のように表示するためにトラッカーの問題と照合できます。

つまり、トラッカーは通常、現在アクセスできるブランチに加えられた変更をすべて確認します。フックを使用すると、新しいブランチの作成など、これらの変更がすぐに確認されます。ユーザー（オフライン）リポジトリに加えられた変更は、ユーザーがそれらの変更をプッシュするまで表示または追跡されません。

于 2009-09-28T11:26:58.780 に答える
1

もちろん、GitHubにはFogbugzとのオープンソース統合もあります。

于 2009-09-28T07:58:04.743 に答える
1

Launchpadがこれをどのように行うかを見てみましょう。さまざまな場所でバグの状態を追跡します。

以下、マーク・シャトルワースに引用します。

真に分散されたバグ追跡（バグリストはどこでもコードに従う）は非常にエキサイティングであり、長期的な解決策になる可能性があります。暫定的には、いくつかの異なる場所でバグの状態を追跡するだけで対処できます。Canonicalは、Bugzilla、Trac、およびその他のバグトラッカーの作業に資金を提供して、プログラムでの会話を容易にし、Ubuntu開発者を自動的に最新の状態に保つことができるようにしています。

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

いずれの場合も、バグが他のバグトラッカーのレポートにどのようにリンクされているかを確認でき、ステータスが自動的に更新されます。小さな結果として、LPを介して（サポートされているタイプの）任意のバグトラッカーで任意のバグレポートをサブスクライブできます。

一元化されたビューは究極のソリューションではありませんが、現在私たちのために機能しており、他のかなりの数のプロジェクト（アップストリームとディストリビューション）もそれを使用しています。

于 2012-09-13T18:24:33.817 に答える
0

おそらく私は少しナイーブですが、バグ追跡はgitとsvnで本当に違うのでしょうか？システムで使用されるリポジトリは、基本的にSubversionと同じ構造（ブランチとタグ）になりますよね？

ブランチがどのように相互作用するかをグラフィカルに表現したいと思うかもしれませんが、それ以外は...

于 2009-09-28T07:41:01.170 に答える
0

RedmineはすでにGitと統合されており、オープンソースです。たぶん、あなたはアイデアのためにそれらの統合を見ることができます。

于 2009-09-27T22:27:45.017 に答える