我想在git中使用\
作为工作流。但是我对git-flow
有疑问。例如,我有四个分支:
git log --graph
我该怎么办?或哪种工具最适合我的需求?
答案 0 :(得分:2)
您通常无法做到这一点。您可以针对特定情况进行伪造,这对您可能已经足够了;但是您必须自己做,因为Git不需要。
原因很简单:显示的图形是一个谎言。它试图假装Git继续前进。 Git不会: Git向后工作。
在Git中,提交通常不在单个分支上 。而是,提交同时在许多分支上。这是该图的文本表示形式:
master: A--B-----------------------P--...
\ /
release: \ K--M
\ / \
develop: C-----F------I------R--...
\ \ /
feature1: D--E-----H
\
feature2: G--J--L--N--...
这也是一个谎言:例如,意味着A
上的提交master
仅 。实际上,提交A
在每个分支上。
由于有...
个部分我们看不到,所以很难确定G-J-L-N-...
的提交是否在多个分支上:我们需要像Git一样从头开始,去看现实而不是说谎。不过,我们可以肯定地说,这些提交现在肯定在feature2
上。同时,提交C
和F
在 feature2
和 develop
上。我们不能确定唯一包含D-E-H
序列的分支是feature2
:所有四个提交都在feature1
上确定,但也确定地< / em>在{{1}上,因为develop
在I
上,并且develop
返回到I
。同时,提交H
在K
上,但是由于release
返回到K
,因此I
在{{1}上也是 };由于I
会同时追溯到release
和I
,因此这两个提交也都在F
上。
简而言之,这里的问题是我们正在尝试向前。 Git无法继续工作。从分支上的 last 提交开始, Git向后工作。假设实际上我们确实拥有这些最后的提交,然后重新绘制所有内容:
H
这幅图是真实的,而不是谎言(嗯,大概是在某个时候的某个仓库)。
我在此处添加的三个名称是我们需要保留所有显示的提交的唯一名称,因为它们是仅有的三个最后提交。我们可以添加另一个名称,例如release
,指向例如A--B-----------------------P <-- master
\ /
\ K--M
\ / \
C-----F------I------R <-- develop
\ \ /
D--E-----H
\
G--J--L--N <-- feature2
,并添加更多我们喜欢的名称:
feature1
最后一张图是绘制事物的一种真实方法(不一定是 the ,而是 a )。名称H
标识提交A--B-----------------------P <-- master
\ /
\ K--M <-- release
\ / \
C-----F------I------R <-- develop
\ \ /
D--E-----H <-- feature1
\
G--J--L--N <-- feature2
,我们和Git可以从release
向后进行工作以找到提交M
,然后从M
返回到K
,并同时运行到K
和I
上。然后从F
和H
开始,我们可以同时回到F
和H
,再回到C
(也可以回到E
) ;然后从D
回到C
,然后回到C
。因此B
的所有提交都可以通过A
到达。
如果删除名称A-B-C-D-E-F-H-I-K-M
,则提交没有任何反应。提交仍然存在。它们只是不再包含在release
分支中,该分支不再存在。它们仍然包含在release
中,因为release
始于-结束于?— master
,向后master
和P
都起作用。由于M
到达B
,因此从P
也可以到达 M
的每个提交。
如果您认为这是沿着单向街道行驶,那么在单向街道网络中,您就在通往启蒙的道路上。有关(更多)更多信息,我建议您浏览网站Think Like (a) Git。请密切注意以下想法:要让您的工具隐藏(某些)从您那里提交(在Making Sense of the Display页上)。
请注意,还有其他版本控制系统以您希望Git正常工作的方式工作。特别是,Mercurial与Git非常相似,不同之处在于,提交永远在其进行的分支上。每个提交仅在一个分支上。无论使用分支名称做什么,包含分支的提交都将保持不变。在Git中,由于名称在提交保持不变的情况下移动,因此包含任何给定提交的分支集总是在变化!如果您不准备在Git中发生这种情况,那么使用Git时您将很痛苦。