0

以前に他の DVCS システムを使用したことがありますが、git は初めてです。ですから、意図したとおりに使用する方法について、間違った仮定をしていると思います。

私は自分の仕事の大部分を行うマスターと開発ブランチを持つ RepoA を持っています。しばらく前に、RepoA から RepoB のクローンを作成して「BigFeatureA」の作業を開始し、開発ブランチでもこれを行いました。私は BigFeatureA を使い終わっていませんが、最新のコードを使用して BigFeatureA の作業を続けられるように、複製を行ってから RepoA で行われたすべての変更を引き継ぎたいと考えています。(現時点では、RepoA では開発ブランチとマスター ブランチは同じですが、もちろん、そうでない場合もあります。) RepoB で動作する XCode を使用して、RepoA 開発ブランチからプルを行いました。競合があり、それを解決し、プル ボタンを有効にしてからプルを実行しました。

現在、RepoB では、持ち込まれたすべての変更は「コミットされていない変更」であり、ファイルには「M」または変更が表示されています。そのため、RepoA からはコミット メッセージなどは一切送信されず、ソースが変更されただけです。これは私が期待したものではありません。これは XCode の git ワークフローのバージョンですか、それとも git merge の仕組みですか?

私の最後のワークフローは、BigFeatureA が完了したときに RepoB を RepoA にプッシュすることでした。それを行うことと、他の方向に進むこと、つまり、RepoA にいることと RepoB からプルすることに違いはありますか?

(さらに読むと、おそらく RepoB に「BigFeatureA」ブランチを作成し、そこにある開発ブランチで RepoA からプルを実行し、次に BigFeatureA ブランチから開発ブランチにマージする必要があったことを示唆しています。ブランチとレポの間のマージ?)

4

1 に答える 1

0

いいえ、これは予期された動作ではありません。すべての変更を変更されたファイルとして残していた理由は、マージを「あきらめた」ためです。

投稿時点で知らなかった情報 → .gitignore ファイルに .DS_Store を入れることを知らずにリポジトリを作成していました。私はそこに *.DS_Store を長い間持っていましたが、おそらくそれを行った後、適切にクリーンアップしていませんでした。リポジトリに「多くの」.DS_Storeファイルがあり、それを.gitignoreファイルに入れることは、「以前に行ったことから」ではなく、「これから」を意味するように見えます。

上記のように、Xcode は .DS_Store ファイルが変更されていると不平を言い、そのタイプのファイルの競合を解決する方法がわからなかったため、あきらめました。ファイルが RepoA で既に削除されているという事実を処理せず、RepoB でも削除する必要がありました。次に、ファイル リストに .DS_Store と表示されていましたが、メイン フォルダーの .DS_Store ではなく、ファイル階層のどこかにある 1 つまたは複数の .DS_Store ファイルでした。そのため、コマンド ライン経由で git の最上位レベルの .DS_Store を何度削除しても、Xcode は満足することはありませんでした。そのため、どの.DS_Store ファイルについて話しているのかわかりませんでした。Xcode は、プロジェクト内に同じ名前のファイルを複数持つことを得意としていないようです。

修正は、階層内のすべての .DS_Store を見つける別のSO 投稿に従い、それらを git rm してから、コマンド ライン経由ですべて git commit することです。その後、Xcode のマージが完了し、プルから変更されたファイルが残ることはありません。

于 2012-11-28T18:40:26.933 に答える