0

たとえば、リポジトリAを ssh 経由で別のリモート ロケーション ( B) にクローンし、 で編集しB、コミットしてから実行した場合

git push A

に戻ると、最新のプッシュされたリビジョンになっていることがわかりますが、ステージングされた変更もいくつかあります。実際には、Aそのコミットの正反対です。B私は通常、使用してそれを回避します

git checkout -f master

しかし、"-f" フラグは私を不安にさせます。たとえば、このチェックアウトを行うことで不用意に捨ててしまう便利な変更がステージングされている可能性があります。

私は何を間違っていますか?プッシュ/更新を行うためのより良い方法はありますか?

4

2 に答える 2

2

git push根本的な問題は、チェックアウトされた作業コピーを持つ裸ではないリポジトリにアクセスしていることだと思います。これについて文句を言わないことに驚いgitていますが、古いバージョンの をgit使用しているか、文句を言わないように設定している可能性があります。git pushはリモート リポジトリを更新しますが、リモートの作業コピーは更新しません。そのため、次に を見るとA、作業コピーの内容は以前のリビジョンに対応していますが、リポジトリは更新されています。明らかに、両者には違いがあります。この場合git checkout -f、おそらく最良のオプション (または) であり、その後にリポジトリをベア リポジトリにgit reset --hard HEAD変換します。A

于 2012-11-07T15:17:18.910 に答える
1

目的のコマンドは、「gitcheckout」ではなく「gitpull」になります

コミットされていない変更がある場合は、コミットする必要があります。これにより、行った変更が保存され、新しい更新が取得されます。最後に、最初に保存した変更を再適用します。

git stash
git pull
git stash pop

まだプッシュしていないローカルコミットがある場合は、実行できます。これにより、変更が巻き戻され、プッシュされたものが適用され、コミットが再適用されます。

git pull --rebase

コミットで「gitpull」を実行することもできますが、マージコミットが追加され、私の意見では履歴が汚くなり、問題が発生する可能性があります。

あなたが言った理由で、私は一般的に-forceオプションが好きではありません。役に立つものを失いたくありません。

于 2012-11-07T14:06:57.063 に答える