Get best of the week

工作周的最后一天即将结束...

工作周的最后一天结束了。我在办公室厨房里喝咖啡，自己想知道如何减少请求池的队列，在引入审阅指南后，请求池已大大增加。看来，简单的规则导致评论与审阅团队成员与框架开发人员之间的请求库产生了较长的对应关系。

图片

没有预示。天开始黑了。

突然，一个正在工作的聊天声中沙沙作响：
-为什么我的请求请求被删除？
-我的请求被撞了！
-我的！

经过仅仅几分钟的投资，我们发现发生这种情况是因为有人删除了Bootstrap工作分支，该分支中有40多个人走私了三个多月。为了能够完全解决问题，再次有40个人在这里花了三个多月的时间。

图片

同事们立即开始想到我们都拥有该分支的本地副本，然后让我们从头开始创建该分支。

根据我自己的经验，我知道草率的决定和即兴创作不会带来任何好处，因此我要求所有人不要采取任何行动，而应从字面上“松开键盘”。

图片

因此，处理方式是星期五晚上，几乎是空荡荡的办公室，一个丢失了巨大代码基础的分支。如果您暂时不解决此问题，那么如果其他不了解当前情况的开发人员在周末与工作联系在一起，则情况可能会变得更糟（我们都仔细阅读了工作聊天，对吗？）。

我在聊天中礼貌地询问了谁删除了Bootstrap分支，最近加入该工作的一位年轻开发人员承认他是错误地这样做的。 “抱歉”。

图片

我聘请了一位成功举足轻重的专家，我们急忙赶到一位年轻的开发商，此人目前正面临生存危机，而他的工作场所很幸运地与我们位于同一办公室。

当然，我们恢复了分支-有点git magic，一切都解决了。您不能说在GitHub的肠子中消失了超过20个拉取请求。不愉快，但不是致命的。
是时候喘口气，弄清楚发生了什么并得出一些结论。

图片

主要问题是为什么？通常，答案是微不足道的-偶然。提交到其自己的工作分支的代码有问题-没什么犯罪，它只是丑陋的代码，即使您撤消提交，它仍然保留在历史中。因此，开发人员决定拆除其整个工作分支，然后重新创建它。从头开始。而Bootstrap分支受到了热烈欢迎。星期五。晚间。 Misklik，是的。

图片

GitHub允许您取消删除操作，但只能在页面更新之前，并且没有使用此机会。

可以避免这种情况吗？是的你可以。默认情况下，对您的存储库具有写访问权的任何人都可以删除任何分支。但是，GitHub允许您为一个或多个分支创建分支保护规则。

图片

重要的是要确保未选中相应的复选框。

图片

对于bootstrap分支并没有做到这一点，它赶上了我们。

在干残渣中：

  1. 他们保存了分支。
  2. 现在，在有多个人参与的任何分支上，我们都将安装保护规则。我建议不要忘记做所有事情。
  3. 为支持自举包在JDI轻，我们最终实现和推出。但这是什么以及为什么-那是另一个故事...

More articles:


All Articles