代码提交

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

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

图片

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

图片

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

图片

当然,图形界面客户端并非完美无暇,许多 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进行操作可能更为便捷。

图片