我是否应该期望我的团队对我们的源代码控制系统有更多的基本能力？

大约三个月前，我的公司从Subversion切换到Git。切换之前，我们已经提前了数周的通知。由于我以前从未使用过Git（或任何其他DVCS），因此我读了Pro Git，花了一些时间来整理自己的存储库并玩耍，这样当我们切换时，我将能够以最小的痛苦继续工作。现在，我默认为“ Git guy”。

除了几个例外，我的大多数团队仍然不知道Git的工作方式。例如，他们仍然将分支视为源代码的完整副本，甚至将克隆仓库克隆到多个文件夹中（每个分支一个）。他们通常将Git视为一个可怕的黑匣子。

鉴于源代码管理在我们日常工作中的基本本质（更不用说Git赋予我们的可笑的力量了），我认为任何未达到一定熟练程度的开发人员都应该承担责任。

我是否应该期望我的团队至少对Git的内部工作以及如何在最基本的拉/合并/推操作之外使用它有所了解？还是我只是一无所有？

专业性自然会要求开发人员熟悉其团队的标准工具，即使它们是新手也不熟悉（甚至是不受欢迎的）。

但是，您的帖子中有几件事让我停下来。

切换之前，我们已经提前了数周的通知。

几周？交换源代码管理很重要。应该有数月的通知才能导致类似的变化。

除了几个例外，我的大多数团队仍然不知道Git的工作方式。

因此，您的公司切换到当时很少有人理解的源代码控制系统？

除非有其他情况，否则似乎整个举动都没有经过深思熟虑（此举，而不是选择，我是个巨大的git fan）。

我们已经在我工作的地方介绍了Git，自然就会遇到阻力。这是一个新项目，因此我们现在维护两个存储库。

问题的一部分是，当人们一直在使用适合自己的SCM时，人们不会看到切换到其他SCM的好处。当我们与团队坐下来进行为时一小时的会议时，它会有所帮助，我们将仅展示项目中的用例以及Git如何使其变得更加容易。例如，帮助我们的事情：

• 当地分支机构鼓励实验
• Git bisect可轻松跟踪错误
• 频繁提交而不会干扰他人
• 在分支之间快速切换

所有这些解决了我们以前的SCM遇到的一个问题，因此人们可以更加欣赏Git。

另一件事是，您不能指望人们会去阅读有关它的书，因为很少有人会这样做。也许他们需要完成工作，承担其他责任或其他各种原因。

因此，作为“ Git专家”，您必须坐下来并使人们尽可能容易地使用它。他们希望编写代码，而不是弄乱他们的SCM系统。

Git的CLI是一个隐秘的问题，对您和我来说都是微不足道的问题，它们会阻止人们工作。这是我们团队发生的事情（请注意，这些都是相当称职的开发人员）：

• Windows上使用SSH的Git是一个常见问题。
• 人们会拉动，合并，但不会推动合并。因此，该图将是一个混乱的巨大混乱
• Windows上的性能问题使“ git status”需要15秒
• 无法弄清楚如何拉新分支。他们将执行“ git checkout -b”，它将分支出他们正在处理的内容
• 蚀中的EGit有一个压倒性的菜单。最终告诉所有人首先使用命令行
• 基于上一项，合并并设置git mergetool
• 对“ git add”，“ git commit”和“ git push”之间的差异感到困惑。

我们仍然会遇到阻力，但是人们肯定会看到好处。至关重要的是，要有一些Git员工进行指导并愿意提供帮助。而且我会避免教一些很酷的事情，例如reset / rebase /-amend / etc。因为大多数人会像SVN一样使用Git，所以如果愿意，最好让他们发现它。

熟练与狂躁症

基本熟练程度之类的术语对不同的人可能意味着不同的意思。很多人似乎患有git-mania（不是这有什么问题）。我们中的许多人被我们自己和其他人对源代码控制的卑鄙行为严重烧伤。

为何重要（如此）

源代码管理工具至关重要，因为滥用可能不仅会减慢一个人的速度，而且会减慢整个团队的速度。与滥用SVN，CVS和其他系统相比，滥用Git应该不会造成太大问题。从历史上看，无能为力的使用锁定文件的系统的使用尤其成问题，并且公司雇用了离散的构建团队，以便当有人遇到麻烦时，有一个流利的专家几乎不做任何事情，只有源代码控制人员才能将伤口治愈到存储库中。这部分地解释了您在git背后发现的一些热情。

基本熟练程度如何？

一些具体标准包括：

• 不参考文档：

  • 可以添加文件，提交更改，推送和拉取更新。
  • 可以查看状态和修订活动。
  • 可以快速分支和合并，而不会引入错误。
  • 可以适当使用结帐。
  • 创建符合组评论标准的提交评论。
  • 在工作副本和存档之间进行不同的更改。

• 附带文档：

  • 添加本地仓库的用户和凭据。
  • 初始化本地仓库。
  • 管理远程仓库。
  • 配置忽略的文件，生成PKI公钥/私钥对。
  • 移动和删除文件。
  • 使用bisect查找引入了特定错误的更改。

良好的git心理模型和要管理的代码对于避免错误至关重要。

您将为高级水平/专业知识添加什么？

流利的使用对于开发人员以及团队中的其他一些成员至关重要。像Git这样的工具比较费力，应该学习到几乎可以自动化的程度。通过使用每年重复数千次的git命令来最大程度地减少时间和分散注意力具有很高的价值。

团队中总会有一些成员会成为高级用户，并且几乎使用每个命令以及几乎每个选项。我的建议是，鼓励团队成员继续学习git（和其他工具），直到学习的投资回报率下降到在项目上做其他事情的价值为止，主要限制是跟上当前已分配的消耗项目短跑。

GIT是完成工作的一种正义工具，最大的问题之一是，许多GIT宣传人员都希望所有GIT用户都成为了解其工作原理的最佳专家。这是GIT的最大弱点-要使用它，您需要知道它的工作方式。GIT没有配方，您应该是GIT专家或不使用它。阅读Pro-GIT真是太好了，您的组织需要一个“ goto” GIT专家（或两个）来最大化对它的投资，因为并非每个开发人员都希望成为GIT专家-那就可以了。

团队需要知道如何使用GIT（实际上，他们只需要知道如何使用工作流要求他们使用的GIT部分），而不是GIT的工作方式。期望每个开发人员了解他们使用的每种工具的每个细节都是有害的。如果您没有支持您的工作流程的食谱书，则尚未部署GIT，而是将其转交给开发人员。

只要我知道如何让git为我工作，我就不会给猴子一个GIT的工作方式。

是。

无论“公司”决定使用哪种工具，您的开发团队都应该花一些时间来学习如何正确使用该工具。没有什么比一群开发人员害怕或不了解工具对生产力的伤害更大。如果他们错误地使用它或对付它，将会出现问题，并且当您动身时，您将承担清理混乱的任务。

Git对许多人来说是艰难的过渡，因此可能需要进行强制性的坐下培训课程。这应该有助于解决人们遇到的许多问题。

我只在个人环境中使用过Git，而不是在专业环境中使用Git，尽管我确实喜欢它的功能以及更加分散的源代码控制的想法，但是它仍然存在很多问题。Git具有泄漏抽象，它需要多个命令来完成简单的事情（例如进行更改：git add，git commit，然后git push）。另外，某些文档也缺少和/或混乱，例如与rebase命令描述一样……“将端口本地提交到更新的上游头”。我不知道这意味着什么，尽管我现在知道您可以移动提交并用它重写历史记录（另一种烦恼……为什么您应该被允许这样做？）我永远不会从该命令中猜到描述。我认为您的团队需要阅读一些内容，并且您需要提供一些其他培训。

培训和理解是最低要求。负责人应该已经确定了您的团队如何使用它的计划。没有指导，您就不会采用新的编程语言。当结合了既定的道路规则时，驾驶员的培训将更加有效。

没有; 我认为期望以下几点是合理的：

1. 无需手持即可执行日常任务（提交，推，拉，分支，合并，二等分）。
2. 无需重复指导即可执行非常规任务。（重复几次是可以的-我必须在某人的名字留下真名之前遇到2-3次）

如果他们不能做到第一，那么您推出的培训部分可能就不够了。如果他们不能做＃2，那么首先要确保您对事情的解释足够清楚，然后再变得不高兴。