git工作流，创建本地分支删除并重新创建

Question

我正在使用git。截至目前，我们是两名正在开展项目的团队成员。截至目前，这两项工作都略有独立，一项专注于UI而另一项专注于apis。我喜欢每天多次登记。我的典型工作流程是：

http://amiridis.net/posts/13

所以我创建了一个功能分支然后处理它，将它合并到main然后推送它。删除分支并重新创建相同的分支。

该产品仍然是第一个版本，我们有一个持续集成构建服务器设置。推动的主要目的是为主管提供增量更新。

我的问题是，

• 如果我还没有完全完成某项功能，如果它仍然是版本1，那么将小型可编辑更改单元推送到主分支上的主服务器是一个好习惯吗？
• 创建分支，合并到main，推送它，删除本地分支然后重新创建它是一个好习惯吗？

Answer 1

问题＃1

  

如果我还没有完全完成一项功能，那么推动它是一个好习惯   主要服务器上的小型可编辑更改单元   分支，如果它仍然是版本1？

没有。将未完成的代码引入主分支通常不是一种好的做法。您应该始终拥有一个模仿生产代码状态的分支。对于大多数人来说，该分支称为master。

为什么这很重要的一个例子是生产中的错误。如果您已经在主分支中引入了一堆完成的工作，那么您发布的任何修补程序也将包括未完成的工作。此外，如果其他开发人员从该分支机构撤出，并且您添加了未经测试的代码，则可能会使其开发变得复杂。

即使您的代码尚未发布 - 您也希望拥有一个仅包含经过完全测试的代码的分支。一般来说，您应该尝试尽可能地降低功能并测试小的更改。如果它们不会对已经有效的其他任何东西产生负面影响，那么它们可以合并到主分支中。

无论你工作，你都应该尝试保持一个具有某种程度的权限的分支机构。 - 仅在满足某些条件后合并的分支。这个标准取决于你。

您可以决定保留一个主分支，它是唯一一次在发布新版本时进行修改。相反，您决定只要您的工作经过测试就可以合并到您的主分支中。您决定如何做到这一点通常取决于发布策略和更广泛的工作流程。

问题＃2

  

创建分支，合并到main，推送它是一个好习惯，   删除本地分支然后重新创建它？

不能回答是/否。关于团队如何处理代码版本化，成员之间的协作以及发布周期，有很多策略。

一般来说，最好在将分支合并到主分支后立即删除分支。通常更好地摆脱并避免继续使用相同的分支（通常称为具有＆＃34;长寿命的分支＆＃34;）。在大多数情况下，短期分支机构在个人开发任务中是首选 - 但是这可能会根据您的团队偏好和选择而改变。

工作流程问题

你有一个小团队，你的代码还没有出现 - 所以压力会降低，解决方案会更容易，因为它只是你们两个。但是，一旦你的产品进入世界，压力将更高，以解决错误 - 释放修补程序/补丁的需求可能会出现。随着越来越多的同步开发，发布周期将变得复杂。随着您向团队中添加越来越多的开发人员，对版本控制有不同程度的理解，协作将更加容易混淆和容易出错。

因此，我建议您在决定工作流程时要记住以下几点。

• 修补程序/补丁 - 如果您已经完成了第2版的一半，但现在您在1.0中发现了一个关键错误，那么在没有包含2.0的不完整工作的情况下发布v1.1是多么容易
• 回滚 - 如果在此过程中引入了错误，您是否可以轻松退出错误的版本？
• 区划 - 尽量不要与没有专门处理相同事情的团队成员共享已损坏或未经测试的代码。如果我在开发过程中总是引入未经测试的代码，我将很难知道错误是由我造成的还是由其他团队成员引起的代码中其他地方的更改。一旦经过测试和验证，我应该只引入其他人的代码。通过保持分支短命，并进行小的，易于测试的更改 - 这些经过测试的更新将更快地到达您的团队伙伴，并且可以更快地捕获错误。
• 协作 - 有时人们实际上需要彼此代码才能继续自己的工作。这就是为什么短暂的，微小的变化很重要。然而，有时两个人在完全相同的事情上工作 - 他们在相同的功能上一起工作。在这种情况下，他们在同一个远程分支上工作是合理的。但请注意，git-reset，git-rebase，执行强制推送或执行任何修改远程提交的操作都会导致您的团队配合受到伤害。分享分支时，请注意分支历史。
• 复杂性 - 团队成员对版本控制的总体理解和git具有不同程度的理解。即使他们都是git专家，通常最简单。任何一个人为了测试某些东西而必须执行的步骤数量，将某些内容合并到权威分支中，或者与其他开发人员共享代码应尽可能保持低水平。这是每个人每天都要做很多次的事情。复杂的过程不仅耗费了开发人员的时间，而且每个人都更容易出错，但更多的是经验较少的人。当其他人努力解决问题时，这些错误可能会导致更进一步的延迟。这种考虑通常与其他考虑相反，因为其他考虑往往意味着增加更多层次的复杂性。只要记得保持这种强制性。

一种流行的工作流程称为＆＃34; git flow＆＃34;，甚至还有command line tool来帮助自动执行相关步骤。作为一个小团队，您可能会发现它过于复杂 - 但我建议如果您有基于迭代的发布周期，这应该是您应该做的最少。

我实际上并不是git-flow的忠实粉丝，但仅仅因为我觉得它实际上过于简单和二维。 （我不是＆＃34的粉丝;分散但集中的＆＃34;，我更喜欢实际分发的工作流程。）

但是，如果您的发布周期非常快 - 在这种情况下，您可能希望采用model that github itself uses。他们的模型类似于你的模型，因为它们只是合并为master - 但是他们只在代码之后才通过一些自动化测试。关于github做什么的关键还在于他们每天部署多次 - 而不像大多数团队那样在发布周期中进行。这使得几乎总能在最近引入生产出来的错误。它是一个更简单的策略，但它不适合所有人，请记住上面的要点，特别是如果你有一个更典型的发布周期。