Tag: 拉取请求
限制您的请求请求，看看会发生什么。 这是我们的故事。
许多开发团队面临的问题是拉取请求的数量不断增加。 您是否曾经听过自己说过“工作完成了，只需要对其进行审核”，只是几天后（或几周）合并？ 信不信由你，我们的iOS团队也遇到了这个问题。 对于我们来说，有22个请求请求进行审查并不少见。 让我们将其放在上下文中：由8个开发人员组成的团队中的22个拉取请求。 如果将所有这些拉取请求都计为进行中的工作，那么我们每个人都会一次执行2.75件事。 似乎大多数人都进行了审查，这也意味着让任何人都对您的请求请求进行审查是一个艰难的过程。 我希望这不是您第一次听到此消息，但是多任务处理是一个神话。 我们人类在这方面非常糟糕。 当我们“多任务”时，我们实际要做的是任务切换（或上下文切换）。 最近加入并认为这是团队中的一个痛点，我觉得我们可以进行两次有趣的练习来突出这个问题。 进入我们的第一个游戏… 第一个游戏：证明您的多任务处理不好 在页面上绘制四列 在每列的顶部写下以下内容之一：“ 1–12”，“ 3–36”，“一月至十二月”和“ 7–84” 目标：填写所有列，以使第一列具有1、2、3等，第二列具有3、6、9、12等，第三列Jan，Feb，Mar等，以及第四列7、14、21等。 时间自己这样做。 第1轮： 通过在每一列中写入一个值来完成所有列，即，随即在各列之间跳转。 （您将在第一行写1、3、1月，7，然后继续到下一行，写2、6、2月，14等。） 这大约需要90-120秒。 前进。 我会等。 第二回合 在继续进行下一列之前，请先完成一列，以完成所有列。 （您将在第一列中写入1、2、3…12，然后移至下一列3、6、9…36，直到所有列都完成。） 这大约需要60秒。 结果 很抱歉将其破坏给您，但像数十亿人一样，您在多任务处理/任务切换/上下文切换方面也很烂。 在第一轮中，您花了几乎两倍的时间来完成所有列，从而付出了任务切换的代价。 在纸上写下月份的数字和名称不是一件容易的事。 想象一下，如果您是在重构，调试生产问题和检查Slack between之间切换任务 第二款游戏：证明您不必编写代码即可做出贡献 现在我们要折一些折纸。 是的，纸折的艺术。 这将需要您的整个团队。 因此，请大家聚在一起。 您可能需要4至8个人。 以下是说明： 我们将建立一条生产线来制造纸船。 在这样的团队成员中（假设有5个人），将说明中的步骤划分为以下几个步骤： 第一个人执行步骤1，下一个人执行步骤2和3，下一个人执行步骤4，下一个人执行步骤5和6，最后一个人执行步骤7、8和9。如果您愿意，可以进行更改有更多的人，但有目的地通过至少给最后一个人更多的步骤来制造瓶颈。 目标：3分钟内制作尽可能多的纸船。 第1轮： 时钟一开始，第一个人就将其折叠，将其传递给下一个人，然后立即抓住新的纸片进行折叠。 然后，队列中的每个人都继续折叠，并尽快将其传递给下一个人。 三分钟后，响起气喇叭并停止。 现在，计算三个指标：成品纸船的数量，未完成纸船的数量（队列中仍有折痕的任何纸张）和团队对质量满意的成品船的数量。 第二回合 这次，如果下一个人当前不忙于折叠，则仅允许每个人将工作传递给下一个人。 为了恰当地表明这一点，如果每个人都不忙于折叠，则双手悬空。 […]
创建GitHub Pull Request的简单指南
作为像Perfect这样的免费开源软件项目，最大的挑战是如何在保持质量和凝聚力的同时，使社区参与。 作为项目“核心”团队的成员，我们经常离代码很近，看不到极端情况，也没有考虑到我们尚未遇到的情况-在这里使用库的人会遇到问题，错误，或优化机会对于项目的成熟至关重要。 幸运的是，git（在我们的特定情况下为GitHub）使用称为“请求”的流程使社区贡献变得容易。 “我很乐意为此做一个请求请求，但我不知道该怎么做” 在我们关于开放社区Slack组的日常讨论中，当被告知有关文档或代码更改的需求时，有人多次评论“我很乐意为此提出请求，但我不知道该怎么做”。 。 好吧，如果您曾经说过或曾经想过并且犹豫要为FOSS项目做出贡献，请继续阅读！ 什么是“拉取请求” “拉取请求”这个术语有点奇怪，除了可能有“补丁”的概念外，它与git社区以外的任何事物都不能很好地等同。 实际上，拉取请求（也称为PR）是您提交代码更改同时促进公开对话和审阅的一种方法。 PR的简单解释是： 您可以修改自己的git存储库副本 一旦感到满意， 就会触发一个请求，将您的更改合并到原始存储库中，并说明您的操作以及原因 然后，项目管理员会查看您的更改并接受更改 ，或者就更改进行讨论。 实际中的拉取请求 为了逐步演示您作为读者的身份如何进行PR，我将描述对Perfect Documentation资源库进行PR的过程。 Perfect项目的整个文档集都是开源的，我们会定期更新主站点上的HTML版本-从GitHub存储库的Markdown文件生成。 这意味着，如果发现拼写错误或可以做出的改进，那么您将有能力提供帮助！ 因此，我今天注意到CouchDB驱动程序文档中提到的版本不正确：它引用的majorVersion为0，应为1。 回到源代码的GitHub回购页面https://github.com/PerfectlySoft/PerfectDocs/blob/master/guide/CouchDB.md，我可以看到它也已经过时了，因此需要更改。 第一步，“分叉”存储库。 哇，更多git术语：“ fork”是在特定时间点故意创建的版本库。 想象一下，如果您沿着森林步道走，突然之间的路径被分成两部分，这就是“叉子”。 一个路径可能会继续到达预期的目的地，而另一条路径可能会将您带向完全不同的方向……有时会合并回到原始路径中。 “叉子”是在特定时间点故意创建的版本库的新版本。 要创建Perfect文档存储库的分支，请使用GitHub页面右上方的“ Fork”按钮。 然后，您会看到一个对话框，询问您要将新叉子放置在何处。 选择一个位置：您的列表可能比我的列表更短或更长时间…… 现在我们有了自己的fork，可以编辑文件了。 编辑并提交更改 对于我们将要进行的小更改，GitHub用户界面使操作变得简单。 对于更广泛的更改（尤其是涉及代码），建议将新的存储库克隆到本地环境，并在提交之前使用Xcode之类的IDE来编辑和测试代码。 看到此演示正在更改文档的一小部分，我将直接在GitHub UI中进行编辑。 在页面上以自己的仓库查看文件时，您会看到一个铅笔图标，用于进入编辑模式： 单击此按钮将使您进入编辑模式。 滚动到要更改的位置-在我的情况下，我想将“ 0”更新为“ 1”。 完成更改后，向下滚动至页面的“提交消息”部分，然后输入有关更改内容的简短说明： 现在，此更改仍在您的文档存储库副本（分叉）上，因此下一步是将路径重新组合在一起。 提交您的拉取请求 当查看分叉存储库的“根”（也显示自述文件的根）时，您将看到一个标有“新请求请求”的按钮。 单击此按钮将带您进入一个页面，该页面专门向您显示您的版本与父版本之间的所有差异。 它还会通知您是否存在任何妨碍成功的合并冲突。 单击绿色的大按钮“创建请求”，然后您可以借此机会总结在PR中所做的所有更改。 现在单击“创建请求请求”将在父资源库中向您显示可公开查看的PR条目。 请注意，有一个橙色的“ CLA助手”注释，以及一条消息“某些检查尚未完成”…… 该“ […]
