回购协议应该承诺什么?

您编写/创建的任何内容都应处于修订控制之下。

生成的文件(.class文件,生成的代码)不应该是 在修订控制下:确保所有团队成员 提供相同的编译器/生成器。

总的来说,我会尽可能经常地承诺,确保 提交的代码工作正常(编译正常,所有测试通过)

如果您与团队一起工作,一个好的一般规则是只有工作代码被提交到repo。如果你有测试,它应该有测试,所有的测试都应该通过(绿色)。

如何处理部分完成的功能实际上取决于您的团队和代码的使用方式。在我的项目中,我试着让代码准备好投入生产,所以如果有一个部分特性,它在用户界面中以某种方式是“隐藏”的。还有一些团队允许repo在发行版之间稍微移动。真的取决于队友和释放周期。

将部分完成的代码检查到您自己的分支中似乎是完全正确的。分支的创建和维护成本相对较低,并提供了良好的备份机制。

大多数人都同意的唯一一件事是:经常承诺。如果你做了一些愚蠢的事情或者硬件出现故障,所有已经承诺的都是保存的,其他的都可能丢失。

至于在哪里承诺——这是你和你的同事需要达成一致的。有很多不同的方法可以做到这一点,你需要找到一个适合你的工作流程。

例如,您可以选择只将compiled/tested/whatever代码提交到主干,这样它(几乎)总是可用的;其他所有代码都将进入功能分支,这些分支只有在它们是compiled/tested/whatever时才合并到主干中。或者你可以同意让每个人都愉快地在主干上投入(这样总是不稳定的)并分支出稳定的分支。我肯定还有很多其他的惯例我现在想不起来。

如果你在进入“后备箱”之前询问什么是要求,答案是 它取决于 使用的工作流。

还要注意,“trunk”的概念并不是git存储库中所必需的;例如,您可以使用“master”(稳定分支;好吧,您可以调用it trunk)、“maint”(维护分支,那里只应用错误修复)和“next”(开发分支)。

但我们假设 “大师” (你所说的后备箱)是唯一 出版 分支机构。在 主题分支 工作流为每个分支创建新的独立分支(几乎每个分支:单个提交更改和修复可以直接应用于“master”),并在准备就绪时将其合并到“master”中。

总结这个(和其他)答案:

• 只把完成的工作放在“主人”身上
• 不要破坏建筑
• master中的提交应该通过testsuite
• 不将生成的文件置于版本控制之下

这完全取决于你想如何工作,但这里有一些值得思考的东西:

我喜欢的一种工作方式是有一个后备箱和一个释放分支。在适当的时候对trunk进行更改并合并到发布分支中。

如果您将逻辑工作单元提交给trunk,那么您就有了一个很好的基础,可以将特定的修订(以及因此而产生的特性)选择到一个发布分支中,并且您在trunk的历史中也有一个关于项目开发的好故事。如果您提交所有内容是因为现在是星期五下午,那么可能很难为您的发布分支挑选出一组连贯的特性(如果您有),并且很难写出好的提交注释。

但你需要平衡这一点,经常承诺保护你的工作,并从你的工作副本中获取价值。不稳定的开发分支是这方面的理想选择。分支可以是短生命的,并在逻辑/功能点合并到主干中。如果你仅仅因为距离上次提交已经20分钟了而提交,那么这些都不会受到惩罚,而且分支的故事可能非常简单,以至于你不太关心个人细节。

然而,只有当您拥有一个足够复杂的开发环境时,这才是相关的—如果您不太可能在发布或同时管理一个项目的多个版本时阻止特定的更改,这可能是不值得的。

将构建项目所需的所有内容提交到其当前状态(不再提交)。

至少我一直在提交半个完成的特性,但即使半个完成,当然也必须是 工作代码 这不会破坏/破坏项目的其余部分。

在给定的存储库中,您应该提交源(或输入)以生成给定项目所需的输出。通常这是源代码,输出是某种可执行实体。

不应将作为任何生成步骤的一部分生成的输出或中间输出提交到与源相同的存储库中。您可以选择将中间输出或最终输出存档到单独的受控存储库中。将中间文件与源文件放在同一个存储库中会导致不一致的可能性,并模糊了在源代码管理工具中保留源和唯一真实源的严格边界。

您应该尽可能频繁地提交检查点,但您应该只与其他开发人员正在处理的任何集成分支集成(推/合并),而您的更改不会损害它们,无论是通过中断项目的构建还是主要功能。

对项目/产品有任何影响的一切。

跟踪变化的成本很低,当有人寻求一个特定的特性 存在的 在最初的迷雾中

这是我的清单

• 需求文件
• 设计文件
• IDE工作区定义
• 图书馆
• SQL
• 源代码和生成的文档
• 测试数据
• 测试用例
• 测试用例结果

如果分支是本地的,则应尽可能提交,因为在将其推送到远程存储库之前,您应该能够撤消或更改它们。

对于其他人共享的远程分支,只有在单元测试没有中断时才发布它。

很多人都在回答这个问题,但我还是会把帽子扔进戒指里。

简单的回答是:对于您编辑的文件,如果不自动生成,请尽可能频繁地提交。

冗长的回答被重新表述为一个稍有不同的问题。更适合团队的问题是我应该“推动”什么。本地提交是为您准备的,应该这样使用。

我应该推动什么的问题与我应该承诺什么的问题有点不同。首先,您应该只推送工作代码,因为您的团队定义了工作代码。理想情况下,通过测试并编译/运行而不中断的代码。(它是否定义为只有完整的特性取决于您)然而,由于git可以自由地重写历史,所以您有两个选项可以选择如何将它们推送到中央存储库。

• 如果您希望中央存储库有一个干净、无噪音的提交日志,可以将某个功能的提交压缩为一个提交 之前 推到远程回购。(注意:只有在没有其他人从你身上拉过的情况下,这才有效)。
• 如果你不在乎中央回购的提交日志有多吵,那么只需推送你已经做过的所有小的提交,就不用担心了。