複数のマシンでGitを使用する


15

これは少し奇妙に聞こえるかもしれませんが、何らかの方法でネットワーク接続された複数のマシンからGitで作業する良い方法について疑問に思っています。私には2つの選択肢があるように見えますが、両方の利点があります:

  • 共有にはgit自体を使用します。各マシンには独自のリポジトリがあり、それらの間でフェッチする必要があります。
    • 他のマシンがオフラインであっても、どちらのマシンでも作業できます。これ自体はかなり大きいと思います。
  • マシン間のネットワークで共有される1つのリポジトリを使用します。
    • コードは常に最新であるため、マシンを切り替えるたびにgit pullを実行する必要はありません。
    • このマシンでファイル共有を使用して作業を行っていたため、他の非ホスティングマシンからコードをプッシュするのを忘れたことを心配しないでください。

私の直感では、一般的に誰もが最初のオプションを選択します。しかし、私が見る欠点は、常に他のマシンからコードにアクセスできるとは限らないことであり、毎日の終わりにすべてのWIPブランチをgithubにプッシュしたくないことは確かです。また、コンピュータから直接取得できるように、常にコンピュータの電源を入れたままにする必要はありません。最後に、複数のブランチを最新の状態に保つためのすべてのgitコマンドが退屈になる可能性があるという小さな点があります。

この状況に3番目の対処法はありますか?このプロセスを簡単にするサードパーティのツールが利用できる場合がありますか?この状況に定期的に対処する場合、何を提案しますか?


gitは分散型のバージョン管理ツールであり、gitは複製時に常にリポジトリのローカルコピーを作成します。「集中型」または「一意の」リポジトリに関する概念は、グローバル用語でgitの世界には存在しません。
-user827992

2
@ user827992私はその事実を完全に100%認識しています。集中化について何か提案したとは思わない。私が言及した唯一のことは、ファイル共有を使用している場合、物理的にファイルを保存しているという意味で、1台のマシンがホストです。これは、dvcsとはまったく別の概念です。
テセレックス

このスレッドstackoverflow.com/questions/1550378/…にはいくつかの良い考えが含まれています。ブランチのコミット、プッシュ、プル、リセット、削除はそれらの1つです(自動化されている可能性があります)
-phil294

回答:


14

提案されたソリューションの両方を毎日処理します。それらを適切に処理するには、2つの重要な概念があります。

  1. トピックブランチを使用します。私は生産の歴史は手つかずのものであると信じています。その結果、productionブランチの履歴を論理的、複製可能、デバッグ可能にするために多くの時間を費やしています。ただし、複数のマシンを使用する場合、進行中の作業をコミットする必要がある場合があります。トピックブランチを使用します。次のことが可能pullpush少しの努力で、両方のマシンからこのブランチ、そしてそれが合流する準備ができていたときmasterまたはproduction より保守歴史を作成するために、それをリベース。
  2. 他のユーザーと共有している場合を除き、ネットワーク経由で共有されている1つのレポを使用しても問題ありません。スクリプトには共有リポジトリを使用し、クリエイティブな名前をscriptsリポジトリに付けています。最初はレポが頻繁に変更されないので良いアイデアのように見えましたが、時間が経つにつれてかなり悪夢になりました。お互いの作業を上書きするのは簡単です。そして、あなたが作業しているのと同じくらい誰がリポジトリを展開するかを制御するのに多くの時間を費やすことになります。

最適なソリューションは、各マシンにローカルリポジトリを保持し、リモート経由でそれらの間でトピックブランチを共有することです。必要に応じて、進行中の作業をそれらのブランチにコミットします。あなたがrebase彼らにもっと分かりやすい歴史に喜んでいる限り、それは実際には非常に効果的です。

終日複数のトピックブランチで作業しているのに、各トピックを個別にリモートにプッシュしたくないgit push <remote>場合、デフォルトで一致するすべてのブランチをにプッシュします<remote>。このデフォルトはgitの以降のバージョンで変更さますpush.defaultが、設定ファイルで設定するか、一致するものを指定することで上書きできますrefspec

git push <remote> :

3

すべてのマシンが常に起動しているわけではない場合、特効薬はありません。マシンをシャットダウンする前に、変更を別の場所にプッシュする必要があります。私はプライベートサーバーにプッシュしますが、それはあなたがどこにでも持ち運べるドロップボックスまたはUSBキーである可能性があります。

はい、複数のブランチを中央の場所にプッシュするのは面倒ですが、スクリプトを作成するのはそれほど難しくありません。そのためのpush.shスクリプトを使用します。これは、マシンでの作業が完了するたびに実行されます。


2

私はこれにわずかに異なる方向から来ました(そして、私は水銀を使いますが、哲学的には同じです)。これは私の考えではありません、私はそれを使用するだけで、私の個人的なもののために機能します。

SkyDriveフォルダーにリポジトリのクローンを作成しました(ドロップボックスまたはお好みの別のマジック同期ツールでもかまいません)。次に、コミット時にSkyDriveリポジトリに自動的にプッシュするように2台のマシンのインスタンスを構成しました。

ボックスを切り替えると、プルと更新を行うだけの問題になります。理論的には、複数のリポジトリにある場合でも、常に線形に動作します。

ここで重要なのは、SkyDriveリポジトリが主に両方のマシンで多少なりとも最新バージョンのコードにアクセスできるようにするための手段を提供することです(より多くの場合は同様に機能しますが)。追加のバックアップ。「完了」したものはすべてKilnにプッシュされます(gitを使用していて、ゲームのプレイ方法を正しく理解している場合、それがリベースを行うポイントになります)。

私が本当にやりたくないのは、共有フォルダから実行することです... DVCSを使用している場合は、同様に利益を享受できます。


0

あなたの2つの選択肢の最初は答えです。これは、「DVCS」の「D」によって暗示されています。各ユーザーはリポジトリの独自のローカルインスタンスを持ち、リポジトリは管理可能な方法で相互に対話します。

2番目の方法を使用することもできますが、問題は、リポジトリの作業ディレクトリが1つしかないことです。そのため、作業ツリーは一度に1つの状態にしかなれません。あるブランチで作業しているジョーと別のブランチで作業しているジェーンはいません。そのため、開発者は互いの変更を上書きし、互いの作業を混乱させることができます。なぜか、バージョン管理がまったくないようなものです!

ネットワークドライブに裸のリポジトリを持ち、個々のユーザーにチェックインおよびチェックアウトさせるという、中間的な方法があります。これにより、WIP作業(はい、ローカルに保持します)とリポジトリに公開する作業が分離されます。「保存」ではなく、「公開」です。同僚に見てもらいたい作品。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.