最佳实践 Git答案

【问题标题】：Best practice Git最佳实践 Git
【发布时间】：2023-04-08 21:26:01
【问题描述】：

我想了解在 GIT 世界中处理以下常见场景的“最佳”方式。我的 Scrum Sprint 刚刚开始，我开始着手编写用户故事。

对于那个用户故事，我必须实现一个新类（“FakeClassA”）并公开 10 个彼此不相关的独立服务方法。例如：

public class FakeClassA
{
   public static firstMethod()
   {
      System.debug('Hey firstMethod');
   }
   ...

   public static tenthMethod()
   {
      System.debug('Hey tenthMethod');
   }
}                                                  

public class FakeClassA_Test
{
   public static void firstMethod_Test()
   {
      System.debug('Hey firstMethod');
   }
   ...

   public static void tenthMethod_Test()
   {
      System.debug('Hey tenthMethod');
   }
}

此开发将占用整个 Sprint，但我希望避免等到最后一天才创建包含所有已开发代码的 Pull Request，因为我可以轻松顺利地进行代码审查。

我怎样才能以正确的方式处理这个过程？

我知道我应该在准备好并经过测试后提交每段代码，但这意味着什么？第一个方法和相关单元测试的一个提交，第二个方法和相关单元测试的另一个提交，等等。但是拉取请求呢？我应该在每次独立提交后打开一个拉取请求吗？即使已经合并，我是否应该重用相同的分支（和相同的 Pull Request）？

我希望我的意思很清楚。

谢谢

【问题讨论】：

我投票结束这个问题，因为它不是一个编程问题。尝试软件工程堆栈交换：softwareengineering.stackexchange.com

标签： git commit pull-request

【解决方案1】：

我的第一印象是你的故事太大了。您必须实现 10 个不同的端点，并且您想测试每个端点的废话吗？那是几个不同的故事。试着把它分成几个不同的块。我团队中的大多数人都害怕审查巨大的 Pull Requests，因此我们尽量减少更改。

如果不可能，请在一个 PR 中完成所有操作。如果你做了一些团队其他成员讨厌的事情（因为你必须做出很多改变），那就糟透了，但至少他们不会因为这里和那里的一点点改变而被纠缠死。最好全部在一个 PR 中提交，进行所有更改，然后再次提交。

但就像我最初所说的那样，您确实应该考虑将其分解为更小的故事。

您倾向于不等到 sprint 的最后一天，这是一个很好的选择。尽早提交：

人们将有机会对其进行审核
您将有时间进行任何请求的更改

【讨论】：