中央リポジトリとしてgitを使用する


12

私は自分で使用するためにgitをセットアップしました。したがって、「どこからでも」プロジェクトにアクセスでき、ここでパートX、ここでパートYで作業している場合にバージョンの安全性を保ち、必要に応じてマージできます。

ただし、静的IPを使用している開発マシンは1つだけです。私の脳はCVSモードで立ち往生しているので、そのマシンが他のすべてのサーバーから引き出される「中央」サーバーになるようにgitをセットアップしようとしました。

この種の作品。「マスター」Mからgit-pullを実行するマシンACが多数あります。彼らはgit pushを実行してデータを送り返します。

マスターで開発を行うと問題が発生します。まず、中央リポジトリを取得して最新バージョンを提供する方法がわからない

git reset --hard HEAD

少し過剰に思えます。また、リセットする前に中央マシンで開発を行った場合、すでにプッシュされている変更とマージする方法がわかりません。

私のメンタルモデルについての何かが外れています。助けて?


「マスター」と言うとき、マスターリポジトリのことですか、それともマスターブランチのことですか。
innaM

マスターリポジトリ
アレックスファインマン

1
gitコンテキストの「マスター」は通常、デフォルトのブランチの名前です。
innaM 2009

これはおそらく、SOに属している
ケン劉

回答:


30

中央リポジトリをむき出しにする必要があります。住んでいるマシンの名前はstatic次のとおりです。

$ ssh static git init --bare /git/myproject.git

このむき出しのリポジトリは、中心的なランデブーポイントです。開発ではなく、プッシュとプルを行うためのものです。

中央リポジトリのクローンで開発を行います。

$ cd ~/src
$ git clone static:/git/myproject.git

を使用している場合でもstatic、クローンで作業します。

$ git clone /git/myproject.git

このリポジトリで作業しているのはあなただけですが、gitドキュメントでトピックブランチと呼ばれるもので作業する習慣を身に付けてください。この直接の利点は、クリーンなマスターを保持することです。つまり、マージせずに、常に中央マスターブランチから現在のローカルリポジトリのマスターにプルできます。

例えば:

$ git checkout -b fix-bug-in-foo
$ hack
$ git add file.c file.h
$ git commit -m "Fix ..."

それは大したことではないように思えるかもしれませんが、部分的に調理された状態でそのブランチ表されているようにプロジェクトを残す自由を与えます、またはあなたのクールなアイデアがフロップであることが判明した場合、プロジェクト内で既に他のブランチで作業している他のものを壊します。無限の無料マリガン!

その夜家に帰って、新しい機能を追加したかもしれません。翌朝、あなた

$ git checkout master
$ git pull

中央リポジトリの内容を反映するようにローカルマスターを更新します。

しかし、fooバグを修正し、masterブランチに含める準備ができたとしましょう。まず、昨夜からの変更と統合します。

$ git checkout fix-bug-in-foo
$ git rebase master

このrebaseコマンドは、昨夜の新機能に加えてfooバグを修正したかのようにリポジトリを表示します。(これはのようなものsvn updateですが、より柔軟で強力です。)

それを中央マスターに入れるには:

$ git checkout master
$ git merge fix-bug-in-foo
$ git push origin master

マスターを特別なものとして扱ってきましたが、それはごく普通のことです。gitリポジトリを介して、異なるリポジトリの異なるブランチでの作業を簡単に共有staticできます。


1
素晴らしい答えは、手元にあるすべての問題を特定します。
ダンLoewenherz

私のgitインストールは--bareをgit init(古いバージョン??)のオプションとして受け入れませんが、既存のレポジトリ--bareを複製し、設定ファイルを手動で少し編集することで回避しました。
アレックスファインマン

git 1.6.4.xを実行している場合git init --bare、他の引数はありません。現在の作業ディレクトリまたはGIT_DIR環境設定が使用されます(設定されている場合)。ディレクトリ引数を取るにはgit 1.6.5.xが必要だと思います。
ダレンホール

4
これは、私がやっていることに関してこれまで見た中で最高のgitワークフローの説明です。
グレッググラハム

8

中央gitリポジトリを備えた中央サーバーがある場合、そのリポジトリはリポジトリである必要がありbareます。ベアリポジトリには、ファイルの作業コピーがありません。そのため、その中央マシンで作業している場合、中央リポジトリを直接操作するのではなく、ローカルクローンを操作します。


6

この回答はgbaconの回答に似ていますが、すでにローカルリポジトリ設定があり、中央リポジトリとして扱われるリモートマスターを作成したいというアプローチを取ります。別のアプローチから詳細を追加するだけです。

gitを使用してdot-configファイルを保存します。私は「中央レポ」と考えるものから押したり引いたりします。複数のコンピューターを介してすべてのドットファイルをリセットすると非常に便利です。

$ ssh example.com
$ mkdir dotconf.git && cd dotconf.git
$ git init --bare
$ exit

これにより、リポジトリサイトに空のベアリポジトリが作成されました。

既にローカルに既存のリポジトリがある場合、リモートサイトにプッシュできます。

$ cd ~/src/dotconf

ローカルディレクトリにchdirします。

$ git remote add origin ssh://example.com/~/dotconf.git

リモートリポジトリをオリジンとして追加すると、プッシュ/プルがそのリポジトリに作用します。

$ git push origin master

マスターをオリジンにプッシュします(以前にgitリモート経由でラベル付けされていたように)。これで、リモートリポジトリは私の「中央リポジトリ」として扱われます。すべてのgitプッシュ/プルは、オリジンと対話します。

別のホストに移動すると、クローンを介してそのリポジトリを新しい場所に簡単にプルできます。

$ git clone ssh://example.com/~/dotconf.git

リモートサーバーで開発を行う場合は、まずクローンを作成してから、ベアリポジトリにプッシュ/プルします。

$ cd ~/src
$ git clone ~/dotconf.git
$ cd ~/src/dotconf
  * do coding *
$ git push
  * check in from another location *
$ git pull

あなたはおそらくあなた自身を設定するgit config --add branch.master.remote origin必要git pullがありますので、あなたは十分に具体的ではないという不満を言わないでください。もう1つの方法は、マスターブランチを--trackリモートオリジンに設定することです。複数のブランチがある場合に便利です。


1

今日、この同じ問題を調査していました。このブログ投稿にはこの問題に関する多くの議論がありますが、多くの意見はマニが言ったことをすることです。インデックスまたは作業ツリーにコミットされていない作業があるリポジトリに誤ってプッシュしてしまった場合の対処方法など、他の可能性については、David Frenchの投稿のコメントを参照してください。「git reset –soft HEAD ^」は、作業を妨げることなく、プッシュされた変更を取り消します。


2
このブログ投稿の1つの問題は、インデックスの有用性をスキップしていることです。gitの代わりにgitを使用する方法を説明する良い記事があります-osteele.com/archives/2008/05/my-git-workflow-ワークフロー図が含まれています。
ダレンホール
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.