この形式のbranch
コマンド(開始点を含む)を使用している場合は、どこにあってもかまいませんHEAD
。
何をしているの:
git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
チェックアウトした場所で新しいブランチを開始する場合は、開始ポイントなしでブランチを実行することができます。
git branch test
または、他の人が答えたように、1つの操作でそこで分岐してチェックアウトします。
git checkout -b test
07aeec98
ブランチの一部であるという事実に混乱するかもしれませんdev
。このコミットがの祖先であることは事実でありdev
、その変更はの最新のコミットに到達するために必要ですdev
。ただし、それらは最新に到達するために必要な他のコミットでありdev
、これらは必ずしもの履歴にあるわけではありません07aeec98
。
8480e8ae
(bb.txtを追加した場所)は、たとえばの履歴にはありません07aeec98
。から分岐した場合07aeec98
、によって導入された変更を取得できません8480e8ae
。
つまり、ブランチAとブランチBをブランチCにマージし、Aのコミット時に新しいブランチを作成すると、Bに導入された変更が反映されません。
ここでも同じですが、2つの並列ブランチmasterとdevがあり、それらをdevにマージしました。masterのコミット(マージより古い)からブランチアウトしても、devの変更は提供されません。
masterからの変更を機能ブランチに永続的に統合する場合は、master
それらにマージして続行する必要があります。ただし、これにより機能ブランチにマージコミットが作成されます。
機能ブランチを公開していない場合は、更新したマスターに基づいてそれらをリベースすることもできます:git rebase master featureA
。起こり得る対立を解決する準備をしてください。
マージコミットのない機能ブランチで作業しながら、マスターの新しい変更と統合できるワークフローが必要な場合は、以下をお勧めします。
- すべての新機能ブランチをマスターのコミットに基づいて
dev
マスターのコミットでブランチを作成する
- 機能ブランチがマスターの新しい変更とどのように統合されるかを確認する必要がある場合は、マスターブランチと機能ブランチの両方をにマージし
dev
ます。
dev
直接コミットせず、他のブランチをマージするためにのみ使用してください。
たとえば、機能AとBで作業している場合:
a---b---c---d---e---f---g -master
\ \
\ \-x -featureB
\
\-j---k -featureA
ブランチをブランチにマージdev
して、新しいマスターでうまく機能するかどうかを確認します。
a---b---c---d---e---f---g -master
\ \ \
\ \ \--x'---k' -dev
\ \ / /
\ \-x---------- / -featureB
\ /
\-j---k--------------- -featureA
機能ブランチでの作業を継続し、マスターブランチと機能ブランチの両方からの新しい変更をdev
定期的にマージし続けることができます。
a---b---c---d---e---f---g---h---i----- -master
\ \ \ \
\ \ \--x'---k'---i'---l' -dev
\ \ / / /
\ \-x---------- / / -featureB
\ / /
\-j---k-----------------l------ -featureA
新しい機能を統合するときが来たら、(dev
!ではなく)機能ブランチをマスターにマージします。