11

私が慣れていること：

  • サーバー上のアーカイブ (NY、IN、NC)
  • 私の開発マシンで：
    • ~/work という名前のディレクトリ
    • ~/work/NY/devproject、~/work/NC/project などのサブディレクトリ
    • ~/work/NY/release/1.3/project、~/work/NY/test/1.3b/project などのサブディレクトリが作成されることも珍しくありません。
    • ~/proxy/NY、~/proxy/NC などの名前のディレクトリには、読み取りのネットワーク トラフィックを減らすために、アーカイブの使い捨てローカル キャッシュが含まれていることがあります。これらのディレクトリはいつでも削除できます。
  • ~/work/... を削除してアーカイブから再作成するスクラッチ ビルド

しかし、意味をなさない DVCS では

  • アーカイブは私の開発マシンにありますが、バックアップ上の理由から、ニア クローンはリモート マシンにあります。
  • スクラッチ ビルドを行うと、アーカイブ全体を削除して再度プルする必要があり、コストがかかるようです。
  • たくさんの git である ~/git/git.git/git という名前のディレクトリがあるようです。

人々はすべての開発を ~/git で行っていますか? 開発版、テスト版、リリース版、大規模クライアント向けの 1 回限りのバージョンを使用する必要がある場合、これらは ~/git の下にありますか? それとも独自のツリーの別の場所にあるのでしょうか? サードパーティのコンポーネントはどこに行きますか? これは SO には大きすぎますか (本を読む必要がありますか)、または ASCII ツリー図で答えることができますか?

4

2 に答える 2

12

私は、各プロジェクトを開発ディレクトリに保持することを好むという点で、TEDの回答に同意します。しかし、私がターミナルでbashリストを見ているとき、私は3つのことを簡単に見るのが好きです。

  1. これはどのタイプのリポジトリですか---Git、Mercurial、またはSubversion
  2. 疑似中央リポジトリはどこに保存されていますか---Github.com、Bitbucket.org、GoogleCodeなど。
  3. 疑似中央リポジトリの所有者

プロジェクトに次の命名規則を使用することで、これを簡単に実行できることがわかりました。

~/development/project.whatwhere.who

Mercurialを使用してローカルプロジェクトのクローンを作成するのは一般的であるため、次のようにディレクトリ構造に1つのレイヤーを追加します。

~/development/project.whatwhere.who/project/   # Initial clone from remote repo
~/development/project.whatwhere.who/project.local.blah_descriptor/  # Local hg clone

私が使用する規則は次のwhatwhereとおりです。

  • github---github.comに保存されているGitリポジトリ
  • gitorious---gitorious.orgに保存されているGitリポジトリ
  • git---他の場所に保存されているGitリポジトリ
  • gitsvn---別の場所に保存されているgit-svnを使用して複製されたSubversionリポジトリ
  • hgbit---bitbucket.orgに保存されているMercurialリポジトリ
  • hg.gcode---Googleコードに保存されているMercurialリポジトリ
  • hg---他の場所に保存されているMercurialリポジトリ
  • svn.gcode---Googleコードに保存されているSubversionリポジトリ
  • svn.sforge---Sourceforge.netに保存されているSubversionリポジトリ
  • svn.work----当社のsvnサーバーに保存されているSubversionリポジトリ
  • svn---どこかに保存されているSubversionリポジトリ

規則は、who単に目的の人のユーザー名です。

以下はいくつかのプロジェクトの例で、すべて私の~/development/ディレクトリにあります。

fabric.github.bitprophet      # Bitprophet's fabric project cloned from Github
fabric.github.myusername      # My fork of the fabric project from Github
virtualenv.hgbit.ianb         # Ianb's virtualenv project cloned from Bitbucket
growl.hg.gcode                # Growl project cloned from Google code
ledgersmb.svn.sforge          # LedgerSMB project checked out from Sourceforge
coldfire.gitsvn               # Coldfire Subversion project at work cloned using git-svn
coldfire.svn                  # Coldfire Subversion project at work checked out with svn

プロジェクトが多すぎる場合にプロジェクトを整理しやすくするために、整理~/development用のディレクトリのすぐ下にレイヤーを追加することをお勧めします。たとえば、次のディレクトリを作成できます。

~/development/workprojects/
~/development/opensrcprojects/
~/development/personalprojects/

注：私は通常、DVCSにGitを使用しているため、この回答はおそらくその方向に傾いています。

于 2009-09-16T16:19:40.860 に答える
8

Git の仕組み上、リポジトリ (またはブランチ)の作業ディレクトリを別のリポジトリの作業ディレクトリの下のディレクトリに配置することは望ましくありません。子ディレクトリの内容を親のリポジトリに入れたいと思うでしょう。

すべてのブランチが兄弟ディレクトリである場合、それは問題なく機能します。

私がよく行うのは (Git、cvs、または (ick) SourceSafe の使用に関係なく)、Development ディレクトリがあり、各プロジェクト、ブランチなどはそこのサブディレクトリです。

于 2009-03-31T14:47:09.193 に答える