将项目从SVN迁移到Gitlab CE，并与工作流和历史进行斗争 以前的SVN工作流 svn cp$PATH/trunk$REPO/branchs/feature_xxx git签出$REPO/分支机构/功能\u xxx 开发人员处理分支的工作副本，在将分支标记为“准备合并”之前，局部地与主分支合并 当功能准备就绪时，所有者进行了svn合并——重新整合$REPO/branchs/feature\u xxx，运行完整的测试套件，如果一切正常，则“svn提交-m”合并功能\u xxx 当发布准备就绪时，svn cp$REPO/trunk$REPO/tags/vX.Y.Z并发布该标签

svn主干历史记录看起来很好且干净：

version 4.5.4
feature_xxx
bugfix_yyy
version 4.5.3
feature_zzz
version 4.5.3
bugfix_aaa

我们不关心内部提交，但如果需要，我们可以使用

svnlog-g

，将合并的提交扩展为内部提交（有用一两次）

现在我们切换到Git和Gitlab，因为它的特性是对合并请求和差异进行评论。但我们正在努力获得同样干净的工作流程，这或多或少是发生的：

策略1：尝试合并功能分支（通过git或Gitlab“合并”按钮） 好的。。这很容易！Ehh wait WTF是以前那些污染我主人日志的提交

决议：不可能，这是一团糟

策略2：学习git合并——挤压 好的。。这就是我们想要的。。现在我们有了一个很好的历史记录，但我们必须从命令行执行它，因为Gitlab CE不允许从GUI（）执行它。没什么大不了的，我们是通过命令行完成的。。哦，等等，为什么Gitlab没有检测到我们关闭了合并请求。。！？这以前是自动发生的

因此，我们了解到它无法检测到分支被合并。。确定还有另一种方法（例如，用提交消息结束）。尚未实施Ups:

解决方案：历史看起来不错，但我们需要手动关闭合并请求，因此我们无法从“已关闭但通过挤压手动合并”中跟踪哪些请求是我们“无意”关闭的。当然，一定有更好的办法

策略3：了解git rebase。。 好的，当一个分支完成时，我们执行

git-rebase-origin/master

，然后执行

git-rebase-i XXXXX

，其中XXXX是最古老的共同祖先，我们通过消息“implemented feature_xxx”提交所有内容。然后我们通过cmd行或GUI简单地与master合并

解决方案：现在gitlab检测哪些合并请求被合并。。好。但重定基址可能是长分支的一大难题，有时会浪费时间，所以当事情变得棘手时，我们只需返回到

merge--squash

。此外，日志也不是很干净，因为我们每个分支都有实现的功能\u xxx，然后合并的功能\u xxx提交。。它不像简单的合并那么糟糕，但仍然是噪音

结论 所以现在我们使用的是最后一种策略。。大多数时候都试图

git-rebase

，但当事情变得棘手时，就会恢复到

git-merge--squash

。但老实说，我们并不是100%满意，SVN的工作流程是干净和简单的

---

我们错过了什么吗？谢谢

从Subversion迁移到Git并非易事，因为Git功能更强大、更复杂。但这肯定是一个富有成效的举措。以下是一组相关备注/建议/参考：

原子提交 我们不关心内部提交，但如果需要，我们可以使用svn log-g将合并的提交扩展为内部提交（有用一两次）

即使您不想一直关注构成特性的内部提交，但使用Git的最佳实践是“尽早且经常提交”。其思想是使每个提交都变小，并且只实现（或修复）一件事。例如，请参阅这篇博客文章。还有编写“良好提交消息”的最佳实践，请参阅或

我记得在Git中，每个提交都有很多元数据（一个作者姓名+电子邮件+时间戳；一个提交人姓名+电子邮件+时间戳；以及一个SHA1签名），与SVN相反，

Git commit

只在本地起作用，因此您需要执行

Git push

将更改发布到远程存储库。所有这些元数据都可以通过GUI工具显示，例如

特征分支 在您提到的三种策略中，第一种肯定是最好的：为每个功能创建一个功能分支，然后在master中“合并”它们。但是这个策略有几个变体，我将在下面的工作流部分详细介绍

策略1：尝试合并功能分支（通过git或Gitlab“合并”按钮） 决议：不可能，这是一团糟

了解合并的一个关键概念是vs.的概念

如果两种类型的合并都是可能的，CLI命令“

git checkout master&&git merge feature”

将执行快进合并，如果feature分支只包含一个提交，这是可以接受的。否则，最好的做法是通过执行

git merge--no-ff特性来强制执行非快进合并。但是如果您不使用命令行，而是单击GitHub或GitLab的“Merge”按钮，它将执行非快进合并

非快进合并（=真正合并）的优点是，您的历史看起来像一棵树（不同于SVN的典型线性历史），它允许您轻松跟踪属于该功能的提交子集

例如，请参见此gitk的屏幕截图，其中可能有一个主历史记录，合并了两个分支：


好的。。这很容易！Ehh wait WTF是以前那些污染我主人日志的提交

这不是一个真正的问题，但仅供参考，
git log
和
gitk
的一个功能允许在一个这样的历史记录中隐藏功能分支的“内部提交”（假设功能分支已与
--no ff
模式合并）：选项