99

SVNを使用すると、サーバー上に1つの大きなリポジトリを保持し、いくつかのマシンでチェックアウトしました。これは非常に優れたバックアップシステムであり、どのマシンでも簡単に作業できました。特定のプロジェクトをチェックアウトしてコミットし、「マスター」プロジェクトを更新するか、すべてをチェックアウトすることができます。

現在、さまざまなプロジェクト用のgitリポジトリがたくさんあり、そのうちのいくつかはgithubにあります。私はまた、git-svnコマンドを介してインポートされた前述のSVNリポジトリを持っています。

基本的に、すべてのコード（プロジェクトだけでなく、ランダムなスニペットやスクリプト、CV、作成した記事、作成したWebサイトなど）を1つの大きなリポジトリに入れて、リモートに簡単に複製できるようにするのが好きです。マシン、またはバックアップとしてのメモリースティック/ハードドライブ。

問題は、それがプライベートリポジトリであり、gitが特定のフォルダのチェックアウトを許可しないためです（別のプロジェクトとしてgithubにプッシュできますが、変更はマスターリポジトリとサブリポジトリの両方に表示されますリポジトリ）

gitサブモジュールシステムを使用することもできますが、それも私が望むようには機能しません（サブモジュールは他のリポジトリへのポインタであり、実際のコードが含まれていないため、バックアップには役に立ちません）

現在、git-reposのフォルダー（たとえば、〜/ code_projects / proj1 / .git /〜/ code_projects / proj2 / .git /）があり、proj1に変更を加えた後git push github、ファイルを〜/にコピーします。 Documents / code / python / projects / proj1 /そして単一のコミットを実行します（個々のリポジトリにある多数のコミットの代わりに）。次にgit push backupdrive1、git push mymemorystickなどを行います

それで、質問：あなたの個人的なコードとプロジェクトをgitリポジトリでどのように行い、それらを同期してバックアップし続けるのですか？

4

6 に答える 6

75

特定の Git リポジトリに関係のないデータを配置しないことを強くお勧めします。新しいリポジトリを作成するオーバーヘッドは非常に低く、これは異なる系統を完全に分離しておくことを可能にする機能です。

その考えと戦うことは、不必要に絡み合った歴史に終わることを意味し、その結果、管理がより困難になり、さらに重要なことに、「考古学」ツールは結果として希薄化するために役に立たなくなります. また、おっしゃったように、Git は「クローンの単位」がリポジトリであると想定しており、分散型の性質上、実際にはそうしなければなりません。

1 つの解決策は、すべてのプロジェクト/パッケージなどを保持することです。 次のように、祝福された階層の下に独自の裸のリポジトリとして（つまり、作業ツリーなしで）：

/repos/a.git
/repos/b.git
/repos/c.git

いくつかの規則が確立されると、管理操作 (バックアップ、パッキング、Web パブリッシング) を完全な階層に適用することは簡単になります。これは、「モノリシック」SVN リポジトリと完全に異なる役割を果たします。これらのリポジトリでの作業も SVN ワークフローに多少似ていますが、 ローカルのコミットとブランチを使用できる点が追加されています。

svn checkout   --> git clone
svn update     --> git pull
svn commit     --> git push

複数の関係者間の同期を容易にするために、各作業クローンに複数のリモートを含めることができます。

$ cd ~/dev
$ git clone /repos/foo.git       # or the one from github, ...
$ cd foo
$ git remote add github ...
$ git remote add memorystick ...

次に、各「ソース」からフェッチ/プルし、ローカルで作業してコミットし、次のような準備ができたら、これらの各リモートにプッシュ (「バックアップ」) できます (同じコミットと履歴をプッシュする方法に注意してくださいそれぞれのリモコン!):

$ for remote in origin github memorystick; do git push $remote; done

既存の作業リポジトリ~/dev/foo をそのような裸のリポジトリに変える最も簡単な方法は、おそらく次のとおりです。

$ cd ~/dev
$ git clone --bare foo /repos/foo.git
$ mv foo foo.old
$ git clone /repos/foo.git

これは -- とほぼ同等ですがsvn import、既存の「ローカル」履歴を破棄しません。

注：サブモジュールは、共有された関連 系統を含めるためのメカニズムであるため、解決しようとしている問題に適切なツールとは考えていません。

于 2008-08-31T18:17:07.027 に答える
28

彼が推奨するダミアンの答えに追加したい：

$ for remote in origin github memorystick; do git push $remote; done

1 つのコマンドですべての個々の実際のリモートにプッシュする特別なリモートを設定できます。http://marc.info/?l=git&m=116231242118202&w=2で見つけました：

したがって、「git push」(同じブランチを複数回プッシュすることが理にかなっています) の場合、実際に私が行っていることを行うことができます。

  • .git/config には以下が含まれます。

    [remote "all"]
url = master.kernel.org:/pub/scm/linux/kernel/git/torvalds/linux-2.6
url = login.osdl.org:linux-2.6.git

  • そしてgit push all master、「マスター」ブランチを両方
    のリモート リポジトリにプッシュします。

次の構文を使用すると、URL を 2 回入力する手間を省くことができます。

[url "<actual url base>"]
    insteadOf = <other url base>
于 2009-04-23T00:24:42.550 に答える
3

また、これを処理するための提案された方法についても興味があり、私が（SVNで）使用している現在のセットアップについて説明します。私は基本的に、独自のbinとlibdirを含むミニファイルシステム階層を含むリポジトリを作成しました。このツリーのルートには、これらのbin、libなどの他のdirを適切な環境変数に追加するように環境をセットアップするスクリプトがあります。したがって、ルートディレクトリは基本的に次のようになります。

./bin/            # prepended to $PATH
./lib/            # prepended to $LD_LIBRARY_PATH
./lib/python/     # prepended to $PYTHONPATH
./setup_env.bash  # sets up the environment

/binと/libの中には、複数のプロジェクトとそれに対応するライブラリがあります。これが標準のプロジェクトではないことはわかっていますが、グループ内の他の誰かがリポジトリをチェックアウトし、「setup_env.bash」スクリプトを実行して、すべてのプロジェクトの最新バージョンをローカルに配置するのは非常に簡単です。チェックアウト。/ usr/binまたは/usr/ libのインストール/更新について心配する必要はなく、複数のチェックアウトと、チェックアウトごとの非常にローカライズされた環境を簡単に設定できます。誰かがリポジトリ全体をrmするだけで、プログラムのアンインストールについて心配する必要はありません。

これは私たちにとってはうまく機能しており、変更するかどうかはわかりません。これに伴う問題は、この1つの大きなリポジトリに多くのプロジェクトがあることです。このような環境を作成し、プロジェクトを独自のリポジトリに分割するgit / Hg / bzrの標準的な方法はありますか？

于 2010-04-28T17:54:57.867 に答える
3

、必要な状況に遭遇していないため、gitリポジトリのネストはまだ試していません。#gitチャネルで読んだように、リポジトリをネストすることでgitが混乱しているようです。つまり、gitリポジトリ内でgit-initを実行しようとしています。ネストされたgit構造を管理する唯一の方法は、git-submoduleまたはAndroidのrepoユーティリティを使用することです。

あなたが説明しているそのバックアップの責任については、私はそれを委任すると言います...私にとって、私は通常、IT技術者がバックアップ戦略によって定期的にバックアップしている職場のネットワークドライブに各プロジェクトの「元の」リポジトリを置きます。選択。シンプルで気にする必要はありません。;）

于 2008-08-31T15:11:54.320 に答える
1

ネストされた git リポジトリを持つ別の方法がありますが、それはあなたが求めている問題を解決しません。それでも、解決策を探している他の人のために、私は：

最上位の git repo で、ネストされた git repo を含む .gitignore のフォルダーを非表示にします。これにより、2 つの別個の (ただしネストされた!) git リポジトリを簡単に作成できます。

于 2010-08-08T19:44:04.587 に答える