语境

我的由8名工程师组成的团队目前正在过渡到Git（从Subversion进行），这是我们接下来的工作。我们有一些“经验更丰富”的工程师，他们发现很难拿起Git。尽管提供了用户手册，培训活动和白板会议，但我仍然被问到同样的琐碎问题。我们有两名初级顾问，他们在几天之内就完成了所有工作，这确实为这个问题锦上添花。这不是仅限于Git的模式，因此已经可见。

题

对于那些不会/不会学习的工程师，我尤其不满意-特别是拥有我们这里资深资历的员工。但是，我确实希望团队成功并建立出色的产品。我们正在使用集中化的Git Flow模型，我觉得所有新术语都使他们感到困惑。

我有什么办法可以帮助这些员工学习Git？

Sourcetree是整个团队都在使用的客户端。

给他们一个玩具。

Git很难。尤其是如果您一直在以不同的范例进行源代码控制。我第一次尝试使用git时破坏了构建。这让我如此偏执，以至于我不想在一切都完成之前检查一下。我在文件夹中隐藏了版本。然后，我终于想出了克服它的必要条件：

我需要一个安全的地方玩。

遇到问题后，我会故意造成问题，以便我可以在安全的地方学习如何解决这些问题。我开发了一种模式，即使被打断也可以恢复到良好状态。不久，人们就向我寻求有关git的帮助。都是因为我花时间玩玩具。

如果您只是将它们扔到最深处，那么如果它们能够浮动，您将很幸运。

一般的开发人员不需要很多git的东西。这是一个分布式源代码控制系统，但是大多数团队都将其与中央规范存储库结合使用以进行推送和提取。

您的团队需要的核心命令是：

• 从远程提取并合并更改并处理由此产生的冲突（可能重新定基础）
• 提交并推送到远程的提交（或推送到暂存仓库/分支，以使更改在审核后被拉入主目录）
• 获得支持：做错事后修复混乱。

更高级的用户将需要的是

• 处理本地提交
• 管理分支

对于不熟悉git的人和不想学习git的人，可以设置一些快速别名的命令来进行操作，并确保一切正确（添加新文件，从存储库中删除已删除的文件等）。

确保这些文件有据可查，并具有充分的傻瓜证明。

这是xkcd漫画的特色，只是记住命令，并希望当他们问专业人士时，不要把事情弄得太乱。

让他们使用Git UI。

如果他们有TortoiseSVN的经验，那么TortoiseGit （仅Windows）的工作原理几乎完全相同。否则，SourceTree （Windows + Mac）很棒-我们有多个非开发人员QA，这要归功于SourceTree，他们可以轻松地在Git中掌握复杂的任务。

这个答案试图解决如何使高级程序员感兴趣的问题git，而不是如何学习git最快的方法，为此，优秀的git书籍很棒，或者提供了许多教程（=> Google）。与该答案相关的良好链接是Git是纯功能性的数据结构，尤其是git如何存储数据的简短内容。

恐怕我对此持悲观态度。我一直都在为你着迷-我是一个git书呆子，想让一支球队远离svn微不足道的成绩，让我们面对现实。就我而言，这导致我积极地改变自己的看法，并接受人们无法“被迫获得幸福”。人不是计算机，很难对它们进行编程。我仍然为自己的尝试感到高兴，它以一种相当柔和的方式向我展示了我在职业生涯中做什么和不想做什么。

当涉及到新事物时，有些人会开始变得有动力，而有些人会变得消极。这与无关git，但是git特别地，您始终具有“如果svn还好就为什么应该完全使用它”的效果，这是一个巨大的心理障碍。

而且，真正的鬼混git需要对抽象数据结构产生浓厚的兴趣。这听起来似乎令人难以置信，但是根据我的经验，有些程序员根本不感兴趣，并且对比简单数组更复杂的元素感到无聊和负担过重。您可以来回争论那些人是否应该做他们正在做的工作，但这就是事实。

如果人们对此不感兴趣，他们将不会理解。干净利落。我敢打赌，无私是学校成绩不佳，而不是缺乏智力的主要原因。

就是说，这将是一门我将应用的课程，它是基于从下到上的知识积累。它对我没有用，但您可以以此为灵感来推出自己的产品。

图形用户界面

尽管以下方法并不一定需要对操作进行GUI支持（git add在hello world存储库中...），但从一开始就拥有用于可视化存储库的GUI会极大地帮助您。如果您不能决定使用哪一种，请采取gitk最后的选择。如果您的人员使用任何类型的可视化编辑器，请查找其gitGUI组件。

（静态）数据结构是关键

首先说明内部数据类型（它们只有三加一：blob，tree，commit，带注释的标签，在此阶段，最后一个都无关紧要）和它们的结构。您可以在白板上/用铅笔轻松地完成此操作；这棵树很容易绘制，因为它永远无法更改，您可以随时随地添加内容。您可以在新创建的本地存储库中进行播放会话，并使用它git cat-file来查看实际对象，以向他们显示它们实际上与广告中说的一样琐碎。

如果可以帮助他们理解

• ...在历史上，实际上只有3种类型的对象，它们都很简单，几乎是微不足道的，而且
• ...大多数git子命令只是以一种或另一种方式“按摩”这些对象，而这些操作几乎都是琐碎的操作（基本上只有一个：在某处添加新的提交），然后...
• ......一切都可以很容易地看到对符合你的面前ls，并git cat-file...

然后他们将对存储库中的实际内容进行心理翻译。在这一点上，前辈们可能还记得s 的内部svn是不可思议的魔术（是否曾经在svn信息库内部的锁出现问题，或者在“重新整合”分支等方面有问题？），这可能只是激发了他们一些动机。

一个问题，尤其svn是对习惯于此的人们来说，是一个习惯，即一个提交（对象，而不是动作）始终是整个目录树。在中svn，人们习惯于提交单个文件。这是一种完全不同的方法。哦，对于静态对象和动作都使用相同的术语“提交”的事实也无济于事。

svn伙计们的另一个问题是svn使用线性历史记录，而不是树。同样，这是完全不同的。因此，现在正是指出这些差异的时候了。

根据结构说明动作

当他们了解了git存储库的组成部分之后，就该向他们确切展示各个git子命令在这些方面的作用了。

我正在谈论add，，commit本地工作目录和阶段（请确保他们了解工作目录与暂存区域不同，而暂存区域与存储库也不相同）。

当他们了解了这些命令后，就简单地种植了树（在这个阶段，树又由3种类型组成-Blob，树，提交，不仅是提交），您可以先做树，git push然后git pull（在快进模式下！） ），向他们展示git实际上只是在推动其对象，这些哈希实际上只是内容哈希，您可以使用文件系统复制命令等轻松地将这些东西复制。

显然，我们在git add hello.txt这里谈论的是远离这些命令的所有不必要的选项。

分行

请注意，分支对于svn人们来说尤其困难，因为它完全不同。该svn模型更容易可视化，因为基本上没有可视化内容-它处于纯视图中。该git模型没有那么多。确保他们从一开始就意识到分支和标签只是指向某个地方的“粘滞便笺”，而在静态的，不变的历史方面实际上并没有“存在”。

然后在简单的示例后面做一个示例，以说明您可以实际使用它们做什么。正如您自己似乎已习惯那样git，您应该在那找到动力。确保他们始终以树的生长方式来查看。

如果他们对此感到沮丧，您可以解释一下git pull实际情况git fetch && git merge；如何所有存储库实际上包含完全相同的对象（git fetch几乎与scp在git object目录内复制内容一样），依此类推。

也许，如果此时您还没有达到唤醒他们的兴趣的程度，那么您也可以放弃，但是如果他们设法做到了那么远，那么他们就可以使用所有的心理工具，应该几乎没有恐惧已经涉及。其余的（git工作流程...）则应该走下坡路。

最后的话

这听起来很费力，的确如此。不要将其出售为“我们需要此项目”，而是“这可以帮助您个人发展并在所有进一步的交互中帮助您”。您需要很多时间，时间就是金钱。如果您对此没有接受管理层的认可，那可能不值得。你也许应该和老板商量一下。

如果您决定放弃教导看似无法掌握它的开发人员的经验，但是您绝对必须git在将来使用，请考虑使用git预编写的脚本或某些可以git消除所有细节的GUI 替换所有与命令的交互。将所有错误控制等倒入脚本中，然后尝试使其正常工作。

我想向您推荐Joel Spolsky的这篇博客文章。

您之所以会看到这些初级开发人员迅速选择它的原因，很可能是因为他们没有关于版本控制在一般情况下如何工作的预定概念，或者至少没有一个根深蒂固的思想模型。因此，它们带有干净的板岩。您更高级的程序员可能会尝试应用他们已经知道的概念，并且因此而失败。

除此之外，我不喜欢说。谁真正阅读用户手册？通常，他们很难解释基本用法。只需查看手册中的git commit页面，并考虑向不熟悉该概念的人介绍了多少个新术语和短语。如果没有好的介绍，我可能会放弃在那儿立即使用Git。

我的个人建议是开始解释命令：

• git添加<文件>
• git提交
• git pull
• git推
• git状态

逻辑上合并冲突应该在下面进行解释，因为一旦人们学习了如何提交代码，那绝对是您的第一个问题。

通常情况下，人们将需要花费更多的时间来学习东西（还原，标签，合并冲突，分支，重新设置，钩子），但是试图在需要之前解释所有这些内容将无助于陷入困境的人们流。

总结一下：根据我的个人经验，有些人只是没有花太多时间去探索新技术，概念或工具，他们通常会以较慢的速度拿起您介绍它们的东西。这并不意味着他们是不好的程序员或坏人，但是他们通常具有较窄的技能。

如果您学习了如何在SVN上进行源代码控制，则Git是一个重大的重新思考。您在该处养成的许多习惯（可能是SVN的最佳实践）在使用git时会误导您。这主要是因为git的分支模型根本不同。它不使用文件夹作为分支，也可以使其非线性，因为它旨在更好地支持分布式用例。这需要一些时间来忘却SVN习惯和理解你如何应该使用的git。

从简单开始

您说您已选择Gitflow作为分支机构管理的标准。这使我震惊，这是您最大的错误。

引用Gitflow被认为有害：

所有使用的这些分支都迫使GitFlow拥有一组复杂的规则来描述它们如何相互作用。这些规则，加上无形的历史，对于开发人员来说，日常使用GitFlow非常困难。

您能猜出每当您建立一个复杂的规则网络时会发生什么吗？没错-人们会犯错误并无意间将其破坏。对于GitFlow，这种情况一直存在。这是我所观察到的最常见错误的简短说明，绝不是详尽列表。这些相同的开发人员会不时地（有时每天）重复一遍又一遍-在大多数情况下，他们在其他软件领域都很有能力。

您的开发人员可能对这个标准的复杂性感到不知所措。我个人认为这没有任何好处，并且上面的文章提出了相同的观点。但这是一个单独的讨论。从客观上讲，这是一个非常繁重的标准，需要大量的人工管理，并且需要大量的认知工作。

您需要从简单开始。现在不用担心分支标准。专注于让他们习惯于首先使用git。您实际上只需要执行一些操作即可：

• 克隆
• 拉
• 科
• 合并
• 承诺
• 推
• 有关.gitignore工作原理的知识
• 也许标记

是的，您的历史起初可能看起来有些混乱。没关系 现在不用担心。只需使用git获取它们即可。

逐步增加知识

从这里开始，您可以逐步对他们进行稍微高级的用法教育。

• 教他们史诗般的隐藏命令
• 教他们在想放弃刚提交的本地提交时如何使用reset
• 教他们如何修改
• 教他们如何重新设置基准以避免不必要的合并提交
• 在他们推送之前，教他们如何交互式地重新组织他们的提交
• 教他们如何从任何哈希，标签或分支中检出

尤其要确保您抓住机会，向他们展示将代码存储到存储库中的更干净的方法，同时还要在培训活动中教这些知识以及您的知识。当人们不确定要做什么时，拥有一两个可以帮助他们的大师也会很有帮助。如果您有Slack之类的东西，请创建一个专用渠道并鼓励人们在那里提问和回答问题。

然后选择一个分支标准

一旦您拥有公司中大多数能使用git的能力，那么您就可以查看分支标准。由于多种原因，预先选择一个是一个非常糟糕的主意：

• 他们对工具的了解不足，无法告诉您该标准是否适合公司的用例
• 他们将无法提供替代标准
• 他们必须同时学习工具和标准
• 有些人会假设您选择的标准是他们可以使用git的唯一方法
• 他们将无法识别标准弊大于利的罕见情况

您不应该从山上传授Git工作流程。您的团队需要对此进行投入，并能够向您提供有关运行是否良好的反馈。如果他们甚至还不了解基本原理，他们将无法做到这一点。您不需要每个开发人员都拥有像这样的深厚知识，但是您确实需要几个真正了解它的人。而且您需要绝大多数人至少能够胜任git的工作，这样他们才足够了解一些东西。

以下是您的团队可以考虑使用的Gitflow的几种替代方案：

• 单流
• 功能分支工作流程
• 集中式工作流程

查看它们和Gitflow，将它们与您的用例进行权衡，然后选择合适的用例。

当我第一次学习Git术语时，我发现stackoverflow非常有帮助。诸如此类的问题对我来说真的很有用（主要是因为它们的简洁性），在使用它的最初几周中，我一直将其保留在选项卡中。也许以粗体打印出几个答案？特别是第一个图。

“ git commit”和“ git push”之间有什么区别？

'git pull'和'git fetch'有什么区别？

我还发现树干的视觉表示非常有用，但是您已经用SourceTree覆盖了它。

_{除此之外，这可能是一条评论，但我缺少代表：我是问题中提到的初级顾问之一。在我开始之前，我已经了解了什么是源代码控制系统，并且从字面上看过两次SVN，Gusdor给了我比我应得的更多的荣誉。整个团队都接受了高质量的Git专业培训，玩具和游戏时间。问题不在于古斯多的指示。我希望对此有一个好的替代解决方案，以便我可以为它加书签并了解更多信息。}

给他们买书

老实说，我正好沉迷于您所描述的营地。我来自SourceSafe和ClearCase的背景。刚开始，尽管我的老板多次走过，但Git还是完全无法理解我。

帮助我的是一本书，其中清楚地描述了正在发生的事情，但更重要的是，Git与我以前使用的任何源代码控制系统有本质的不同。现在，我比其他任何选择都更喜欢Git。

不幸的是，我不记得当时我读过哪本书，但是，只要确保您为他们所读（或指向他们）所读的书着重于它的不同之处以及它如何需要不同的思维定式即可。

推荐书的最佳猜测是：

斯科特·查孔（Scott Chacon）的Pro Git（为方便起见，亚马逊链接...从您想要的人那里购买：https : //www.amazon.com/dp/1484200772/ref=cm_sw_r_cp_dp_T1_BNruzbBQ8G9A6）

注意：千万不能买参考书的Git。那根本没有帮助。

根据我的经验，有些人可能不了解git就可以使用它。他们找到了基本的教程，掌握了基本的命令，并且很不错。这可能是初级顾问适合的地方。我不相信您几天之内就能真正学到git！

其他人无法做到，他们需要了解git在做什么，这需要更多时间。我属于那个类别；我发现使用目录的内容确实很有帮助.git，那是事情开始为我点击的时候。与我们的技术负责人进行的一对一交流也有所帮助。

您可以进行一对一的教程，因为人们学习的方式不同，并且对不同的部分可能会感到困惑，在一对一的会话中，更容易看到和解决。如果他们真的不了解git如何跟踪分支，向他们显示.git目录内容等事实而感到困扰，...

我想介绍一下git我的位置（来自TFS），所以您的问题对我来说是及时的，特别是因为我在提出该主题时也有所退缩。

在Peopleware中，整本书的基本原理是：

本质上，我们工作的主要问题不是技术而是社会学。

我提出这一点是因为我们这不是技术问题。git，虽然有些晦涩，但除非您或我的资深开发人员非常愚蠢，否则可能并不超出您或我的资深开发人员的能力。

让我们从您的开发人员的角度来看一下它，而不是技术人员：

您是在要求他们停止使用（可能）精通的源代码控制系统，而不是他们所不熟悉的源代码控制系统。有点像要求git专家停止使用git并转到那里svn，对吗？我认为git专家会很烦，并且可能不会花太多力气，svn因为git效果很好，而且她确实喜欢其中的某些部分，而这些部分确实很难做到svn。

这可能是为什么晚辈已经采取措施来更好-也许他们还没有得到的窍门svn，并git为自己的机会把它抛弃了^。

老年人虽然对机会成本保持警惕-如果他们学习了git，那么他们就不会：

• 学习React / Angular / Swift / Blockchain / Kotlin（他们认为应该学习的其他东西）。
• 自己动手做/自己动手做/自己动手做/自己动手做/做自己想做的事情。
• 与他们的孩子/亲戚/朋友/重要的其他人共度时光。

• 交付“重大新事物”-有期限，预算等。他们可能对此感到担心。

  “我需要做以上所有事情，为什么git 已经拥有源代码控制时为什么要使用？”

您给出了哪些理由让他们从他们擅长的一件事切换到您刚接触新事物时坦白尴尬的另一件事，并且需要对您的开发方式进行全面的重新思考？您是否解释了git功能的好处？

拉请求？细颗粒的签到吗？分布式源？叉子？

他们有这些原因吗？如果您处于集中式源代码管理的思维定势中，那么这将是大规模的结构性变更-不仅是技术变更，还包括文化变更，而且我们知道改变一种文化有多么困难。

因此，基本上，请仔细考虑您要开发人员执行的操作，并确保出于正确的原因。如果您只是因为svn笨拙而又老旧而又不想再使用了，那么就可以了，但是要卖给那些不喜欢您的人并且只想顺其自然的人，就很难了。您需要用对团队和项目有意义的术语来陈述收益。如果你可以让他们同意，git是值得的痛苦，那么你不必担心他们学习技术，只是同意你设置任何的工作流程了。

祝好运。

我认为这不是软件工程问题，而是心理学问题。我想参考一下Algorithms to Live By: The Computer Science of Humand Decisions。在其中作者探讨了探索/利用权衡的主题。人们通常会经历一个探索阶段，然后经历一个探索（使用）他们所探索的东西的阶段。为什么要在特定时间间隔内最佳利用某些东西，背后有一些扎实的数学理论。

这也延伸到年龄和经验。人类将自己的生活视为一个间隔，在经过一定的探索阶段后，最好开始使用您的知识。他们引用了一项研究，询问年龄较大的参与者是否想见一个他们喜欢的名人或家庭成员。他们通常选择家庭成员，而年轻人则更有可能选择名人。但是，当被问及如何决定自己是否年轻20岁时，老年人通常也会选择名人。这表明，当人们认为自己从探索中获得的收益要少于从已有知识中获得的收益时，他们就会停止构建社交网络。

您的高级工程师可能年龄较大，他们可能已经经历了一些版本控制系统。SVN可能是迄今为止他们使用过的最好的版本（至少从我使用的旧版本系统来看，SVN击败了所有版本）。

他们的最佳策略是利用SVN，因为他们已经进行了探索，发现这是最好的，现在就可以利用。

这是基本的人类心理学，是您要对抗的数十万年的进化优化。

您需要向他们展示：a）他们在他们前面有多久的职业生涯，以引导他们从不同的角度思考他们所处的时间间隔； b）问他们他们认为什么是伟大的，他们是什么。不见了SVN。您可以列举的数百种好处git，但是他们SVN毕竟已经经历了大概5种版本控制系统，所以他们已经有了一个清晰的主意，为什么是最好的。您需要找到该论点的重点，然后看看是否git可以解决这些问题，然后他们就会说服自己。

不要给他们使用Git的工具或GUI。它只会使事情变得混乱。Git的构想是在命令行上运行，因此应该是学习它的地方。任何GUI都有其自己的术语和特性，并坚持简单的原则。

接下来是研究Git比SVN更好的一些问题。为了让您的团队学习它，您需要激励他们去了解为什么git更好。

• 在不连接网络的情况下进行提交的能力
• 制作和玩自己的分支机构的能力
• 可以在彼此之间发送且仍合并音轨的音色
• 樱桃采摘没有痛苦。
• 变基
• 用git splice查找错误

我敢肯定，SVN在过去几年中一直在发展，但是那些曾经使人感到痛苦的事情。如果开发人员发现此新工具不仅是一件奇特的事，而且在工作上具有可观的优势，那么他们可能会更喜欢它。

这是一门要学习的新事物，有很多相似之处，可能会引起混淆，但实际上，在2017年，DCVS对于每个开发人员来说都是一项基本技能。

告诉他们不要担心

在Git中，一旦完成工作，就几乎不可能丢失。您唯一容易丢失的工作是尚未完成的工作。

向他们展示如何git reflog工作。他们不必知道如何使用它。他们只需要知道它的存在，因此如果出现问题，他们可以获取帮助以恢复工作。

然后给他们留下一条简单的规则：如有疑问，请坚持。他们总是可以稍后撤消提交（甚至是从远程！）。

不要使用GUI

GUI将使他们更快地入门，但是他们永远不会真正了解Git。此外，我发现使用Git GUI 并不是 “几乎不可能丢失”已完成的工作。我见过GUI会做可怕的事情，例如在合并时显示一个清单，然后，如果用户取消选中某个项目，则从历史记录中删除该文件，而不会发出警告，也不会对其进行记录。GUI比单纯学习命令行Git差得多。

配对程序代码提交

学习git add -A起来git commit并不难，但是特别是在与远程进行合并（或变基础）时，他们将需要一些帮助。明确指出，欢迎任何人随时寻求帮助。当他们键入命令并做笔记时，请等待。随着时间的推移，他们将逐渐增加无需帮助即可处理的情况。

Git已经很安全了

上面的人谈论过拥有“一个安全的游戏场所”。但是Git 是那个安全的地方。在日常的日常情况中，只有两种容易丢掉工作的情况：

• 未提交的代码
• 使用GUI

确保他们提早并经常提交，并确保他们不会使用GUI犯错，并且不久他们会发现，他们比以往任何其他源代码控制系统都更加信任Git的代码。

我建议看看Gitless。它是git的包装，大大简化了基本工作流程（无需担心暂存区，分支保留其自己的文件工作副本，使用git rebase来处理更简单的用法gl fuse等），同时维护了基础git仓库以进行协作或者您需要做一些不寻常的事情。此外，这些消息对新手更友好。如果命令由于某种原因需要使用没有gitless的系统，那么这些命令就足够接近git以充当垫脚石。

我尝试记录如何使用git命令行的基础知识。对于我自己（曾经使用过Perforce和Source Safe的人），以及喜欢旧的“只是压缩相关文件夹”范式的程序员，这仍然令人困惑。使用不透明的工具来修改我的工作目录的内容令人担忧，并且经常不得不与该工具争论以将特定的更改合并到我的工作目录中。

相反，我使用两种间接方式。

• 我使用GitKraken来提供分支的可视历史记录，以及用于隐藏命令行语句的GUI。GitKraken处理“原始”远程存储库和git认为是我的本地工作目录之间的交互。

• 我还保留了一个“真实的”本地工作目录，该目录与git认为的本地工作目录分开。我手动同步了这两个工作目录，这使我感到很舒服，因为我对工作目录所做的任何更改都是我想要的。

我有什么办法可以帮助这些员工学习Git？

您确定问题是Git而不是其他问题吗？我从评论中得到的是，管理层决定更改某些内容，而无需获得高级贡献者的支持，并要求他们中的初级人员来推动更改。无论发生什么变化，这似乎都是失败的好起点。Git的复杂性不是问题，问题在于，他们认为不需要进行更改。

因此，只要他们没有看到转换的优势，就不要专注于如何教他们Git，他们会拖延脚。向他们展示Git如何解决他们现在遇到的问题。不是Git如何为他们提供他们不需要的东西，不是Git如何为其他人的问题提供解决方案，不是Git如何解决他们现在正在战斗的问题。然后教他们Git将不是问题。

通常，Git在公司中用于解决分支机构的问题。是的，分支比Subversion更好，但是它没有任何作用。

有经验的开发人员很可能曾在许多拥有该公司的公司工作。

• 创建分支机构，因为管理层不愿在冲突需求之间做出决定
• 已经为每个客户使用了一个分支，而不是配置开关。
• 每个管理层都必须有一个错误修复分支，因为管理层不愿意让所有客户都升级到相同版本的软件
• 等等。

因此，有人告诉我，一种工具擅长分支我对我说。

管理层不想决定公司的发展方向，而是宁愿浪费生命，不得不将我的工作合并到101个不同的分支机构中，同时不得不测试101个不同版本的软件。

同样，两个人将同时在同一个文件上工作的概念是“好”的，对于经历过运行良好的项目的人来说，这是不可接受的，因此，推广Git作为这样做的工具，不太可能会经历开发人员喜欢你。

每当我查看Git中的历史记录时，都很难理解为什么代码会更改，因为50％或更多的历史记录是逻辑上不应该公开的合并，并且一旦代码离开开发人员，它们就变得毫无意义。机。

但我很想在以下地方工作：

• 在托管服务器上对其进行编译和单元测试之前，没有代码进入中央系统。
• 有一种简单的方法来跟踪代码审查
• 每当我执行“获取”操作时，代码总是可以编译和运行
• 在这里我可以进行更改而不必与其他人竞争，也不必在办公室流浪以查看是否破坏了构建。

因此，解决实际的问题，如果Git是您经验丰富的开发人员会购买的解决方案的一部分，但不要指望他们喜欢Git只是因为它是一个很酷的玩具，可以“神奇地融合”。

因此，任何让开发人员将其从本地Git推送到中央Git的地方都做错了，一个受控的自动化流程应该从开发人员那里获取更改，并在对其进行测试之后等，并检查合并是否可以更新中央Git，从而将所有内容都扁平化。没有长期利益的分支机构等。

我希望Kiln（http://www.fogcreek.com/fogbugz/devhub）甚至使用“拉取请求”工作流的GitHub都能使有经验的开发人员满意，例如，不要从低级开始，而从改进开始处理。