GitよりもSVNに慣れている人の多くはこれに混乱していると思いますので、誰かが明確にできるかもしれません。
いくつかの変更をコミットしてGitリポジトリにプッシュします。私はしばらく何もしません。その間、他の人々は彼らの変更をコミットしてプッシュします。それから私は彼らの変更を引っ張ろうとします、そして私git statusは私が私のものではないいくつかの変更をコミットしなければならないことを示しているのでそれをすることができません。どういう意味ですか？これらの変更をコミットするとどうなりますか？この種の「コミット」にはどのようなコミットメッセージを使用する必要がありますか？
明らかに、「コミット」のGitの概念は、update他の人の変更を取得し、自分の変更のみをコミットするという、私が慣れているSVNの概念とは大きく異なります。
どこが間違っているのかは明確ではありませんが（十分な情報を提供していない）、ここで2つのことを指摘する必要があります。
あなたのgitリポジトリと作業ディレクトリはまさにそれです：あなたのもの。変更は、あなたが要求した変更です。あなたは単にあなたがそれらを求めたことに気付いていないかもしれません（特にあなたがgitのよりあいまいな機能のいくつかを使い始めた場合）。
もちろん、これはSVNにも当てはまりますが、それは私に...
gitとsvnはどちらも「リポジトリ全体」のビューを提供できますが、svnは、「一度に1つのファイル」モードの操作を推奨します（少なくとも積極的に推奨しません）。これはgitで（ある程度）可能ですが、「すべてのリポジトリを一度に」というgitの一般的な推進力に逆らって作業するため、お勧めできません。
古いコミット全体をチェックアウトするようにgitに依頼することで問題が発生したように聞こえますが、古いコミット全体をチェックアウトするわけではありません。
$ git checkout master@{1.week.ago}
これにより、1週間前の時点でリポジトリ全体（作業ディレクトリに）が取得され、その時点で必要に応じて個々のファイルを検査できます。1しかし、たとえば、ある特定のファイルを見たいだけの場合foo.txtは、代わりにこれを実行したくなるかもしれません。
$ git checkout master@{1.week.ago} foo.txt
「これは絶対にしない」とは言いませんが、これを行う場合は十分に注意してください。「次のコミットでfoo.txtを変更して、1週間前と同じようにするつもりです。。」
具体的には、gitには、各「次のコミット」を構築する「インデックス」（別名「ステージング領域」）があります。いくつかのファイルを変更し、それらをインデックス/ステージに追加し、ステージングに満足したらアレンジメント、あなたはgit commitそのアレンジメントを新しい完全なコミットに変えるために走ります。
git checkout（）の特定のファイル形式を使用する場合、これはgitにファイルの古いバージョンを抽出し、それらをインデックスと作業ツリーに書き込むように指示します。つまり、古いバージョンのファイルを取得してワークツリーに配置し、その結果をgitに要求しているということです。git checkout [rev] path ... git add
この状況から抜け出すには、git reset --hard（このコマンドを再設定するだけでなく、インデックスとワークツリーの両方の変更を消去するなど、非常に注意してください）、またはgit checkoutファイルの最新バージョンを使用します。 ）古いバージョンをチェックして、元の状態に戻すことで混乱しました。
1より具体的には、この形式でgit checkoutは「分離されたHEAD」が残ります。コミットIDを見つけることによって特定のコミットをチェックアウトします。これにより、最初に既存の作業が上書きされないことが確認され、次に、選択したコミットに一致するようにインデックスと作業ツリーが設定され、HEADそのコミットIDを保持するように更新されます。後で、git checkout mastergitがその特定のコミットIDから変更を加えていないことを認識でき、次にgit status示すように「ブランチマスター」に安全に戻すことができます。したがって、この形式のcheckout-old / restore-currentは、作業が失われないことを確認する必要がないという点で「より安全」です。gitがあなたに代わってそれを行います。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加