首先,我知道关于VCS作为单独开发人员提出了许多问题,但它们通常过于笼统。这仅涉及分支,并且仍被标记为重复...假定的重复再次被标记为另一个问题的另一个重复,该问题过于广泛且与分支无关。这就是我的问题的独特之处。

使用分支作为单独开发人员的优势(如果有)是什么?即使在单独开发环境中,我也经常看到它的建议,但是据我所见,除了使用“主”主干进行开发,并分支工作以准备发布版本的代码外,我还看不到我可以利用分支的力量(例如,划分新功能),而不会使整个开发过程过于复杂。

评论

抱歉,我承认我对StackExchange模型的经验不是很丰富,但是我是否想了解“最佳实践”或任何其他没有单一,确定性答案的问题却被皱眉了,甚至没有允许讨论?我什至在此问题的“相关”部分中也看到了许多基于观点的假设问题示例,例如softwareengineering.stackexchange.com/questions/286928或softwareengineering.stackexchange.com/questions/132730

虽然我同意曼(Man)的观点,此问题并非完全重复(范围上的差异很明显),但被链接的重复目标问题的重复确实碰巧涵盖了您感兴趣的主题-是否有那些答案没有涵盖您想了解的更多信息?

我的想法是,尽管该问题确实涵盖了该主题,但它是切线的(用户询问与分支的不同方面相关的3个不同的问题),并且实际上,由于这个原因,该问题本身因“过于广泛”而被关闭。我希望在类似的特定环境下开始讨论VCS的这一非常特定的功能。为了回答您的问题,到目前为止,这里已经提到了该问题的几个方面(在对这些答复的答复和评论中),而在您所引用的问题的答复中并未提及。谢谢大家的贡献。

作为唯一的开发人员(暂时而言),我应该如何使用Git?

Dan,再次……您链接的问题是“作为唯一的开发人员,我现在可以利用Git或GitHub的哪些功能使我受益?”。除其他外,对该问题的可能答复可能是“分支”。那不是我的问题的答案。同样,由于同样的原因,它被关闭得过于广泛。请阅读我的问题顶部的解释。我现在必须编辑我的帖子3次...

#1 楼

优势与开发人员群体的优势大致相同。通过使用始终可发布的master分支和用于开发新功能的Feature分支,可以始终释放master。在使用功能时发现重要错误?切换分支,修复,发布,切换回并继续开发。

或者这是一个爱好项目,就像您能够在此功能上进行一些工作一样,就像心情一样打击你。您基本上是在通过时间片来模拟一个多人团队。

DVCS在克隆上进行的隐式分支意味着权威存储库上的正式分支不再是与人员协调,而是更多地与协调开发方向有关,甚至一个人也可以做多个。

评论


究竟。小组也不必使用分支机构-我曾为没有使用分支机构的团队工作过。当然,这主要是因为对git不熟悉,并且所有这些团队都学会了使用分支,因为出现了不使用分支的问题,但是这些问题也将适用于单独开发人员。

– KRyan
18年1月18日在2:47

#2 楼

长期运行的开发

对于一个长期运行的开发功能(如果不适合您的发布周期),为一个人团队进行分支将非常有用。

您可以分支可以进行数月的跨度更改,并且仍然能够定期从主分支推送任何日常的错误修复或更改。

与单次“切换”相比,它具有优势分支,因为您的主分支始终处于可部署状态,并且可以保证长期运行的功能中的任何功能都不会影响其他先前测试过的代码。

实验功能

分支对于您可能希望对其进行原型设计的功能也很有用,但可能永远不会将其纳入已部署的代码中。在最终被我丢弃的分支上完成这些操作意味着您永远不会不必要地污染您的主代码库。

#3 楼

我将其用于重要的网站维护。我是唯一的开发人员,但我有一个管理员,负责开发和发布分支。

我的网站设置工作流程如下:


使可行的管理员科。进行初始提交。
签出开发分支。不做任何事情,开发功能作为合并到master的测试缓冲区。
结帐问题分支。对您的问题进行编码,完成后将其放入开发中,查看是否出现任何问题,合并冲突等...解决这些问题。

将足够多的问题合并到开发中以进行发行时,经过稳定性测试,将开发人员掌握到主。

   Master
     |
   Develop  - E
   / |  \  \
 A   B   C  D


这样,您就可以在开发中获得完整的测试集,在其中可以测试稳定性,问题等...而无需必须冒伤害Master的风险,并且如果有害的话必须回滚提交。

此外,通过使用单独的分支进行提交,您可以“离开”您已经做过的工作,重新尝试进行其他修复

在现实生活中,我通常会有一个问题分支,然后将其拉进开发中,然后再掌握。有时候这很乏味,但是至少每两个月一次,我必须丢下工作,因为有人认为我必须制造RightNow™,这样我才能快速切换回基本状态,完成此操作然后再继续我所在的地方。特别是对于耗时数周的大型项目,我可以快速切换分支。

请考虑以下情形:您始终在主分支上工作,并且拥有AwesomeCodeThing™可以使您的主人进行心脏直视手术的分支机构,然后弹出一个YugeBug™,需要紧急修复,否则成千上万的用户会向您抱怨BigProblems™
在这种情况下快速解决问题的唯一方法


检查您以前的提交,
查看上一次稳定提交的时间(可以选择是否进行诅咒)
回滚到该提交
进行修复,将修复推送到生产环境
解决您现在想要回到AwesomeCodeThing™状态的所有冲突和问题
放弃,哭泣并开始工作(可选)。

如果使用分支:


结帐母版
创建分支UrgentFix™并将其修复
将UrgentFix™拉入大师
投入生产
将大师合并到开发中
将开发者合并到AwesomeCodeThing™中
喝啤酒并继续工作。


评论


在继续之前喝啤酒是非强制性的。

–JamesB
18年1月16日在17:54

@JamesB在开始之前喝啤酒是非强制性的:)

–克里斯·西里菲斯(Chris Cirefice)
18年1月17日在14:07

#4 楼

分支使同时处理多个功能变得更加容易,这在项目过程中更改优先级时非常有帮助。

说您现在认为一个功能更为重要。也许您急需修补实时系统中的关键错误。您可能需要长时间与客户一起使用多个功能,并且可能想分别演示每个功能的进度。也许您刚刚读到一个讨厌的零日漏洞,并希望在客户了解该漏洞之前就开始使用它。

如果您为每个功能/修补程序使用分支,通常会更容易,更干净,更快捷地隔离和部署这些修改,而不是对所有内容使用单个分支。无论您是开发人员还是团队的成员,这都是正确的。

对于实际流程,我发现git flow效果很好。 Daniel Kummer的git flow备忘单是很棒的资源,即使您不使用git也值得一看。

#5 楼

正如其他张贴者所提到的那样,优点与团队合作基本上相似:能够独立开发和测试功能,为修补程序/产品部署维护单独的主分支,进行实验的能力。

对我个人而言,如果我知道我擅长的领域,我通常倾向于在硕士领域工作,这只会增加分支的开销,因为无论如何我都会合并它们。

但是,如果我对所做的更改有任何犹豫,我将分支,并且只有分支表现出预期并经过全面测试后,才进行PR /合并。这样,如果我发现回滚是最佳解决方案,那么它是一次提交而不是整个提交(我永远不记得回滚一系列提交的语法,但是一次提交很容易)。 br />