これは少し奇妙に聞こえるかもしれませんが、何らかの方法でネットワーク化された複数のマシンからGitで作業するための良い方法について疑問に思っています。私には2つのオプションがあるように見え、両方の面でメリットを確認できます。
私の直感は、誰もが一般的に最初のオプションで行くと言っています。しかし、私が目にする欠点は、他のマシンから常にコードにアクセスできるとは限らないことであり、毎日の終わりにすべてのWIPブランチをgithubにプッシュしたくないのは確かです。また、自分のコンピューターから直接フェッチできるように、コンピューターを常にオンにしておく必要はありません。最後にマイナーな点は、複数のブランチを最新に保つためのすべてのgitコマンドが退屈になる可能性があることです。
この状況の3番目のハンドルはありますか?たぶん、このプロセスを容易にするのに役立ついくつかのサードパーティのツールが利用可能ですか?この状況に定期的に対処する場合、何を提案しますか?
私はあなたの提案するソリューションの両方を毎日扱います。それらをうまく処理するには、2つの重要な概念があります。
production
ブランチの履歴を論理的、複製可能、デバッグ可能にするために、かなりの時間を費やしています。ただし、複数のマシンを使用する場合は、進行中の作業をコミットする必要がある場合があります。トピックブランチを使用します。少しの労力で、両方のマシンからこのブランチをpull
およびPush
できます。また、master
またはproduction
にマージする準備ができたら リベースしてより保守しやすい履歴を作成します。scripts
リポジトリ。リポジトリは頻繁に変更されないので、最初は良い考えのように見えましたが、時間の経過とともにそれはかなりの悪夢になりました。お互いの作業を上書きするのは簡単で、最終的には、作業するのと同じくらい多くの時間を航空交通に費やして、誰がリポジトリを展開しているかを制御します。最善の解決策は、各マシンにローカルリポジトリを保持し、リモートを介してそれらの間でトピックブランチを共有することです。進行中の作業を好きなだけこれらのブランチにコミットします。それらをrebase
でよりわかりやすい履歴にできる限り、実際には非常に効果的です。
1日に複数のトピックブランチで作業しているが、それぞれを個別にリモートにプッシュしたくない場合、_git Push <remote>
_はデフォルトですべての一致するブランチを_<remote>
_にプッシュします。これは デフォルトはgitの以降のバージョンで変更されます ですが、- 設定_Push.default
_を構成ファイルで設定する によって、または一致するrefspec
を指定することによって上書きできます。
_git Push <remote> :
_
すべてのマシンが常に稼働しているわけではない場合、特効薬はありません。マシンをシャットダウンする前に、変更を他の場所にプッシュする必要があります。私はプライベートサーバーにプッシュしますが、どこにでも持ち運べるドロップボックスまたはUSBキーにすることもできます。
はい、複数のブランチを中央の場所にプッシュするのは面倒になる場合がありますが、それをスクリプトで記述するのはそれほど難しくありません。 Push.sh
そのためのスクリプト。マシンでの作業が完了するたびに実行します。
私はこれに少し異なる方向から来ました(私はMercurialを使用していますが、哲学的には同じです)。これは私の考えではありません。私はそれを使用するだけで、個人的なもので機能します。
SkyDriveフォルダーにリポジトリのクローンを作成しました(ドロップボックスまたは選択した別の魔法の同期ツールでもかまいません)。次に、コミット時にSkyDriveリポジトリに自動的にプッシュするように2台のマシンのインスタンスを構成しました。
私がボックスを切り替えるときは、プルと更新を行うだけです-理論的には、複数のリポジトリにある場合でも、常に直線的に作業していることになります。
ここで重要なのは、SkyDriveリポジトリがほとんどの場合、両方のマシンで最新バージョンのコードにアクセスできるようにする手段を提供するために存在することです。追加のバックアップ。 "完了"したものはすべてKilnにプッシュされます(gitを使用していて、ゲームのプレイ方法を正しく理解している場合は、リベースを行うポイントになります)。
私が本当にしたくないのは、共有フォルダから実行することです... DVCSを使用している場合は、その利点を享受することもできます。
あなたの2つの選択肢の最初は答えです。それは「DVCS」の「D」によって暗示されています。各ユーザーは独自のリポジトリのローカルインスタンスを持ち、リポジトリは管理可能な方法で互いに対話します。
2番目の代替案を実行することもできますが、問題は、リポジトリの作業ディレクトリが1つしかないことです。したがって、作業ツリーは一度に1つの状態にしかなりません-あるブランチで作業しているJoeと別のブランチで作業しているJaneは存在しません。そのため、開発者はお互いの変更を上書きし、お互いの作業を壊すことができます。なぜ、それはバージョン管理がないかのようです!
ネットワークドライブにベアリポジトリがあり、個々のユーザーがそれをチェックインおよびチェックアウトするという、中間的な立場があります。これにより、WIP作業(はい、ローカルに保持します)をリポジトリに公開する作業から分離します。 「保存」するのではなく、「公開」します。同僚に見て使用してもらいたい作品。