如果您使用的是这种形式的branch
命令(带有起点),则无论您身在何处都无所谓HEAD
。
你在做什么:
git checkout dev
git branch test 07aeec983bfc17c25f0b0a7c1d47da8e35df7af8
如果要在刚签出的位置启动新分支,则可以在没有起点的情况下运行分支:
git branch test
或如其他人回答的那样,在一个操作中跳转并结帐:
git checkout -b test
我认为您可能会对07aeec98
分支机构中的这一事实感到困惑dev
。的确,此提交是它的祖先dev
,需要更改它才能到达最新的提交dev
。但是,它们是达到最新状态所需要的其他提交dev
,而这些不一定是的历史07aeec98
。
8480e8ae
(在其中添加bb.txt的位置)不在历史记录中07aeec98
。如果您从分支07aeec98
,则不会获得引入的更改8480e8ae
。
换句话说:如果将分支A和分支B合并到分支C,然后在提交A上创建一个新分支,则不会得到B中引入的更改。
同样在这里,您有两个并行分支master和dev,您将它们合并到dev中。从master提交(比合并更早)分支出来不会为您提供dev的更改。
如果要将永久更改从master 永久集成到功能分支中,则应将master
其合并并继续。但是,这将在功能分支中创建合并提交。
如果尚未发布功能分支,则也可以基于更新后的母版将它们重新建立基础git rebase master featureA
。准备解决可能的冲突。
如果您想要一个工作流,可以在没有合并提交的情况下处理要素分支,并且仍与master中的较新更改集成,我建议以下内容:
- 每个新功能分支均基于主提交
- 创建一个
dev
在master提交上分支
- 当您需要查看功能分支如何与master中的新更改集成时,请将master和feature分支合并到中
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
!)合并到master中。