1

「Go コードの書き方」チュートリアルを読んでいて、どうすれば安定したワークフローを設定できるのか疑問に思わずにはいられません。

当然のことながら、私のコードはソース管理下に置かれます。たとえば、Git です。今、私は次のことができるようになりたいです:

  • プロジェクトの実行可能ファイルをビルドします。特定の Git バージョンに対して、実行可能ファイルが同じものをビルドすることを確認してください。
  • プロジェクトの継続的なビルドを実行して、コミットごとにアクティブ化します。継続的なビルドが行うことはすべて、ワークステーションで再現可能であることを確認する必要があります。
  • プロジェクトのリリースを作成します。コードの同じ git バージョンからもう一度リリースを行うと、リリースを再作成できることを知っておく必要があります。

Go はそのための「go get」ツールを提供していますが、ここで混乱します。これをサポートする必要があるツール「go get」は、依存パッケージのソース管理リポジトリを設定します。これにより、次の問題が発生します。

  1. 依存パッケージを自分のソース管理下に置くことができません。つまり、私と共同作業者の間、または私と私の継続的ビルド システムの間に環境の違いがある場合、それらの違いを理解するのに苦労することになります。
  2. ネットワークがダウンしている場合、コードを最初から作成することはできません。別の言い方をすれば、私の継続的ビルド システムは、リリースをビルドするたびに、これらすべての外部サーバーにアクセスする必要があります。これは壊れやすいものかもしれませんし、外の世界に知らせたくないものかもしれません.
  3. Go は、パッケージのバージョンをベース言語のバージョンと同期させる規則を定義していますが、パッケージの作成者がその規則に従うという保証はありません。そうでない場合、クリーンなワークスペースは、壊れている可能性のある任意のリリースを取得します。
  4. 依存しているプロジェクトが放棄された場合、プログラムを構築する能力を失う可能性があります。

依存プロジェクトのコードを手動でインポートし、「go get」をまったく使用しないことで、それらを回避できますが、言語がその使用のために特別に設計および促進したツールを避けています。

助言がありますか?何か不足していますか?

4

1 に答える 1

1

go get は、ソース リポジトリが使用する分散バージョン管理システムを使用するだけです。リポジトリのローカル コピーが使用されます。私はここであなたの懸念のそれぞれに対処しようとします.

  1. 必要に応じて、ローカル リポジトリで変更を行い、そこにコミットすることができます。
  2. go get は、明示的に更新するように指示しない限り、最初に構築したローカル リポジトリを使用します。
  3. go get はリポジトリを吹き飛ばしませんが、まだそこにあります。また、go get が理解するすべてのソース管理システムは分散ソース管理システムであるため、プロジェクトのフォークを自分で進めない理由はありません。
于 2012-04-07T20:45:52.873 に答える