7

この質問のニーズは、

  • 次のようなマネージャー/顧客向けの変更ログがあります。
    • 「ユーザーに追加のアドレスを許可する」が含まれています
    • 「X によりアドレスが上書きされるバグを修正」は含まれません
  • ビルドごとに最も重要なコミット (ほとんどの場合、下位互換性がない) を見つけるために、完全なログ履歴を調べる必要がなくなります。
  • 典型的なゲームの変更ログと同じくらい読みやすくします(「固定バランスの問題: X」および「グラフィックス ドライバー Y がゲームを遅くレンダリングしました」)。

現在、次のようなコミット メッセージでフラグを使用しています。

Add|Ref|Rem|Fix: <msg>通常のコミット用。

そのため、これに対する私の最初の試みは、これらのフラグに別のティアを追加することです。たとえば、

CL-Add: feature X(CL = 変更ログ) 次に^CL-(Add|Ref|Rem|Fix)、変更ログに追加するすべてのコミット メッセージを解析します。

しかし、次に、変更ログのためだけにコミット メッセージが書き込まれる可能性 (つまり、レベルが高すぎる) にどのようにアプローチしますか? または同じ変更ログの問題に関する複数のメッセージ。おそらく、機能ブランチがマージされたときに変更ログ メッセージを抽出する必要がありますか? この問題を処理する SCM:s (git など) の機能はありますか?

簡単に言えば、有用なコミット メッセージを変更ログに簡単に抽出するための業界標準の戦略またはツールはありますか?

4

3 に答える 3

3

私は過去にほとんど運がなかったので、これを自分で試しました。基本的に、すべての開発者がコミットのたびに、自分のコミット メッセージが顧客にとって怖すぎるかどうかを考えるのは、実際にはより多くの作業です。一般に、開発者はその決定を下すのに適した人物ではなく、一度に少しずつ行うのは非効率的です。

多くの実験の後、私にとってうまくいったことは些細なことです: すべてのリリースの直前に、最後のリリース以降の git ログを 1 人が調べて、すべての興味深いものを変更ログ ファイルに書き留めます。これは実際には他の方法よりも手間がかかりません。ほとんどの作業は、言い回しではなく決定です。また、意思決定プロセスには特定の考え方が必要なため、多数の開発者が一度に少しずつ行うよりも、大きなバッチで 1 人で行う方が効率的です。(このように考えてください: ジョブの「コミット メッセージの顧客チェック」部分をキャッシュの内外で交換し続ける必要はありません。)

コミット メッセージにこの種の情報をタグ付けしたい場合は、少なくともgit notes生のコミット メッセージの代わりにそれを行うことを検討する必要があります。次に、誰かがコミットを誤ってバグ/機能/などとしてマークしてそれを台無しにした場合、注釈を更新することで修正できます。

于 2011-02-25T12:19:24.643 に答える
1

私はそのような標準的なツールを知りませんが、しばらく回答が得られていないので、いくつかのアイデアを紹介します:

したがって、最初に、CHANGELOG ファイルを回避しようとすることは、そのようなファイルが引き起こす傾向があるすべてのマージ競合のため、一般的にはおそらく良い考えです。(たまたまスマートな自動マージ ツールを持っている場合を除きます。)

簡単に抽出できるように、CL: や Log: などのプレフィックスを付けるとよいでしょう。Add/Ref/Rem/Fix について: (これは "Refactor" と "Remove" の略だRefとRem思いますよね?) 変更ログを書いているときは、自由形式のエントリに固執したいと思います。たとえば、リファクタリングが変更ログに属しているかどうかはわかりません。また、変更ログのエントリを正当化するのに十分な高レベルの機能は、通常、完全に削除されるわけではなく、別の形式に変更されます。

しかし、変更ログのためだけにコミット メッセージが書き込まれる可能性にどのようにアプローチしますか (つまり、レベルが高すぎる)。

( CL:-tagged) の高レベルの説明をコミット メッセージの 1 つの段落に入れ、低レベルの技術的な説明を別の段落に入れます。

または同じ変更ログの問題に関する複数のメッセージ。

私たちはこのようなことについて話していますよね？

  1. (2011-01-03) CL: ウィズバーのデフォルトを 200 に変更しました。
  2. (2011-01-11) CL: whizbar のデフォルトを 150 に変更、または foosnub が true の場合は 250 に変更。

そして、これが「自動変更ログ」の扱いが難しいと私が思うところです。事後にコミット メッセージをリベースして編集する意思がない限り (上記のコミット (1) から "CL:" を削除するなど)、これを行う唯一の実用的な方法は、リリースを行うたびに行うことです。 、最後のリリース以降にタグ付けされたすべての段落を git ログから抽出し、結果のリストを手動で編集して、上記の (1) と (2) のようなものをマージし、「Fixed #145」、「Fixed #153」とします。 、「固定 #164」を 1 行に「固定 #145、#153、および #164」にします。

インスピレーションを提供できたことを願っています。あなたが何をしているのか教えてください！

于 2011-01-12T16:43:17.483 に答える
1

vclogを見てください。

于 2011-12-07T22:30:46.247 に答える