最近,我开始使用gitflow
,我非常喜欢它的功能方法。通常,我会执行以下操作:启动一个新功能,在一个单独的文件中git add > commit
等中实现其逻辑。然后完成功能并合并回develop
。完全没有问题。
但是一段时间后,我遇到了一些问题。例如,我有一个文件FormMain.cs
,对于我在Controller
中的GUI来说,它基本上像一个WinForms
。因此,有许多事件,例如buttonABC_Click
或buttonXYZ_Click
。
因此,假设我的GUI上只有两个按钮(但非常重要)-> ABC和XYZ。我想实现单击按钮ABC的逻辑。没问题。我启动了一个新功能,做了一些提交。如果完成,推入,合并等操作,则开始使用按钮XYZ的功能就没有问题。
但是,如果我没有完成功能-> f.e.它需要进行一些测试,或者甚至必须以某种方式使用单击XYZ按钮的逻辑,我不需要finish
该功能。麻烦来了。如果启动新功能,则基本上是从develop
开始的(它仍然没有与feature/buttonABC
合并)。因此,我没有以前在feature/buttonXYZ
上为buttonABC编写的任何代码。然后,如果我想完成feature/buttonXYZ
->没问题,那就可以了。但是然后,如果我想完成feature/buttonABC
->合并就会出现问题,feature/buttonABC
上的cuz buttonXYZ_Click
函数为空,但是在先前合并的develop
( feature/buttonXYZ
),因为有一些代码,所以我们存在合并冲突。
所以我的问题是:我能以某种方式解决该问题吗?还是我不应该在一个文件中执行多项功能?
答案 0 :(得分:1)
您概述的方案不应导致合并冲突;实际上,这正是合并的一种日常设计。
因此,您在develop
上开始工作(从ABC
开始,后来又在develop
上开始工作(从XYZ
开始)。
X -- Y <--(featureXYZ)
/
x -- x -- D <--(develop)
\
A -- B <--(featureABC)
两个分支都没有另一个分支的工作-这就是分支的意义。
您完成XYZ
并将其合并。
X -- Y -- Z <--(featureXYZ)
/ \
x -- x -- D ----------- M1 <--(develop)
\
A -- B <--(featureABC)
现在,您完成ABC
并希望将其合并以获取
X -- Y -- Z<--(featureXYZ)
/ \
x -- x -- D ----------- M1 -- M2<--(develop)
\ /
A ----- B ----- C <--(featureABC)
现在featureABC
函数中没有代码是正确的。但更重要的是,XYZ
没有更改 featureABC
函数。所以这是合并失败的方式:
就在合并之前
XYZ
您已签出 X -- Y -- Z<--(featureXYZ)
/ \
x -- x -- D ----------- M1 <--(develop)
\
A ----- B ----- C <--(featureABC)
,并说了develop
。因此,git说要确定三个提交:一个作为“我们的”,一个作为“他们的”,以及一个作为“基础”。您在git merge featureABC
上,所以develop
是“我们的”。而且您说要合并到develop
中,所以featureABC
是“他们的”。
合并基础(或多或少)是“我们的”和“他们的”的最新共同祖先。查看我们的图,我们可以看到featureABC
-创建任何分支之前的D
提交。
因此git将计算“我们的更改”-“基础”和“我们的”之间的差,即“向函数develop
添加代码”。然后,它将发现“他们的更改”-“基本”和“他们的”之间的区别,即“向函数XYZ
添加代码”。
现在,它将尝试将“我们的更改”和“其更改”都应用到“基础”,其结果将是合并结果。仅当“我们的更改”之一与“他们的更改之一”触摸相同的代码时,才会发生冲突。
“我们的更改”向ABC
添加了代码,但对XYZ
却一言不发;和“他们的更改”将代码添加到ABC
,但对ABC
则一无所知。因此没有冲突,并且合并按预期进行。