问题描述
在使用Docker镜像仓库和源代码管理服务（如Bitbucket）时，希望了解最佳实践，以确保这两者之间能够尽可能紧密地耦合。用户担心如果开发人员没有充分的尽职调查，镜像仓库中的最新Docker镜像可能不会反映源代码管理中Dockerfile的当前状态，反之亦然。此外，用户强调对于镜像仓库中的任何镜像，能够追溯回基本Dockerfile（自己创建的）是至关重要的。
解决方案
请注意以下操作可能涉及不同工具及版本，具体操作前务必做好备份。
使用GitLab的内置Docker镜像仓库
对于希望实现Docker和源代码管理（SCM）的美观集成，GitLab提供了内置的Docker镜像仓库。这使得在构建流水线中发布Docker镜像变得非常简单。
GitLab Docker镜像仓库的另一个重要优势是，它支持为每个GitLab仓库创建多个Docker仓库。这允许您为每个分支、每个提交、每个环境或其他任何需要的情况创建新的Docker仓库。
例如，如果您有多个为特定分支构建的Docker镜像（例如前端Angular应用及其所依赖的后端API），您可以进一步限定范围，例如：
project-name/branch-name/api:commit-SHA
project-name/branch-name/front-end:commit-SHA
您可以根据需要使用任意数量的斜杠（/）来进行范围限定。这使得在部署时可以很容易地确定使用的确切提交的镜像。出于这个原因，我们公司几乎从不使用通用的“latest”标签，而是更喜欢指定在哪里部署了哪个镜像。
使用自动化构建系统
在Dockerfile中使用LABEL来记录构建的源。这可能包括分布式源代码控制（如Git、Mercurial）的提交哈希、分支名称（如果适用）、任何发布标签（如果存在）以及可能的其他详细信息，如上次提交的时间戳。docker history和docker inspect命令可以显示这些信息。
当您使用docker push推送镜像时，至少推送两次，一次使用提交哈希，一次使用分支名称作为“版本”部分（例如：quay.io/mycorp/imagename:123abc7，quay.io/mycorp/imagename:dmaze-test）。如果可用，持续集成系统应该使用这些标签来推送镜像。
确保Dockerfile已提交到源代码控制，同时尽量确保能够稳定地获取任何可能存在的外部依赖项。
现在，您可以双向操作：对于任意提交，如果您的持续集成系统对其进行了构建，您可以运行构建的镜像；如果您有一个镜像，您可以找到它在源代码历史中的确切位置，并切换到该特定版本，然后自行构建一个几乎相同的副本。
回答2的评论
评论：
1. 推送多次Docker会有什么不同吗？
2. 您的问题不太确定，但Docker镜像仓库会跟踪镜像的哈希值，因此如果您多次推送Docker镜像（使用不同的标签），您将会得到多个具有标签的“镜像名称”，但它们都指向相同的哈希值。因此，除了用于存储新镜像名称的空间外，不会占用额外的空间。