1

状況:私たちの会社は、git リポジトリのコードから Hudson を使用してビルドされたソフトウェア リリースを作成しています。試用期間が終了したため、以前のバージョンのビルドを再現する必要がある場合があります。そのソフトウェア バージョンに対応するコード バージョンを見つける必要があるため、これは問題を引き起こします。私たちの開発者は、タグやブランチを使用して作業することはありません。これは、作業スタイルに合わないためです。

この問題の解決策として、ビルドが成功するたびに自動タグ付けシステムを組み込むべきだと考えました。

私が念頭に置いていたワークフローは次のとおりです（ビルドマシンで実行されます）：

  1. ローカルの変更が行われた場合は、すべて破棄します。git checkout . git clean -df
  2. 最新バージョンを入手:git pull
  3. 目的のバージョンに移動するgit checkout .か、git checkout <tag>
  4. ソフトウェアを構築する
  5. 成功した場合: 現在のバージョンにタグを付け、タグをリポジトリにプッシュします。git tag -m "automated tag" versionXXX git push --tags

この働き方について、3 つの質問があります。

  1. この作業方法に明らかな欠陥はありますか? （あいまいです、知っています - ごめんなさい）
  2. このユースケースでは、軽量タグよりも注釈付きタグを使用する利点はありますか? ほとんどの投稿は注釈付きタグを推奨していますが、特にこのユースケースでは、付加価値を実際には見ていません.
  3. 私たちのソフトウェアは複数のモジュールで構成されており、それぞれが独自の git リポジトリを持っています。これらのモジュールの一部はほとんど更新されません。同じコミットを指すタグがたくさんあることにマイナス面はありますか?
4

1 に答える 1

2

1) この作業方法に明らかな欠陥はありますか? （あいまいです、知っています - ごめんなさい）

いいえ。

2) このユースケースでは、軽量タグよりも注釈付きタグを使用する利点はありますか?

いいえ、タグ メッセージに意味のあるものを何も入れていないのであれば、そもそもタグ メッセージを作成しても意味がありません。本当の欠点はありません (スペースをほとんど使いません)。ビルドから何らかの結果が得られた場合は、それらをタグ コメントに入れることができます (チェックされる他のログ メカニズムがない場合)、たとえば、警告の数などです。

3) 多くのタグが同じコミットを指していることのマイナス面はありますか?

いいえ、タグの名前空間が乱雑になる可能性があることを除けば (タグ名はリポジトリに対して一意である必要があります)、問題はありません。前述のとおり、スペースはほとんど使用しません。冗長なタグが問題になる場合は、次のような戦略を実装できます。以前のビルドのタグが、今すぐタグ付けしたい同じコミットを指している場合は、タグ付けしないでください。特定のバージョンのタグを検索する場合は、指定しているバージョンより前の最新バージョンのタグを使用してください。(ルックアップが自動化されている場合にのみ可能です。それ以外の場合は、コミットにタグを付け直すだけです。)

于 2013-01-08T15:23:06.830 に答える