3

一般的な状況：

deployer$ git clone git://gitserver/project.git
deployer$ cd project
deployer$ ./deploy
Lots of errors!
deployer$ hack --until-it-works deploy
deployer$ git commit -m "fixed it" deploy

deployment-accountおっと、適切なキーがないため、プッシュできません。では、自分のアカウントに戻りましょう。

larsmans$ cd /tmp
larsmans$ git clone /path/to/deployed/project
larsmans$ cd project

しかし、リモートが元のクローンのリモートに設定されていないため、プッシュできません。

larsmans$ git remote -v
origin  /path/to/deployed/project/ (fetch)
origin  /path/to/deployed/project/ (push)

ローカルディレクトリのクローンを作成して、リモートを取得できますか？このためのスクリプトを簡単に書くことができますが、Gitにはそれが組み込まれている可能性があります。git-clone(1);に関連するオプションが見つかりませんでした。--mirrorトリックをしませんでした。

4

1 に答える 1

4

スクリプトを作成する価値はありません。これは、プロジェクト (およびユーザー) ごとに 1 回だけ行うためです。

実際、このような状況に陥った場合、ほぼ確実にローカル リポジトリを持っていると思いませんか? 次に、最後に行うことは、新しいクローンです。

代わりに、git remote add deployed /path/to/deployed/project既存の通常のワークスペースで( )git fetch deployedを使ってやりたいことを何でもできます— 直接プッシュしたり、チェックアウトしたり、それをチェックアウトしたり、何でもしたりできます。deployed/masterrefs/remotes/deployed/masteroriginmergemerge --rebase

サーバーに ssh してそこで git を実行できる場合 (そこをハックすれば実行できます)、そこから ssh プロトコルを介して git pull を実行することもできます。また、ssh プロトコルは単純にリモート側で git を実行し、同じ git プロトコルで通信するだけなので、効率的です。したがって、ローカル マシンでは次のことができるはずgit remote add deployed host:/path/to/deployed/projectです。完全なホスト名、ユーザー名、および公開鍵でhost構成することをお勧めしますが、同様に機能します。.ssh/configuser@host

運用サーバーでは、ダウンタイムを制限するために、以前のリビジョンに切り替え、他の場所を修正してから再度プッシュすることをお勧めします。テストと本番前では、これはもちろん問題ありません。

于 2013-01-24T14:00:29.060 に答える