代码提交

尽管越来越多的开发者转向使用 Git 的图形界面客户端，但依然有大量开发者热衷于使用命令行，其主要优势在于，不论是在个人电脑上，还是在字符界面的服务器上，使用体验都是一致的。

学习 Git 的第一课通常都会从常用的 Git 命令开始。虽然 Git 的命令众多，但在日常使用中频率最高的大约只有五个，例如 git branch、git add、git commit、git pull和git push。而掌握更高级的命令，可以使代码库更为简洁规范，后续的维护也会更为方便。对于熟练的用户来说，命令行可以更快地完成操作，无需通过其他界面或工具。

图片

然而，命令行的缺点也非常明显。对于新手来说，学习成本相对较高，除了需要记忆大量的命令和参数，对操作流程的理解也并非易事，比如 add 和 commit 之间的配合使用就是新手常问的问题之一。再加上命令行无法提供直观的可视化表示，新手往往难以理解代码库的结构和历史。

图片

相反，图形界面客户端很好地解决了上述问题。新手，特别是中国的程序员，无需再面对难以理解的英文命令，操作过程非常直观。可视化的表示可以帮助用户更好地理解项目结构和历史。当代码冲突时，用户可以用更直观的方式来解决合并冲突。此外，由于图形界面客户端是独立的，因此可以集成到开发工具中，如缺陷跟踪和代码评审。

图片

当然，图形界面客户端并非完美无暇，许多 Git 命令行的高级操作可能无法覆盖。而且在处理大型仓库时，图形界面客户端可能会比命令行更耗资源，速度也可能慢一些。然而，微服务架构的兴起，客观上大大降低了大型仓库的可能性。

除了以上两种交互方式，还有一种更为明确的场景化方式。一些开发者希望在一个集成环境中完成所有工作，IDE 便成为了理想的选择。然而，由于集成的功能可能有限，且并非所有的 IDE 都支持 Git 集成，因此，这类用户的比例相对较低。

图片

实际上，开发者可能会根据自己的需求和习惯，在三种方式中进行切换。

对于图形界面客户端的使用者，Bitbucket 提供了与 SourceTree 的紧密集成。SourceTree 是 Atlassian 公司推出的一款免费的 Git 和 Mercurial 客户端。它提供了非常直观的代码库浏览和操作界面，以及与 Bitbucket 的无缝集成，使得用户可以在 SourceTree 中直接进行代码的克隆、提交和合并请求等操作。

图片

代码合并请求

在多人参与的项目中，代码合并请求是一种重要的协作机制，它允许开发者将他们的更改提交到主分支或其它特定分支中。对于代码合并请求，有两种说法，在 GitHub 和 Bitbucket 中，它被称为 Pull Request (PR)，而在 GitLab 中，它被称为 Merge Request (MR)。

图片

请求代码合并时，必然会促进团队的协作和沟通，在一次提交中，开发者们可以提出问题、讨论解决方案并共同改进代码。由于代码合并前会进行代码审查，虽然该行为并不能完全排除代码缺陷，但成员之间的相互审查，还是有助于发现潜在的问题以及不合适的设计决策，对提高代码质量有着重要意义。

图片

这种方式可以有效的保持主分支的稳定，并且有利于自动化集成和部署的设计。

但由于代码评审并没有统一标准可言，这使得制定怎样的通过标准成为这一环节的难点。Bitbucket 在这流程方面做了一些努力。

合并检查与评审策略

虽然我们无法标准化必须检查的内容，但可以定义一些评审规则，在 Bitbucket 中，内置了 5 条规则可以根据实际需求来选择是否开启：

  • All reviewers approve

    • 开启/关闭需要经过所有评审人都判定通过

  • Minimum approvals

    • 定义参与评审的最少人数

  • Minimum successful builds

    • 定义执行成功的流水线的最少条数

  • No ‘needs work’ status

    • 开启/关闭如果合并请求处于 ‘needs work’ 状态将不允许合并

  • No incomplete tasks

  • 开启/关闭需要所有的任务都完成才允许合并

图片

如果开启其中的一个或多个规则，那么只有满足了规则之后，才会允许进行代码合并操作。

默认规则已经覆盖常规需求场景，如果还有需要的检查条件，比如要求必须静态代码扫描结果为通过，可以尝试从插件市场找一找。

图片

评审判定结果

在多元化的代码评审场景中，我们可能需要在不同分支的代码评审中设置各自的默认评审员，同时，对于最低评审员人数的需求也可能不同。这时，我们可以在项目或代码库的设置中指定一些默认评审员规则，使得代码评审过程更加灵活和智能化。

图片

对于未达标的合并请求，除了人工驳回之外，我们还可以选择放任不管。Bitbucket 提供了一项设置，允许在超时后自动驳回合并请求，从而清理那些在流程上阻塞或者已失效的合并请求。虽然这可能不是对流程遵从性的最佳实践，但如果你曾经处理过大型团队的评审请求，你就会明白这个功能对于评审双方来说，实际上是非常友好的。

图片

其他

Bitbucket 中充满了许多用户友好的特性，对于大多数用户来说，他们可能需要花一些时间去探索和熟悉。

例如，许多程序员对编写文档感到厌倦，即便是在提交代码评审时的描述也会让他们感到困扰。Bitbucket 为此提供了一项特性，允许用户使用提交历史记录作为默认描述，同时也可以群策群力，共同定制描述模板，既美观又简洁，同时又实用。

图片

对于包含子模块或多个流水线的代码库，Bitbucket 可以设置相关联的所有流水线都成功，或者需要子模块流水线成功作为评审条件，可以关联一个或多个流水线。

图片

此外，当提交代码评审申请时，可能需要一些默认的检查清单，Bitbucket 允许用户配置默认任务列表。

图片

这些只是众多特性中的一部分，我们不可能一一列举。在后续的章节中，我们将结合具体的使用场景和案例，深入探讨这些特性。

分支权限

在涉及大量协作成员，尤其是新旧成员交替，业务熟悉度不同，技术能力层次不齐的场景中，分支推送错误并不罕见。Bitbucket 并没有像 GitHub 那样采用”分支保护”的说法，而是在安全设置中，将其称为”分支权限”。

图片

用户可以在此添加自定义的分支权限配置，这不仅可以针对某个特定的分支，还可以通过正则表达式匹配多个分支。如果你采用的是分支类型的管理方式，那么这里也可以按照分支类型进行配置。总共有四种限制条件：

  • 防止任何修改
  • 防止删除
  • 防止重写历史记录
  • 防止不通过代码合并请求直接修改

这些限制条件支持组合单搭配，并提供白名单功能。通过这种方式，用户可以自由组合各种分支的权限设置。例如，针对用于稳定发布的分支，我们通常会防止随意修改，只允许通过合并请求提交，那么可以设置”防止不通过代码合并请求直接修改”。如果需要保留一个”上帝视角”用户，允许他强行提交，那么就可以将某个账号加入白名单。

版本发布

Git 的原生功能中包含了一个适合进行版本标记的标签功能。然而，标签本身并不区分自身所在的分支，因此，如果仅仅使用 Git 命令进行标记，将难以为应用版本提供可视化的追溯。GitHub 则对此做了增强，在其 Web 界面上操作，虽然也是 Git 标签的功能，但扩展出了可视化的操作日志和发布管理的页面，极大地辅助了软件发布流程。

图片

然而，我的客户通常会对在哪个分支上打标签感到困惑。他们会疑惑是应该在合并到主分支后打标签发布，还是在发布分支上打完标签再合并到主分支。

这主要取决于团队的工作流程和发布策略。如果团队和项目较小，并且希望保持流程简单，那么可以在合并到主分支后再打标签。而如果发布流程较长，团队规模较大，项目复杂度较高，那么在发布分支上打标签可能更为稳妥。这样可以在发布分支上进行额外的测试和修复，而不会影响主分支的稳定性。

然而，有趣的是，Bitbucket并没有提供一个专门的发布功能，也没有简化打标签的过程。

在Bitbucket中，用户需要通过左侧菜单栏的”提交”选项进入提交记录，点击提交的哈希值，进入详情页面，才能通过按钮创建标签。

图片

相较而言，使用图形界面客户端SourceTree进行操作可能更为便捷。

图片