git - 在具有连续重构的项目上使用git/mercurial？

Question

我试图了解我是否真的有使用git / mercurial的情况。

我从事的项目是Java和C#项目，通常有5至20个人参与
一个共同的目标(“发布”)。大多数开发商是专业的开发商，他们
始终重构代码。因此，典型的linux内核中有大量的
相对独立的文件更改，我们一直在不断地进行更改重构-
通常会打很多文件和很多代码。没有人会害怕在这里更改代码。

现在，通过颠覆，我们通过非常接近SVN HEAD来解决此问题。我们当中有些人甚至
自动svn up，在构建服务器的jabber广播上触发。我们大多数人也学到了
(或非常快地学习)如何计划我们的工作，以保持与SVN HEAD的距离。如果您要进行重大重构，我们
将源树逐渐向新的方向弯曲，而不要花太长时间。有时您只是计划
重构操作并从竞争较弱的区域开始。几年后
这样工作成为第二天性。我们大多数人根本就不会离开小于“舒适区”的“舒适区”
距svn头2个小时。自动构建和svn头是项目“脉冲”，我们喜欢它。

当然，我们会分支每个发行版，但从发行分支到主干的回退数量将逐渐减少
快速下降到可以忽略不计的程度(我们拥有不错的测试范围)。与源声音的私有(private)分支一起运行数天/周
就像我们积极劝阻的事情，而且这种情况很少发生。

git和mercurial声音都很酷，git稍微多一点，因为我更喜欢McGyver类型而不是James Bond类型。
但是，在为实际切换建立理由时，感觉就像我和Linus住在两个不同的星球上。
在大多数情况下，我们希望我们的团队始终专注于HEAD。

GIT如何使我的版本控制更好？ GIT如何让我改善流程？我是颠覆恐龙吗？

Answer 1

从心态上讲，有时可以创建一个软分支，执行该软分支中的所有更改，测试该软分支中的更改结果，然后在“软分支”完成后”，将其与本地主分支重新集成，重新测试，然后传播。

在某些情况下，这比赶时间更好，因为您不会经常中断其他调试代码的存在，从而使您的代码不堪处理以添加非错误来处理。

这也意味着您可以更频繁地进行提交，提供更全面的历史记录，因为提交不会立即出现在所有出现问题的地方。

另外，在使软分支与共享主线协调一致时，您会看到一个不错的完整变更集，向您展示所有集体变更及其所有集体变更，这为获得良好的代码审查机会打开了大门。

此外，从测试的 Angular 来看，如果您有更多的软分支，则可以在将软分支合并回主分支之前在软分支上运行测试，并具有一个标准，即该分支不会合并回主分支分支直到有

自己通过

通过了测试

在主分支更改已协调到软分支

后通过测试

这样就为您提供了额外的代码质量保证，因为您的主要协作分支非常干净利索，因为不允许出现失败的代码。

(这也限制了解决问题的 Realm ，因为您只需要测试自己的大部分更改，而当您完成“更改”时，则仅需担心其他人所做的事情以及他们所做的事情还应该通过测试，这意味着当某件事确实失败时，您只需要查看解决问题所采取的措施即可)

But would I continiously update from central repo head into my softbranch ? This is really the essence of my problem

分支系统的优点是您可以根据需要将“其他人认为稳定的东西”拖入本地副本。

不需要“连续更新”，因为您不会出现相同的问题。

a  b   center
         |
         |
         /      Key:   / - | \   = Flow
/----<---|             < >       = Flow Directions
|  /--<--/             *         = Commit 
*  |     |             T         = Test
|  *     |             M         = Merging with "Current" state of common branch
*  |     |             C         = Tests Complete and Current state is "sane"
|  *     |
T  |     |
|  T     |
|  C     |
|  |/-<--/
*  M     |
|  T     |
*  C     |
|  \--->-\
*  /---<-/
T  |     |
C  *     |
|/-----<-/
M  |     |
T  *     |
|  T     |
*  C     |
|  |/-<--/
*  M     |
T  T     |
C  \-->--\
|/---<---/
M        |
T        |
C        |
\---->---\
         |

另外，由于系统的工作原理，以后还会发生这种情况:

a  b   center
|  |     |
T  |     |
C  *     |
|/</     |
M  |     |
|  *     |
T        |
C        |
|/----<--/
M        |
T        |
C        |
\-->-----\
         |

在这种情况下，它们成为“头”的整个概念都消失了。它有几十个头，您看到的这些头很容易透视。

我可能还要补充一点，这些逻辑分支尽管在此处显示为单独，但可以相当可行地表示单独的结帐位置，或单个机器上不同的软分支。 a和b实际上可以是单个开发人员。

本质上，“从主分支不断更新我的软分支”在概念上是没有意义的。因为实际上，会有一些尚未在主分支中表示的更改，您何时知道它们是否已被推送？ SVN给您一种“单一”代码状态的错觉，实际上，当一个用户在其文本编辑器中打开文件时，他们实际上创建了一个寿命很短的软分支，即正在发生的更改，没有人知道，要想让这种错觉持续下去，实际上，用户必须在每个角色之后都付诸实践，这几乎是不现实的。因此，实际上，人们已经习惯了以下事实:不同的位置会彼此“不同步”，并学习解决方法，因此这不再是问题。

另外，“不断用其他所有人的更改来更新我的树”有一个核心问题，那就是，您的注意力太多了，不断受到其他所有人正在做的一切的轰炸，如果他们做出一系列的决定， line promise 测试他们无法在自己的计算机上测试的内容，然后您将对不断变化的文件感到恶梦，而用户看到的看似随机的更改无法理解它们。

通过允许两次提交之间有更长的运行时间，然后分批查看最终结果，并且仅看到同行的最终结果全部更改，您可以立即看到自从 checkout 以来已更改了哪些代码，以及其含义的整体概述代码，因此您只需编写自己的代码即可。

如果您有任何疑问

从简单的事情开始，不要过渡冷火鸡，DSCM中的某些概念可能会有些令人生畏(我已经看到很多人都无法理解垂直堆叠的软分支的概念)，移动了一个小的非Git / Mercurial的代码库的重要组成部分，并使用它一段时间，尝试其好处和作用。没有比亲身经历更好的证据了，我所有的可爱解释都不太可能传达您需要理解的内容，只能通过尝试并多次失败来学习(因为失败是学习的关键部分)