提交非工作代码可以吗？

要求仅提交工作代码是个好主意吗？

此提交无需使存储库处于工作状态，如下所示：

• ...我们正处于早期设计阶段，代码尚不稳定。
• ...您是该项目的唯一开发人员。你知道为什么事情不起作用。此外，您不会通过提交损坏的代码来停止任何人的工作。
• ...该代码目前无法正常工作。我们将对其进行重大更改。让我们承诺，以便在事情变得丑陋时有一点可以还原。

• ...链很长，如果本地分支中存在损坏的代码，则不会有任何麻烦。即

  1. 本地文件
  2. 暂存区
  3. 提交到本地分支
  4. 提交到远程个人功能分支
  5. 与远程develop分支合并
  6. 与远程master分支合并
  7. 与远程release分支合并

• ...提早提交，经常提交。

因此，在上面链接的问题中，大多数答案都说，提交不可编译的代码在本地和功能分支中没有问题。为什么？提交失败的价值是什么？

补充：有几条备受赞誉的评论，说在当地一家人可以做任何想做的事。但是，我对该问题的技术方面不感兴趣。相反，我想学习最佳实践-习惯，这些习惯在行业中已经工作了很多年，他们的工作效率最高。

我惊讶于大量的出色答案！他们得出的结论是，我不擅长使用分支来组织代码。

分支机构的一种哲学（高级SCM分支机构中的“开发分支机构策略和代码行策略”部分-另请阅读Perforce最佳做法，其pdf格式，但还会涉及其他一些细节）是您基于不兼容的策略进行分支。

代码行策略指定了代码行的合理使用和允许的检入，并且是代码行SCM的基本用户手册。例如，开发代码行的策略应声明它不适合发布；同样，发布代码行的策略应将更改限制在已批准的错误修复程序之内。该策略还可以描述如何记录正在签入的更改，需要进行哪些审核，需要进行哪些测试以及签入后对代码行稳定性的期望。策略是文档化，可强制执行的软件开发过程的关键组成部分，从SCM的角度来看，没有策略的代码行已失控。

（摘自Perforce最佳实践）

假设您有分支“ release”（或“ master”）（从中构建版本）和“ trunk”（或“ dev”），开发人员在其中检入工作代码。这些是分支机构的政策。注意“工作代码”是“ dev”分支策略的一部分，永远不要将损坏的代码提交给dev分支。通常，诸如CI服务器会挂接到这些分支，并且将损坏的代码检入dev中可能会使每个人的分支混乱并破坏构建。

但是，有时需要检入不起作用的部分代码。在这些情况下，应该分支-与中继不兼容的策略。在这个新分支中，可以决定策略（“可以使用断码”），然后将代码提交给它。

有一个简单的规则来确定是否应分支代码行：当用户需要不同的签入策略时，应该分支代码行。例如，产品发布组可能需要强制执行严格测试的签入策略，而开发团队可能需要允许对部分经过测试的变更进行频繁签入的策略。这种策略差异要求代码行分支。当一个开发小组不希望看到另一个

（摘自Perforce最佳实践）

意识到这来自具有强大公司思维的基于中央服务器的SCM。核心思想仍然是好的。这些通常被隐式考虑-您不要将未经测试的开发代码签入release分支。那是一项政策。

因此，分支，说该分支可以破坏代码并提交。

Linus Torvalds提出的一种哲学是创造性编程应该像一系列实验一样。您有一个想法，并遵循它。它并非总是可行，但至少您尝试过。您想鼓励开发人员尝试创新的想法，并且要做到这一点，尝试该实验必须便宜，而要恢复则必须便宜。这就是git commit如此便宜（快速又容易）的真正力量。它打开了这种创造性的范式，使开发人员可以尝试其他方法可能没有的东西。这是git的解放。

是的，只要它不是发行分支。

在个人分支机构中，一切都进行了，如果实验不起作用，则可以将其丢弃。这是DVCS的主要优点之一：自由

提交破损代码的价值是什么？：协作与实验

是的，还可以，我经常这样做。

提交不可编译的代码（至少在分支中）的要点是，有时您的代码是正在进行的工作，但是到目前为止所做的工作值得保存和/或与他人共享

我的做法是：

• 先写测试
• wip（正在进行的工作）提交很好
• 经常（一天内多次提交）和早期（节省“工作”步骤）进行提交
• 在每次提交后推送（以防您的硬盘驱动器崩溃/总线撞到您）。
• 总是先在分支机构工作
• 如果可能，仅合并工作代码以掌握
• git中的交互式rebase以在主合并之前压扁wips

主要问题（也许是您正在接触的问题）是，当您拥有一项基本功能正常且企业非常需要的功能（因此需要处于“主”角色）但测试失败时。这里的一种选择可能是进行待定测试，让您暂时前进。但是，这充满了危险，因为测试可能永远无法修复，并且可能会在其他区域设置一个模式，即仅“挂出”已损坏的测试而不是对其进行修复。

另一个选择是临时使用和部署分支。这在某些情况下可能会有所帮助，但通常不建议这样做，并且不可持续。

也许最好的选择是从根本上采取更专业的方法进行软件开发，并确实需要对任何已提交的代码进行工作测试。这通常是软件开发的“硬”部分，而不是许多人想象的编码。更好的方法可能需要在敏捷开发过程中进行更好的初始估算，资源分配，优先级设置等，并留出足够的时间并使用足够的纪律来解决在问题发生时以及在修饰过程中的所有问题（指向会议）。

关注“完成”的含义-这意味着代码和测试已编写，已重构并可以正常工作。如果您听到诸如“大多数情况下已经完成，只需要编写/修复/重构测试”之类的评论，则说明该功能尚未完成。说一个功能在技术上不完整就完成了，这是初级程序员最常见的错误之一。

任何提交（无论是否中断）的值都是将代码提交到服务器。在专业环境中，该服务器是安全，冗余且正在运行的备份。如果我整天工作，提交是一种确保我的代码能够在本地计算机上生存的任何形式。硬盘坏了。笔记本电脑会丢失或被盗。即使建筑物被烧毁，存储库服务器的备份也将可用。

这样想吧。作为开发人员，您最具破坏力的事情之一是阻止团队中的其他开发人员执行任务。

仅提交工作代码的理念来自开发团队，他们在存储库中的同一主干上工作。现在看似疯狂，但是10年前，这是正常的工作方式。当您想创建一个稳定的发行版时会出现一个分支，但是几乎没有听说过开发人员在分支中工作以实现新功能的想法。

如果您的环境意味着您的提交不会立即影响其他开发人员，那么请经常进行提交。它为您的代码提供了更高的安全性，使您更容易回退代码错误，并且许多源代码控制系统为您提供了对已提交代码的某种代码保护（尽管不是全部）。

现在，确保您与其他开发人员共享的分支的合并能够正常工作，并且您升级到此级别的任何代码都可以编译，通过所有单元测试和其他基于团队的健全性检查……如果您不想这样做，这是必不可少的继续在酒吧里买啤酒...

在开始教条如何使用版本控制之前，值得思考一下为什么要使用版本控制。

致力于版本控制会冻结代码的状态，以备将来参考-其他所有内容均不在此列。查看差异和制作补丁程序只是在看快照之间的代码变化。分支和标签只是组织快照的方法。与其他开发人员共享代码只是让他们查看特定的快照。

你什么时候犯？如果有合理的机会，将来您将查看代码的状态（或解释更改的提交消息）。

Git在如何组织快照方面为您提供了很大的灵活性。没有中央存储库，因此您可以与其他开发人员共享代码，而无需将状态推送到“主”存储库。您可以轻松地创建，合并和删除分支，以将一组状态的详细信息与主代码的叙述隔离开来。您可以在本地进行提交，以帮助您撤消对当前开发的关注，然后将所有内容分批提交到单个提交中，然后再推出以供其他人查看。您可以标记特定的修订，以便以后查找。

KISS。在小型项目的早期开发中，对单个开发人员最有效的方法将与当拥有一百名开发人员在具有十年历史的任务关键型系统上工作的开发人员完全不同。在任何软件开发过程中，您都应避免创建不必要的工件，因为其他人告诉您要这样做。

建立/发布分支

您永远不应故意将损坏的代码提交给build分支。任何处于持续集成状态或从其发布或日常构建的分支都应始终处于潜在可释放的状态。

其他分支：经常保存状态

对于私有或功能分支，目标通常是不同的。经常检查代码（无论是否工作）是可取的。通常，您将需要在可能需要倒回当前状态的任何时间进行提交。

考虑以下示例，其中保存的状态可以带来很大的好处：

• 您可能在运行全局搜索和替换之前立即执行提交，这样，如果出现问题，可以通过一次操作还原树。
• 您可能会在重构复杂的代码段时执行一系列临时提交，以便在过程中破坏某些内容时可以平分或倒退。
• 如果您想尝试一些实验性的事情，并且可以随时返回到当前工作树的状态，则可以执行提交，启动新分支或创建标签。

只要是本地代码，就可以提交一些损坏的代码库。

为什么？

• 在开发中使用提交作为保存点至关重要
• 它向您展示了在开发产品时使用的思维模式。
• 它不会破坏协作。

然而，当有一个程序员团队的哲学编程的房子是最重要的，并取代个人提交的行为。一些编程公司决定记录所有进度，而另一些编程公司决定仅提交解决功能的代码。在这种情况下，损坏的提交的值（从软件管理的角度来看，cost是可怕的）：

1. 现在花了更多的时间来修复错误...
2. 发展削减没有达到...
3. 产品未按时发货

可以将其他几点加到这三个方面，将它们的影响按指数级联到公司崩溃中……当然，这必须是长期习惯性提交错误代码的影响。

我认为提交损坏的代码不是可以的。

如果发生什么情况

• 需要紧急修补程序。代码库处于损坏状态。您被迫回滚，修复和部署。

• 别人开始在同一个分支中工作，不知道您已提交了损坏的代码。他们可能正在追逐“红鲱鱼”，以为自己的变化破坏了某些东西。

• 您决定离开公司，去度假或出于任何原因无法上班。您的同事将必须深入研究，以找出损坏的内容以及为何在损坏状态下执行该操作。

• 有人部署您的“破损代码”？如果您使用个人数据或使用支付提供商，这可能是一场“游戏大战”。

回复@WarrenT

我同意您的看法，在每个人都在功能分支中工作的理想世界中，提交不起作用的代码可能会起作用。我从事大型项目，即使在那时，仍然有多个人必须在一个功能分支中工作。我还看到人们向主分支提交“不起作用”的代码，因为发布已经有几周了，他们计划在第二天修复它。所有这些都是灾难的候选者，我坚信应该不惜一切代价避免发生这些事情。

一些问题可以帮助您确定是否可以提交非工作代码：

1. 你工作过度吗？
2. 您的队友会不断打破常规吗？
3. 您的代码库是否一团糟，看起来不会变得更糟？

如果您对以上任何一项说“是”，那么可以提交非工作代码。

只要记住要尽快修复它，用任何适用的单元测试将其覆盖，并为破坏该版本而道歉。