描述使用版本控制（VCS或DVCS）的工作流程

 

我想在使用vcs或dvcs时学习其他人的工作流程。

请描述您的策略来处理以下任务：

  • 实现一个功能
  • 修复错误（在开发和部署应用程序期间）
  • 代码审查
  • 重构代码（发布代码审查）
  • 加入补丁
  • 发布你的应用的新版本（桌面，网页，手机，你会不同地对待他们？）

    • 随意组织您的答案，不按任务分组，但按照您认为相关的任何分组进行分组，但请由VCS / DVCS组织（请勿混用）。

    谢谢。

    所有VCS在提到的各种任务中使用的主要特征是分支 ：以协作方式隔离开发工作的能力。 由于它是一个中央VCS，一些开发人员可以在同一分支上进行协作，对文件进行悲观或乐观锁定，以便开发平行历史记录。

    但作为VCS对分支有两个主要影响：

  • 它倾向于阻止提交，因为一旦提交了一个文件，它将立即以相同的配置影响其他视图的工作空间（即“在同一分支上工作”）。
    〜“出版”过程是一个积极的过程，会产生直接的后果，
    〜“消费”部分（更新您的工作区）是被动的（您必须在更新工作区时立即处理由其他人发布的更改）
  • 它适用于线性合并工作流程 （即“仅从分支A合并到分支B，不在两个方向混合合并” - 从A到B到A到B ...）。 合并是微不足道的，A的所有修改都会简单地结转到B中

    • 现在：

    实现一个功能

    任何VCS都会通过创建一个分支来实现这一点，但是令我非常惊讶的是，“特性”分支并不容易：
    *功能可能变得太复杂
    *它可能会及时准备下一个版本
    *只有部分可能需要合并回主开发分支
    *它可能取决于尚未完全完成的其他功能

    因此，您需要小心处理功能分支和提交的方式：如果它们与同一个功能紧密相关，那么它会很顺利（当您需要它时，将整个事件合并回您的主开发分支） 。 否则，部分合并对于这些工具并不容易。

    修复错误

    开发期间和发布后的错误修复之间的区别在于，在前一种情况下，您经常可以在同一分支中进行线性修改，因为在后一种情况下，您将不得不建立一个错误修复分支，并决定哪些错误需要回到当前的开发分支。

    代码审查

    它最好与外部工具（如Crucible）一起使用，并广泛使用VCS功能（如责任或注释），以便在审查后更好地分配代码修复。

    重构代码（发布代码审查）

    如果重构很小，它可以在同一分支中继续。 但是如果它很大，需要设置一个特殊的分支，并在开始重构之前完成单元测试。

    加入补丁

    与最后一点相同的评论。 如果补丁很大，需要创建一个分支。

    发布您的应用的更新版本

    VCS在发布您的应用程序时只会让您感到满意，因为它不是发布管理工具。
    您将需要以前识别要发布的版本（标签），但在此之后会出现部署过程，其中包括：

  • 停止当前正在运行的内容
  • 复制新文件
  • 部署它们（更新sql数据库，webapp，...）
  • 实例化所有配置文件（使用正确的值，地址，端口号，路径......）
  • 重新启动（如果您的系统由多个组件组成，请按照正确的顺序重新启动它们！）

    • VCS和发布管理的关键是：

  • 它们不太适合存储要发布的二进制文件，这意味着您需要它们来构建应用程序，而不是存储最终的可执行文件
  • 他们在生产环境中并不总是受欢迎的（安全约束限制了写入访问，以及在这些平台上运行的工具数量，本质上是监控和报告工具）

    • 发布机制也会影响二进制相关性：

  • 对于外部二进制依赖关系，您可能会使用像maven这样的机制来获取外部库的固定修订版
  • 但对于内部依赖关系，如果您不是只开发一个应用程序，而是依赖于其他应用程序，则需要知道如何引用由其他应用程序生成的二进制文件（内部二进制依赖项），并且通常不会存储它们在您的VCS中（特别是在开发阶段，您可以为其他应用程序生成许多不同的版本以供使用）

    • 您也可以选择使用源代码依赖项（并获取您自己需要的其他内部项目的所有源代码），并且VCS可以很好地适应这种情况，但重新编译所有内容并不总是可行的。

    与来自VCS的DVCS （分布式版本控制）的主要区别在于它（根据其分布式工作的本质）完成一件事，而且是一件好事：

    合并 。

    所以你可以从这个角度看待你提到的任务。
    分支仍然会被创建，但并不是所有的分支都会被其他开发者看到。 其中很多将不会真正离开您的本地存储库。

    作为DVCS对合并有两个主要影响：

  • 你可以多次提交你想要的内容。 这些提交不会立即被其他人看到（例如，“他们在下一次更新工作空间后不需要立即合并）”
    〜出版过程是被动的：你的推动可以被其他回购忽略。
    〜“消费”部分是一个活跃的部分：您可以在将其合并到您的分支之前检查推送给您的内容，并决定要合并的内容以及来自哪个人（而不仅仅是因为您都在“科”）。
  • 它适用于任何合并工作流程（部分，纵横交错，递归......）通常用于记录那些DVCS（至少Git和Mercurial）的历史记录的DAG（直接非循环图 ）可以很容易地找到已经合并并找到共同的祖先。 这是SVN与DVCS同行之间的一个重要区别，但也有其他一些。

    • 现在：

    实现一个功能

    正如我在CVCS（中央VCS）答案中详细说明的，“特征”分支背后的难点在于许多子特征将最终交织在一起。
    这是DVCS将发光的地方，因为它们允许您重新组织它们的本地（如“尚未推送”）历史（Mercurial的变更集，SHA1提交或Git），以促进部分合并或子功能分支创建。

    修复错误

    如果你愿意的话，你几乎可以为每个bug修复创建一个分支。 这个想法是确保一个错误修复是通过在开发分支中合并回来的一个简单的线性集合来识别的（或者如果这个被释放的话，维护分支）。
    我更喜欢确保首先在开发分支之上重新设置bug修复分支（以确保我的修复仍然符合可能在所述主分支上并行完成的任何工作），然后将该分支合并到错误修复一个（快进合并：主分支现在引用所有修复）

    代码审查

    责备或注释功能仍然有助于在代码审查期间分配任务，但是这次，所有开发人员不一定在一个站点上（因为它是* Distributed * VCS），并且不具有相同的识别方案（例如不使用相同的LDAP）。

    DVCS组织代码审查的方式是将新更改推送到特殊的代码审查仓库，该仓库将：

  • 如果他们不符合所要求的质量标准，则拒绝这些提交
  • 接受这些（将它们与代码评论回购合并），并将它们推送到一个新的回购（例如用于各种测试）

    • 重构代码（发布代码审查）

    他们是在开发人员的本地回购，在一个分支上完成的（因为它很容易合并回来）

    加入补丁

    与上一节相同的过程。

    发布你的应用的新版本（桌面，网页，手机，你会不同地对待他们？）

    实际的发布过程只需通过特定的标签（标签）版本的软件即可启动。 （“发布管理流程”的其余部分，即部署和配置部分在CVCS答案中有详细说明）
    问题是，用DVCS：
    “你的软件的官方版本从哪个版本库中出来？”

    您需要建立一个“中央”或“官方”存储库，它将扮演以下角色：

  • 要发布的版本的回购
  • 新存储库的回购想贡献

    • 所以它既可以用于发布目的，也可以用于新的开发目的。

    链接地址: http://www.djcxy.com/p/49267.html

    上一篇: Describe your workflow of using version control (VCS or DVCS)

    下一篇: Git for solo developer: merge vs rebase