我想知道，通常会将哪种代码提交给项目仓库（分支机构，而非主机代码）？
仅限完整功能？提交半完成代码是否被认为是错误的/不赞成的？
答案 0 :(得分：4)
您编写/创建的任何内容都应受版本控制。
您生成的（.class文件，生成的代码）不应该是 在修订控制下：尽管如此，确保所有团队成员 有相同的编译器/发电机。
总的来说，我会尽可能多地投入，确保 已提交的代码可以正常工作（编译好，所有测试都通过）
答案 1 :(得分：2)
如果您正在与团队合作，一个好的一般规则是只有工作代码才会提交给repo。如果你有测试，它应该有测试，所有测试都应该通过（绿色）。
如何处理部分完成的功能实际上取决于您的团队以及代码的使用方式。在我的项目中，我尝试保持代码准备推送到生产，所以如果部分功能在，它以某种方式从用户界面“隐藏”。还有其他团队允许回购在版本之间稍微漂移。真的取决于队友和发布周期。
将部分完成的代码检查到您自己的分支中似乎完全没问题。分支的创建和维护相对便宜，并提供良好的备份机制。
答案 2 :(得分：1)
大多数人唯一同意的是：经常提交。如果你做了一些愚蠢的事情或硬件故障，那么已提交的所有内容都是保存，其他一切都可能丢失。
至于何处承诺 - 这是你和你的同事需要达成一致的事情。有很多不同的方法可以做到这一点，你需要找到一个适合你的工作流程。
例如，您可以选择仅将可编译/测试/任何代码提交到主干，以便它（几乎）始终可用;其他一切都将进入功能分支，只有在可编译/测试/无论什么时才会合并到主干中。或者你可以同意每个人都乐意在主干上放弃（因此总是不稳定）并分支稳定的分支。而且我确信现在还有许多我无法想到的其他惯例。
答案 3 :(得分：1)
如果您在“主干”中进行评分之前询问的是什么要求，答案是取决于所使用的工作流程。
另请注意，“主干”的概念不是Git存储库中必需的内容;例如，你可以拥有'master'（稳定的分支;好吧，你可以把它称为主干），'maint'（维护分支，只有错误修正在那里应用）和'next'（开发分支）。
但我们假设'master'（你称之为trunk）是唯一 发布的 分支。在主题分支工作流中，您可以为每个创建新的单独分支（好吧，几乎每个：单个提交更改和修复可以直接应用于'master'），并在准备就绪时将其合并为“master”
总结这个（和其他）答案：
答案 4 :(得分：1)
这一切都取决于你想要的工作方式，但这里有一些值得思考的东西：
我喜欢的一种工作方式是拥有一个主干和一个发布分支。对trunk进行更改，并在适当的时候合并到release分支中。
如果你将逻辑工作单元提交到主干，你就有了一个很好的基础来挑选一个发布分支中的特定修订（以及特性），你也可以在你的项目开发中得到一个很好的故事。树干的历史。如果你因为星期五下午而提交了所有内容 - 可能很难为你的发布分支选择一套连贯的功能（如果你有的话），并且很难写出好的提交注释。
但是你需要平衡这一点，经常承诺保护你的工作，并从你的工作副本中获取价值。不稳定的开发分支是理想的。分支可以是短暂的并且在逻辑/功能点处合并到主干。如果你只是因为你上次提交的时间已经过去了20分钟，这些就不会受到惩罚，而且分支的故事可能非常简单，你不会过多关注个别细节。
但是，这只有在您拥有足够复杂的开发环境时才有意义 - 如果您不可能同时从发布版本或管理项目的多个版本进行特定更改，则可能不值得
答案 5 :(得分：0)
将构建项目所需的所有内容提交到当前状态（不再需要）。
至少我一直在提供一半已完成的功能，但即使半完成它当然必须是工作代码，不会破坏/崩溃项目的其余部分。< / p>
答案 6 :(得分：0)
在给定的存储库中，您应该提交源（或输入）以生成给定项目的所需输出。通常这是源代码，输出是某种可执行实体。
您不应将作为任何构建步骤的一部分生成的输出或中间输出提交到与源相同的存储库中。您可以选择将中间或最终输出存档在单独的受控存储库中。将中间文件与源文件放在同一个存储库中会导致出现不一致的可能性，并使源代码管理工具中保持源和唯一源的严格边界模糊不清。
您应该尽可能频繁地提交检查点，但是只应通过打破构建或主要功能来集成（推送/合并）其他开发人员正在处理的任何集成分支。该项目。
答案 7 :(得分：0)
对项目/产品有任何影响的一切。
跟踪变化的成本很低，并且当有人在最早的时间内寻找存在的特定功能时，可以获得良好的红利
离开我的头顶，这是我的清单
答案 8 :(得分：0)
如果分支是本地的，那么随时提交，因为在将其推送到远程存储库之前，您应该能够撤消或更改它们。
对于在其他人之间共享的远程分支，仅当单元测试不中断发布时才会发布。
答案 9 :(得分：0)
很多人回答这个问题，但无论如何我都会戴上帽子。
简短回答是：根据需要随时提交您编辑但不会自动生成的文件。
长回答被重新描述为一个稍微不同的问题。更适合团队的问题是我应该“推”什么。本地提交适合您，应该这样使用。
我应该推送什么的问题与我应该提交的内容有点不同。首先，您应该只在团队定义工作代码时推送工作代码。理想情况下，代码通过测试并编译/运行而不会中断。 （它是否仅定义为完整功能由您自己决定。）然而，由于Git对于重写历史记录是如此自由，因此您可以选择如何将这些功能推送到中央存储库。