Git与颠覆多个大型开发分支

在我的公司，我们正在使用Subversion。我们的项目开发流程包含一个“实时”分支代码（这是我们的实时Web服务器上的代码），一个针对较小项目的通用开发分支，然后每个较大的项目都有其独立的分支。在任何特定时间，我们通常至少有两个大型项目正在开发中。将这些合并回到活动分支可能是一种痛苦，但更大的痛苦是大型项目1上线后，大型项目2将在晚些时候上线，而合并过程只是......凌乱。Git与颠覆多个大型开发分支

我一直在SVN中做的事情是每天从开发分支中生活（所以发生任何错误修复等）。但是较大的项目合并过程仍然很混乱，我想知道Git是否会更清洁。作为SVN发生的一件坏事的一个例子，我们将在开发中使用一个小功能，将其合并到生活中，然后当执行活动后退时，SVN会尝试再次将该功能合并回dev（导致冲突），除非我们手动取消选择合并中的提交。从我的理解中，Git足够“聪明”，足以知道提交是在dev中产生的，因此它不会尝试将它合并回来......但我的理解可能是错误的。我还听说Git更擅长自动处理复杂的合并，就像我们正在做的那样。

因此，第一个问题是：Git是否比SVN明显好于我们正在做的事情，或者我们是否仍然可能遇到相同的问题，并且如同毛茸茸的合并？

第二个问题：是否有其他集成方法可能对我们的方案更好？特别是，我正在阅读一篇关于promiscuous integration的文章，虽然看起来不错，但看起来好像越来越难以让更多的项目同时进行。但是，我再也不指望我们同时拥有三个以上的大项目，通常只有两个。对于我们的许多项目来说，持续集成并不是一种选择，因为它们往往是全有或全无的项目，或者如果被部分推送（例如，我们最近重新设计我们的结账流程），会对用户造成冲击。对于我们的情况，This article也是一种很好的方法。

来源

2013-03-01 Mike Todd

检查[本问答]（http://stackoverflow.com/a/10340877/236871），基本上Git在合并时比SVN好，因为它们如何存储信息以及如何执行合并过程。 Git存储完整的快照，SVN存储增量/差异。在合并时，Git进行3路合并，SVN重新应用补丁/差异。 – KurzedMetal 2013-03-01 16:34:44

有一个关于高级分支和合并的免费网络研讨会。 http://go.wandisco.com/advanced-branching-merging。html – vinnyjames 2013-03-01 23:12:30

作为一个说明，我们已经转移到Git，并发现它好多了 - 合并期间几乎没有冲突。主要的难点在于，当我们将一些代码合并到master时，发现一个严重的bug已经逃脱了QA，在master进行了进一步的合并/提交之后。在Git中支持这一点比在SVN中困难得多。但总的来说，Git对我们来说比SVN更好。 – 2013-11-20 16:38:06

尝试git，你不会回去。

如果你没有做任何合并（即在一个小团队中工作），我会说坚持Svn。所有其他情况，包括你的确定 - git会让你的生活更轻松。

当谈到分支，合并和解决冲突时，Git比SVN更好。例如，想想SVN“每个分支一个结帐目录”场景。而且，git在合并/分支方面非常优秀，有些人正在使用git-svn来合并SVN分支。想象一下，相反...

另外，This answer是很好的解释Git vs SVN。

来源

2013-03-01 16:19:04

+1，但请确定您的链接。 ;） – carlspring 2013-03-01 18:44:23

我想如果你习惯了SVN继续使用它。 Git非常好，但你仍然有学习曲线，开始使用它会有破坏性。 Svn工作正常，所以也许你可以改善公司“分支”和“项目”的结构。这听起来像你有一个与工具无关的结构性问题。无论如何，这只是我的愚见。我希望它有帮助。

来源

2013-03-01 16:13:14

我们让人们使用他们觉得最舒服的工具。 git-svn为那些更适合或希望学习专业开发git的人提供了git-lite体验。有一个名为SubGit的项目可以让你拥有SVN和Git给任何想使用的人。

一般来说，根据功能分支开发风格进行分支/合并的人往往更喜欢git。几个团队成员独立于团队的其他成员进行合作也会少得多。

来源

2013-03-01 16:34:18

“Git有一条学习曲线” - 是真的。另一方面，在学习曲线之后，开发人员开始更好地理解源控制系统的概念。他们变得更有组织，并以更实际的方式做事。

是的，如果您需要将存储库从Subversion迁移到Git，您的分支布局将会不同（等等）。但历史将全部存在。

通常较慢的学习曲线的一个原因是，相当多的命令有不同的名称，并且需要一些时间才能绕过它。

Git对于大型存储库（数据方面）并不好。但是，您始终可以对您的系统进行模块化并提取其中的一部分。这个概念的好处通常不是很好理解（在公司和公司有很多糟糕的传统设计），以便得到足够的赞赏。如果你有一个巨大的存储库（比如SVN/Perforce下类似的情况），你可以将所有项目的所有代码放在一个地方。但是，Git允许您将项目的整个历史记录保存在本地克隆中。想象一下，如果你已经模块化了所有的东西 - 你可以将模块的完整历史作为单个实体检出。 Git遵循的原则是你应该为每个项目建立一个仓库（至少这是大多数人采用它的原因）。维护一小段代码总是更简单，更快，更整齐。分支，合并，重写历史，将历史目录和历史记录提取到不同的新存储库中......所有这一切都非常简单。

Git是你应该尝试的东西。即使你害怕它。阅读ProGit书籍。这很好，有很好的例子和解释。你会很快发现Subversion的局限性。我曾经从早期的CVS开始工作，然后迁移到Subversion并进行了多年的管理。当我开始处理git时（一旦我读完了这本书），我真的意识到这个版本控制是多么的聪明。

真的，如果你尝试了一段时间并且付出一定的努力，那么就不会有回头路了。

如果你想开始并快速学习它，我建议在GitHub中设置一个项目并稍微玩一下。他们有很好的解释让你快速起步。

来源

2013-03-01 18:38:02 carlspring

较大的项目合并过程仍然凌乱，我想知道它是否会与Git更干净。

号你的问题都没有（主要是，我能理解的过程）中使用的工具，他们是发展过程中的组织和管理的更重问题。更换工具不会破坏坏习惯。（顺便说一句，我从来没有见过描述过的“backmerge怪异”，同时使用sync-merge分支到regurarly--并且将这些分支合并到后来的主干中），但是“混乱在脑海中” 。 Git-merge是（通用的）更强大，但你会踩在其他耙，这是更多的Git

来源

2013-03-02 06:23:51

Git与颠覆多个大型开发分支

回答

相关问题