2

要するに：

新しい git リポジトリgit pullのリモート ブランチからコードをプルした後、コードをリセットする前の状態に戻すことはできますか?

長い話：

スクリプトを含む 2 つのフォルダーがあり、1 つのフォルダーは他のフォルダー内の別のバージョンのファイルを表します。バージョン管理を適用するには、他のフォルダーと比較してリビジョンが少ないフォルダーを使用して github に git リポジトリを作成することから始め、両方のフォルダーを表す同じ内容の 2 つのブランチを作成します。

最新のリビジョンを持つフォルダーをリモート ブランチに同期するには、そのフォルダーで次の操作を行います。

git init
git remote add origin [GITHUB_REPO]
git pull origin [BRANCH_NAME]:[BRANCH_NAME]
git add .
git commit -m "Latest revision."

git add .以前にワークフローを数回テストしましたが、後で実行する直前にgit status変更が表示されず、追跡されていない新しいファイルのみが表示されることに気付くまで、何も問題はないようです。

git pull一部のファイルがリモートで上書きされることに気付いたので、実行する前の状態に元に戻す必要がありますが、これpullが最初のアクションであり、その前にコミットがないため、前の状態にリセットすることはできませんpull。

これは次の結果ですgit reflog show。

edbfd0d HEAD@{0}: commit: Import code from development environment.
da39602 HEAD@{1}: checkout: moving from master to development

私がやったことは次のとおりです。

git reset HEAD@{1}

そして、これは問題を解決しません。最後のコミットを元に戻すだけで、上書きされたファイルはgit pullまだ戻ってきません。役に立った場合、サーバー上の git のバージョンは 1.7.1 で、私のローカル マシンでは 1.8.2.1 です。彼らの行動が異なるのも不思議ではありません。

--

さらに調査git pullした結果、サーバーでの の動作がローカルの開発マシンとは異なることがわかりました。サーバーでは自動的にマージされるようですがgit pull、私のローカル開発では、マージ時に上書きされる可能性のあるファイルがあることがわかります。

git pullこれにより、サーバー内のファイルは、追跡されていないファイルを含む既存のファイルで改訂の少ないバージョンを自動的に使用しますが、ローカル開発では、変更されたファイルを追加して更新されたバージョンを使用できます。

4

2 に答える 2

4

何git pullが行われたかに応じて、2 つのシナリオが考えられます。のマージ フェーズでgit pull早送りマージが行われた場合は、 の直後に次の操作git pullを実行できます。

git reset --hard HEAD@{1}

これにより、HEAD とブランチ ポインターが、実行する直前の場所にリセットされますgit pull。の後に他のことを行った場合はgit pull、実行git reflog HEADして、本当にリセットしたいエントリを決定する必要があるかもしれません。

git pull早送りができなかったか、早送りではないマージを実行するように要求されたために、新しいマージ コミットが作成された場合でも、上記のコマンドは機能します。ただし、この場合、次のコマンドを使用して、現在のコミットの最初の親にリセットすることもできます。

git reset --hard HEAD^1

繰り返しますが、その間に他のことを行った場合は、reflog を確認し、代わりに 1 以外の番号で最初のコマンドを使用する必要があるかもしれません...

于 2013-07-16T19:35:53.123 に答える
1

そのフォルダーで次のことを行います。

git init
git remote add origin [GITHUB_REPO]
git pull origin [BRANCH_NAME]:[BRANCH_NAME

実際、それは良い考えではありません。git に関する重要なルールの 1 つは、「汚れた」作業ツリー (つまり、チェックインされていないファイル) に対して複雑な操作を実行してはならないということです。

この場合、ファイルを含むディレクトリにリポジトリを作成しましたが、ファイルをコミットしていません。そのため、ファイルは git に認識git statusされないため、「追跡されていない」と表示されます。git pull自動的にマージを試みるようになりましたが、ダーティ ツリーとのマージには問題があります。git はデータを上書きしないようにしますが、マージが思い通りにいかない場合、ファイルの古いバージョンがコミットされていないため、一部の変更を元に戻す簡単な方法はありません。

したがって、より良いアプローチは、最初に空のディレクトリで init/remote add/pull を実行することです (または単にリモート リポジトリを複製します)。

git clone [GITHUBREPO]
git checkout BRANCH_NAME # note: This will create a local branch from the remote

これにより、リモート ブランチのクリーン コピーが得られます。次に、最新バージョンのフォルダーからファイルをコピーして、ブランチの意図した新しい状態を作成します。

rm oldfiles; cp -a ../folder2/* . # or similar

次に、これをすべてコミットします。

git add .
git commit -m "Files from folder2"

その時点で、再びきれいな作業ツリーが得られます。これで、データを失うことを恐れることなく、他のブランチとマージしたり、変更をプッシュしたり、より多くのブランチをマージしたりできます。問題が発生した場合は、いつでも古いコミットに戻ることができます。

ノート：

問題は、ファイルがリモート ブランチで上書きされ、プルする前の状態に元に戻すことができないことです。これが最初のアクションであるためです。

それは通常起こるべきではありません。git pullがローカルのコミットされていないファイルと競合する場合（あなたの場合のように）、エラーgit pullで中止する必要があります。このような：

error: Untracked working tree file 'myFile' would be overwritten by merge.

そうでない場合は、これらの競合を無視するように git が構成されている可能性があります (デフォルトではありませんが、可能だと思います)。とにかく、汚い作業ツリーとマージしないのであれば、それは問題にはなりません。

于 2013-07-17T11:10:37.220 に答える