1

私のチームの開発者が、何らかの形で彼のローカル リポジトリで変更された git コミットを修正するのを手伝ったところです。以下の Git 拡張機能のスクリーンショットから、11 時間前に彼がコミットを行ったことがわかります。彼は、すべての変更が含まれていると考えていました。彼は今朝、自分のファイルシステムの作業コピーから多数のファイルが失われていることに気付きました。リポジトリを見ると、これらはコミットされた「マスター上の追跡されていないファイル」にありました。分岐とマージでいくつか遊んだ後、それらをマスター ブランチに戻しましたが、今は問題ないようです。

このシナリオを作成するという彼のコミット中に何が起こったのかについてのアイデアはありますか? これらのファイルは .gitignore にはありません。以下に表示される .gitignore チェックインは、silverstripe-cache フォルダーの内容を無視しようとする試みです。

ここで git を使用するのは初めてなので、サポートに感謝します。

Git リポジトリの履歴

4

2 に答える 2

1

「マスター上の追跡されていないファイル」はどのコミットにもありません。つまり、それらはファイルシステムにのみ存在し、gitに追跡するように指示したことはありません。それを修正するには、不完全なコミットに追加したいすべての人に対して「git add」を実行してから、「git commit --amend」を実行します(修正するコミットがまだ現在チェックアウトされているブランチが指しているコミットであると仮定します) .

于 2012-04-18T17:11:37.010 に答える
0

ブランチ (コミット メッセージの左の点と線) の外観から、「マスター上の追跡されていないファイル」のコミットは、他のコミットと同じブランチで行われなかったように見えます。

「マスター」ブランチの履歴に実際にフォークがあったかどうかを確認するには、履歴をさらにさかのぼる必要があります。

これがどのように起こるかについての盲目的な推測:

  • 最初のコミットは別のマシンから行われ、中央リポジトリにプッシュされましたが、同僚がプルするのを忘れていました (またはプルしたと思っていたのに、奇妙なエラー メッセージが表示されました)。
  • git checkout <branch>git checkout -b <branch>まったく異なる意味を持ち、新しいユーザーを混乱させる可能性があります-見つけるのに1つか2つの驚きがありました;)。
于 2012-04-19T11:37:45.333 に答える