3

私が現在取り組んでいるプロジェクトでは、Git と Gitflow ワークフローの方法論を使用しています。私は、Git の基礎となる機能に由来すると信じている Gitflow でつまずきにぶつかりました。問題は機能ブランチに関するものです。

Subversion を使用すると、リポジトリの 2 つのブランチを作成し、それらをチェックアウトして自分のワークスペースで Eclipse プロジェクトを分離し、並行して編集することができました。これらのプロジェクトの両方のファイルを互いに分離して編集できました。あるブランチでファイルに加えた変更は、他のブランチには反映されず、その逆も同様です。

Git を使用すると、リポジトリのクローンに 2 つのフィーチャー ブランチを作成することもできます。ただし、あるブランチでファイルを作成または編集するときはいつでも、2 番目のブランチに切り替える前にそれらの変更をコミットしないと、それらの変更も 2 番目のブランチに表示されます。同様に、2 番目のブランチで同じファイルを変更し、最初のブランチに再び切り替えると、変更が行われたときにどのブランチにいたかに関係なく、これまでに行ったすべての変更がファイルに含まれます。

さらに悪いことに、2 番目のブランチに変更を追加してコミットすると、2 番目のブランチのファイルには 1 番目と 2 番目のブランチで行われたすべての変更が含まれ、変更は最初のブランチから完全に消えてしまいます。

コミットする前に、ファイルとファイルへの変更が両方の機能ブランチに反映されないように、機能ブランチを互いに分離する方法はありますか?

別のブランチに切り替える前に変更をコミットするか、機能ごとに個別のリポジトリクローンを作成するだけでよいことに気付きました。ただし、これらのアプローチはどちらも、ブランチを持つ目的を無効にしているようです。

4

3 に答える 3

4

git のブランチは、subversion や CVS と同じ意味を持ちません。

これは私が同僚と最近経験したことです。彼女は自分のプロジェクトを管理するために git リポジトリを使用していました。それ以前は、CVS を使用していました。彼女は 2 つのサブディレクトリを作成し、関連するはずのブランチに応じて名前を付けました。彼女のワークフローは、branchA と cd をサブディレクトリ A にチェックアウトするというものでした。その後、機能 B に取り組みたいときに、branchB と cd をサブディレクトリ B にチェックアウトしました。

これは通常、git の動作方法を理解していない人や、CVS の悪癖を持っている人向けの方法です。

git でブランチまたはタグをチェックアウトすると、これはプロジェクトにとって GLOBALになります。

同じプロジェクトの 2 つの同時ブランチが必要な場合は、プロジェクトの 2 つの別個のクローンが必要で、それぞれが独自のブランチでチェックアウトされます。

于 2013-07-19T15:38:08.123 に答える