1

私が、コンパイル時間が非常に長い巨大なコードプロジェクトでgitを使用している多くの開発者の1人であると仮定します。

現在、私の個人的な日常の変更は通常制限されており、コードベースは適切にモジュール化されています。つまり、私の個人的な作業に関する限り、最初からコンパイルすることは、一度だけ支払う必要がある価格です。その後、変更したモジュールのみを再コンパイルできます。

一方、私が取り組んでいるブランチとは完全に異なるコードベースの状態を反映する（少なくとも2つの）ブランチのバグを修正しなければならないことがよくあります。これらの2つのブランチは、実際には開発チーム全体の作業の結果であり、多くの場合、モジュール全体が書き直されたり追加されたりします。バグ修正をプッシュする前にすべてをコンパイルしておくことは必須です。

私の最初のアプローチは、バグ修正が必要になるたびに開発ブランチから切り替えてから、クリーンアップ、バグ修正、最初から再コンパイル、プッシュ、元のブランチに切り替え、再度クリーンアップ、再コンパイルすることでした-これを行うための遅延は耐えられません。

次に、自分のマシンにコードベースの3つの別々のチェックアウトを保持するように移動しました。これにより、「コストのかかる再コンパイル」の問題が解決されます（すべてのブランチでの変更は再び増分になります）が、「今何を開発しているのか」という疑問が生じます。答えるのがより複雑になり（現在のディレクトリに依存するため）、これら3つのコピーの同期が複雑になります（これにより、実行する必要のあるすべてのルーチン//コマンドが3倍になりますpush）。remote updatepull

より簡単な解決策は、チェックアウトがブランチを「離れる」たびにディレクトリの状態（追跡されていない、コンパイル済みファイルを生成する場所）を保存し、そのディレクトリが存在する場合は毎回その状態を呼び出す機能を持つことです。ブランチを「入力」（チェックアウト）します。

  • この動作を実現するのに役立つgitコマンドはありますか？
  • そうでない場合、それを可能にするツールはありますか？
  • そうでない場合、gitはこの動作のスクリプトを作成するのに役立つチェックアウトフックを提供しますか？
4

3 に答える 3

1

スタッシュを使用することをお勧めします。スタッシュは必要なものにかなり近いものです。

gitの最近のバージョンでは、オプションを使用して追跡されていないファイルを隠しておくことができ--include-untrackedます。スタッシュにメッセージを送信して呼び出すこともできるので、ブランチをチェックアウトした後に、どのスタッシュを適用する必要があるかを確認できます。

#before leaving branch
git stash save --include-untracked "compiled stuff for my_branch"
git checkout another_branch
#what stash contains compiled stuff for another_branch?
git stash list
git stash pop stash@{n}

あなたは物事をより実用的にするために少しスクリプトを書くことができます...

于 2012-06-12T10:00:50.127 に答える
0

私はあなたのようなケースに対処する必要がなかったので正確な答えはありませんが、とにかく可能なヒントを提供したいと思います：Gitは単一のリポジトリに「接続された」いくつかの異なるワークツリーを使用できます（たとえば、この回答で詳細を読んでください）。したがって、複数のチェックアウトを維持する代わりに、単一のリポジトリで複数の作業ツリーを使用できます。

@CharlesBのソリューションの方が（概念的には）気に入っていることを付け加えておきますが、一方で、測定します。ファイルをブロブに変換してスタッシュに保存すると、ファイルgit stashが効果的にコピーされ、a）一時的に巨大なファイルが占めるスペースが2倍になります。ファイルシステム上のファイル。b）Gitのオブジェクトデータベースサイズのサイズに、長期にわたる未知の影響があります。

于 2012-06-12T10:09:08.127 に答える
0

私の2セント：コンパイルディレクトリをサブモジュールとして追跡します-しかし、私はまだこのgit機能を使用していないので、ドキュメントページを指すことしかできません...

于 2012-06-12T11:47:14.727 に答える