团队过渡到 Git 前须知

当 Emma Jane Hogbin Westby 对某事感兴趣时，她会全身心投入，然后分享她的学习成果。例如，她不仅仅是使用 Drupal，她还写了几本关于学习 Drupal 的书，并且她还创作并分享了一个 Drupal 袜子的编织图案。Emma Jane 就是通过使用 Drupal 开始使用 Git 的。然后她写了一本关于使用 Git 进行团队协作的书，制作了一个关于 使用 Git 进行协作的 O'Reilly 视频，并且像她对 Drupal 所做的那样，她在技术活动中谈论这个开源项目。

在这次采访中，我在 Emma Jane 即将进行的 OSCON 演讲和培训 之前采访了她，并询问了她关于学习 Git 以及在团队中使用 Git 的情况。

您是如何以及为何开始使用 Git 的？

那大约是在 Drupal 首次决定切换到哪个版本控制系统的时候——那应该是 2008 年或 2009 年。（当时我们正在使用 CVS。）作为 Ubuntu 贡献者，我的第一个分布式版本控制系统是 Bazaar，所以我将这个视角带入了 Drupal 的讨论中。

请告诉我您喜欢 Git 的三件事，以及 Git 哪里做得不好。

我喜欢的事情

1. 核心社区。并非所有使用 Git 的人都热情友好，因此 Git 看起来可能是一个非常可怕的地方。今年早些时候，我有幸参加了核心贡献者会议 Git Merge。社区非常热情和支持。我现在在核心邮件列表中。
2. 变基 (Rebasing)。这个命令允许我在与他人共享分支之前重写我的本地提交历史。当我重写历史时，我可以组织提交，使我的工作分组为逻辑单元，而不是像我工作过程的定格动画电影那样的提交序列。
3. 灵活性。Git 最初可能用于内核开发，但该软件足够灵活，几乎任何想要跟踪文件随时间变化的人都可以使用它。它仍然是一个底层工具，鼓励其他人在其基础上构建。

Git 哪里做得不好

1. 文档。许多 Git 文档都非常非常好。但它感觉不一致，因为并非 git help -a 中列出的所有命令都有相应的帮助手册页。
2. 变基 (Rebasing)。这是一个很棒的命令，可以很好地处理自定义历史的制作，并以整洁的方式保持分支的最新状态；但是，它最终感觉像是历史修正主义。
3. 灵活性。Git 没有提供很多关于如何使用它的线索。结果，人们可能会对他们做事的方式变得固执；而且因为它真的无关紧要，所以可能会导致开发人员之间的紧张关系。

您说您的 Git 团队协作演讲不仅仅是关于如何从命令行运行 Git 的教程——它是一次工作流程的全面改革。Git 将如何帮助改进团队的工作流程？

Git 非常灵活，因此就其本身而言，它在选择您的团队希望如何协作方面不会有太大帮助。本次研讨会旨在让团队思考他们*希望*如何协作。QA 是否应该有最终签字权？每个人都应该写入同一个存储库吗？您是否需要遵守法规审计？

这些是我在研讨会上帮助人们规划出的难题。一旦人们了解了他们希望如何相互协作的蓝图，以及他们的“政治”约束是什么，就更容易将相关的 Git 命令映射到您的工作流程图中。

是否有任何团队应该避免使用 Git，因为它只会使他们的工作流程更糟？

对他们现有的版本控制系统非常满意，并且正在使用具有良好的社区或供应商支持的软件的团队，可能不适合切换到 Git。重新调整您的工作流程很困难，所以如果事情进展顺利，我认为不值得为了“仅仅因为”而切换的启动成本。

当为新项目实施 Git 工作流程策略时，您看到团队领导常犯的几个错误是什么？

当我实施 Git 工作流程时看到的常见错误，实际上与 Git 无关……但 Git 最终因这些潜在原因而受到指责。

“我不明白！”通常是团队成员之间通过代码进行交互的方式不明确的委婉说法。您可以通过与您的团队讨论他们理想的工作方式，然后与他们合作将 Git 命令映射到团队期望的工作流程来缓解这个问题。是的，有一些常见的约定（GitFlow、GitHub Flow、Agile Git 等），您的团队最终可能会使用其中一种约定，因为约定通常建立在许多团队的良好实践之上。人们常常忘记团队的一部分，而只是投入到一组任意的规则中。考虑您的整个团队：从设计到部署——不要忘记 QA 和安全！与每个人交谈，了解他们希望如何参与代码，以及是否有任何监管要求会影响您将代码推送到管道的方式。

“这怎么工作？” 或有时 “哎呀！这个提交历史真是一团糟！” 这是人们由于缺乏文档而以不一致的方式使用 Git 的委婉说法。管理人员和团队需要坚持提供关于工作流程如何工作的最新、随时可用的文档（包括可复制粘贴的 Git 命令）。我们为支持未来的自己和新员工做得远远不够。通过拥有该文档，您可以确保团队使用 Git 的方式完全相同。如果您想在使用高级调试技术时获得可预测的信息，一致性非常重要。(不幸的是) Git 核心不会帮助您强制执行这种一致性。

“……”沉默是最糟糕的！我认为我们需要花更多时间与人们一对一地交谈，了解我们实际如何使用 Git。有时承认您不知道如何向整个团队做某事可能会让人感到紧张。我们需要确保人们有定期的——理想情况下，是安排好的——方式来提问，并与他人分享他们学到的东西。技巧和窍门可以编入文档，并且可以将困惑点用于澄清书面说明。

对于 Git 新手，并且需要在深入研究您的 O'Reilly 使用 Git 进行协作 视频和 Git 团队协作 书籍之前掌握基础知识的人，您会推荐哪些免费在线资源？

• 资源：我有一个不断增长的 一流资源列表。它按类别排序，例如团队治理、提交消息、可视化 Git、合并与变基等等。我尝试提供一个经过深思熟虑的资源平衡列表，我认为这些资源对人们有用。
• 新闻：如果您有兴趣关注 Git 开发（您应该关注——它比我最初意识到的要活跃得多），git.github.io 是一个新网站，其中包含每月对 Git 新版本中即将推出的内容以及一些更有趣的社区倡议的总结。
• 技巧和窍门：Twitter 上的 @bestgit 每天都有精彩的技巧分享。

本文是 OSCON 2015 的 演讲者访谈系列 的一部分。OSCON 涵盖了所有开源内容——全栈，包括您在日常工作中使用的所有语言、工具、框架和最佳实践。OSCON 2015 将于 7 月 20 日至 24 日在俄勒冈州波特兰举行。.