1

Django プロジェクト内にアプリとして配置される、通常は 1 つの小さなプロジェクトがたくさんあります。それらをコードから削除して、コードをクリーンに保ち、年を気にする必要がないようにしたいと考えています。既存のコードベースをアップグレードするときのプロジェクト。

git rm src/clients/my_project/と一緒にa (およびすべての参照を削除) を行う必要がありgit commit -m "Removed my_project"ます。プロジェクト全体が削除されたということは、それが単に別のコミット メッセージであり、ノイズの中で消えてしまうだけである場合、あまり明白ではないように思えます。

一部のクライアントがプロジェクトの再実行を要求したり、既存のものを適応させたりするため、古いコードベースを回復したい場合もありますが、ほとんどの場合は間違いありません。復元できる古いプロジェクトがあることを合理的かつ明白にするにはどうすればよいですか?

1 つの解決策は、プロジェクトごとに 1 つの git リポジトリを持つように変更することだと思いますが、これらのプロジェクトは非常に小さく、github、jenkins、デプロイ用のサーバーなどをセットアップするオーバーヘッドを保証するものではないようです。

誰かが自分の組織でこれを解決しましたか?

4

2 に答える 2

3

プロジェクトごとに個別のリポジトリを使用することをお勧めします。よりクリーンな履歴が得られ、関係のないプロジェクトの大量のコードをチェックアウトすることを心配する必要がなくなり、全体的により柔軟になります。

とはいえ、ノイズの中でプロジェクトを失うという差し迫った問題を解決するために、削除ごとにタグを作成できます。

git commit -m 'Removed my_project'
git tag -a deletes/my_project -m 'Deletion of my_project'

このようにして、タグリストですべてのプロジェクトの削除を確認でき、プロジェクトを参照する必要がある場合にそれらを簡単に見つけることができます (deletes/my_projectそのプロジェクトのコードを実際に取得するには、の親を確認することを忘れないでください)。

于 2012-09-11T11:07:01.110 に答える
0

「小規模な 1 回限りのプロジェクト」は、トピック ブランチの最適な候補のように思えます。特に、メイン プロジェクトと多くの共通コードを共有している場合。ブランチは git が得意とするところです。

小さなプロジェクトから分岐するということは、git の全機能を使用してプロジェクトを管理できることを意味します。関連するバグ修正をメイン プロジェクトから小さなプロジェクトに簡単にマージまたはリベースできます。プロジェクト間で簡単に差分を取ることができます。類似プロジェクトからサブプロジェクトを分岐できます。プロジェクトが有用であることが判明した場合は、マスター ブランチにマージして戻すことができます。

また、プロジェクトを個別に展開することも容易になります。異なるプロジェクトを異なるサーバー (または同じサーバー上の異なる仮想ホスト) にチェックアウトするだけです。

プロジェクトが独自のリポジトリを保証するのに十分な大きさになったら、そのブランチを再度複製することで、そのブランチを独自のリポジトリに簡単に変換できます。古い履歴が必要ない場合は、深さ 1 でクローンを作成するか、その履歴を押しつぶすことで削除できます。

于 2012-09-11T11:21:14.420 に答える