2

gitflow を使用して、既存のリポジトリ (「Production」) から複製したベア git リポジトリ (「Core」) を作成しました。その裸のレポを再び非裸のレポ (「Staged」) にクローンし、Staged で git フローを再初期化しました (裸のリポジトリをクローンしたときに gitflow が見つからなかったように見えるためですか?)

しかし、私は奇妙なことに気づきました。ステージングされたレポの開発ブランチにいて、テキスト ファイル (test.txt) を編集しているとします。実行するgit statusと、test.txt が変更されたことがわかります。素晴らしい。

今、私はコミットもマージもしていませんgit checkout masterが、を使用して master をチェックアウトし、再度実行git statusすると、test.txt が変更されたと表示されます!

私が間違っている場合は訂正してください。ただし、開発ブランチで行った変更は、マスター ブランチにはまったく影響しないはずです。これにより、私の「マスター」ブランチと「開発」ブランチは実際には同じブランチであると信じるようになります。

明らかに、どこかで非常にばかげた間違いを犯しましたが、どこで？わかりません。これは以前に誰かに起こったことがありますか？ここで問題を診断するための指針はありますか? 私が思いつくようなばかげた間違いはありますか?? 救済策はありますか？

(実際には、develop ブランチと master ブランチが必要であることを指摘したいと思います)

更新 開発ブランチで変更をコミットした後、実際にはマスターが正しい状態に戻り、開発が更新された状態になりました。おそらくこれが git の振る舞いなのだろうか？

4

2 に答える 2

1

git には、リポジトリ (すべてのバージョンが保持される場所)、ステージング ディレクトリ、および作業ディレクトリの 3 つの重要な領域があります。ステージング ディレクトリは、コミットする前に変更をステージングする場所です (または、「git add」コマンドを発行したときにファイルが移動する場所)。作業ディレクトリは、チェックアウトしたリポジトリに表示される一連のファイルです。

ブランチは、リポジトリのスナップショットへの単なるポインタです。アクティブなブランチを交換すると、git はステージング領域と作業領域の変更を保持しようとし、作業ディレクトリ内のすべてのファイルをブランチが指すスナップショットに変更しようとします。これを安全に行うことができない場合は、変更を隠しておくように指示します。ブランチを交換する前にステージング領域の内容をコミットする傾向があるため、ステージング領域の競合については実験していません。

特定の状況では、作業ディレクトリを変更してから、ブランチを交換しました。変更はコミット (またはステージング領域に追加) されないため、ブランチを変更すると、git は単に作業ディレクトリをマスター ブランチに戻し、コミットされていない変更を保持します。これにより、必要に応じて変更を別のブランチにコミットできます。

于 2012-03-22T08:53:07.290 に答える
1

リンクされた質問で述べたように、変更はコミットするまでどのブランチの「一部」にもなりません。その時点までは、それらは作業コピーの変更にすぎないため、git は可能な限り変更を保持しようとします。

于 2012-03-22T08:43:21.740 に答える