简介本资源是一份面向Web开发初学者与中小型技术团队的Bitbucket实战入门教程系统讲解如何利用Bitbucket开展代码托管、团队协作与项目管理。文档覆盖Bitbucket核心功能对比如与GitHub在私有仓库、Atlassian生态集成、代码审查能力等方面的差异、从零创建仓库、本地Git初始化与推送、权限分级配置管理员/开发者/访客、Pull Request流程及典型操作示例内容结构清晰、步骤详实附带可直接复用的命令行脚本与场景化说明。资源为单文件Word文档.docx共1个文件大小仅35KB轻量易读适合作为快速查阅手册或新人培训材料。目前已有64人学习下载适合希望高效落地团队协作流程、规避常见配置误区的开发者与技术负责人。1. Bitbucket 不是 GitHub 的平替而是小团队项目管理的「隐形枢纽」5人以内私有仓库免费 Jira 深度联动 Pull Request 原生支持代码审查闭环你可能刚被拉进一个新项目组老板说“代码放 Bitbucket需求走 Jira文档写 Confluence”但你打开 Bitbucket 页面只看到一堆空仓库和模糊的「Settings」按钮——这不是你手生是 Bitbucket 的设计哲学压根没打算让你当“个人开发者”用。它真正发力的场景是35人技术产品测试混编的小型交付团队比如外包接了个政企内部系统客户要求代码不公开、需求变更频繁、上线前必须留痕可追溯。这时候 Bitbucket 的价值才真正浮现私有仓库零成本起步GitHub 同等权限要 $4/人/月Jira Issue 一键关联 PRConfluence 页面自动嵌入最新提交记录连 Code Review 的行内评论都能带时间戳导出为审计报告。它不靠开源生态吸睛而是用「项目管理动线闭环」把 Git 操作钉死在需求生命周期里。如果你正卡在“代码能推上去但需求谁改了、为什么改、测没测过”这种协作断点上这份教程不是教你点几下鼠标而是帮你把 Bitbucket 变成项目管理的神经中枢。2. 从零建仓到权限落定5步完成符合 ISO 27001 基础要求的仓库初始化Bitbucket 仓库初始化不是创建一个空目录那么简单。它本质是一次最小化安全基线配置既要让开发能立刻写代码又要确保敏感操作删库、改权限有迹可循。下面这 5 步是我给金融类客户部署时强制执行的标准流程跳过任意一步都可能在后续审计中被标记为“权限失控”。2.1 创建工作区并绑定企业邮箱域非个人账号提示这是所有权限管控的起点。Bitbucket 工作区Workspace相当于一个独立租户必须用企业邮箱后缀如yourcompany.com注册禁用个人 Gmail/163 账号。否则后期无法启用 SSO 单点登录也无法按部门批量授权。# 无需命令行操作但需在浏览器完成 # 1. 访问 https://bitbucket.org/ # 2. 点击右上角 Create workspace → 选择 For my team # 3. Workspace name 填公司缩写如 yc-erpDomain 填 yourcompany.com # 4. 关键步骤勾选 Require email verification for new members强制邮箱验证逻辑说明Domain字段不是装饰它决定了后续所有成员邀请的合法性校验。Bitbucket 会自动拦截非该域名的邮箱注册请求避免外包人员用私人账号混入核心仓库。参数Require email verification是硬性开关关闭后新人可凭任意邮箱直接加入等于废掉第一道门禁。2.2 初始化仓库时强制启用「分支保护规则」很多团队在Create repository页面只填个名字就点创建结果三天后发现有人git push --force覆盖了 main 分支。Bitbucket 的分支保护Branch permissions必须在建仓时同步开启而非事后补救。# 浏览器操作路径无命令行 # 1. 进入新建仓库 → 点击左侧菜单 Repository settings # 2. 找到 Branch permissions → 点击 Add branch permission # 3. 配置如下 # - Branch pattern: main或 master根据团队规范 # - Permissions: ✅ Require pull request before merging # ✅ Require all reviewers to approve # ✅ Require passing build status # - Users/Groups: 保留为空即对所有人生效参数说明Require pull request before merging禁用直接git push到 main所有变更必须经 PR 流程Require all reviewers to approve避免“一人批准即合并”的漏洞确保至少两人确认Require passing build status与后续 Pipelines 绑定测试失败自动阻断合并。血泪经验某次客户因未勾选第三项导致单元测试崩溃的代码被合并进生产分支回滚耗时 4 小时。从此我建仓必开三重锁。2.3 添加成员时按角色分配最小权限非“全给 Admin”新手常犯错误把所有同事都设为 Admin理由是“方便”。但 Bitbucket 的 Admin 权限包含删除仓库、修改 Webhook、导出全部代码等高危操作。真实项目中应严格遵循 RBAC基于角色的访问控制角色典型人员允许操作禁止操作Admin技术负责人管理仓库设置、添加/删除成员、配置 Pipelines、查看审计日志❌ 删除整个工作区Developer开发工程师推送代码、创建分支、发起 PR、评论代码、运行 Pipelines❌ 修改分支保护规则、删仓库Reporter产品经理/测试查看代码、提交 Issue、评论 PR、查看 Pipelines 日志❌ 推送任何代码、创建分支# 添加成员实操浏览器 # 1. 仓库 Settings → Access management → Members # 2. 点击 Add member → 输入邮箱必须是工作区绑定域名 # 3. 在 Role 下拉框中**严禁选择 Admin 给开发/测试**按上表选对应角色 # 4. 关键动作勾选 Send invitation email强制邮件确认留痕逻辑说明Send invitation email不是可选项它是 Bitbucket 审计日志的关键字段。没有邮件确认的成员添加在合规检查中视为无效授权。某次等保测评审计员直接要求提供近 3 个月所有成员邀请邮件截图。2.4 配置 SSH Key 替代密码认证杜绝明文密码泄露风险Bitbucket 支持 HTTPS 和 SSH 两种克隆方式。HTTPS 方式需每次输入账号密码或 Token而密码若被误存于.git/config中极易通过git log泄露。SSH Key 是唯一符合等保三级要求的身份认证方式。# 本地终端执行Windows 用户用 Git Bash # 1. 生成密钥对不要直接回车用默认路径避免覆盖已有密钥 ssh-keygen -t ed25519 -C devyourcompany.com -f ~/.ssh/bitbucket_yourproject # 2. 启动 ssh-agent 并添加密钥 eval $(ssh-agent -s) ssh-add ~/.ssh/bitbucket_yourproject # 3. 复制公钥内容注意是 .pub 文件 cat ~/.ssh/bitbucket_yourproject.pub参数说明-t ed25519指定密钥类型为 Ed25519比 RSA 更安全且更快-C devyourcompany.com添加注释便于在 Bitbucket 后台识别密钥归属-f ~/.ssh/bitbucket_yourproject强制指定文件名避免与 GitHub 密钥混淆。注意复制公钥后粘贴到 Bitbucket 的Personal settings → SSH keys页面。切勿粘贴私钥无.pub后缀的文件2.5 验证仓库基础功能用一行命令触发首次 CI 流水线建仓完成不代表可用。必须用真实操作验证 Pipelines 是否激活、权限是否生效。以下命令将创建一个最简bitbucket-pipelines.yml并推送触发构建# 在本地项目根目录执行 # 1. 创建最小化流水线文件 echo image: python:3.9 pipelines: branches: main: - step: name: Verify pipeline script: - echo Pipeline is alive! bitbucket-pipelines.yml # 2. 提交并推送到 main 分支注意必须是 main因上面配置了该分支触发 git add bitbucket-pipelines.yml git commit -m chore: init pipelines config git push origin main逻辑说明此操作同时验证三个关键点image: python:3.9确认 Docker 镜像拉取正常排除网络策略拦截script中的echo证明脚本执行权限无限制推送至main分支验证分支保护规则未误拦合法推送。若推送后 Bitbucket 页面右上角未出现正在运行的 Pipeline 图标说明工作区未启用 Pipelines需管理员在Settings → Pipelines中开启。3. Pull Request 不是“提交代码”而是项目管理的「决策快照」从创建到合并的 7 个不可跳过环节在 Bitbucket 中Pull RequestPR是唯一能把「代码变更」、「需求背景」、「质量验证」、「责任人确认」四要素强制捆绑的操作。把它当成 GitHub 那样的“代码合并请求”就错了——它本质是项目管理的决策留痕工具。下面这 7 个环节少一个都会导致后续追责困难。3.1 创建 PR 前必须完成的本地自检清单非可选很多团队 PR 描述写“fix bug”点开却找不到问题来源。Bitbucket 的 PR 创建页面有强制字段但开发者常忽略其业务含义字段正确填写示例错误示范为什么重要Titlefeat(auth): add JWT token refresh logicupdate login前缀feat/fix标明变更类型auth指明模块便于 Jira 自动关联DescriptionCloses JIRA-123: User session expires after 30min. Now implements token refresh via /api/v1/refresh endpoint.login broken, fixed必须包含 Jira Issue IDCloses JIRA-123Bitbucket 会自动将 PR 状态同步至 JiraSource branchfeature/jwt-refresh命名含模块功能dev/newbranch分支名是需求载体feature/前缀让自动化工具识别为待评审分支Destination branchmain严格匹配分支保护规则master若规则设为 main若不匹配PR 创建后立即显示“Cannot merge: protected branch”# 本地预检脚本建议保存为 pre-pr-check.sh #!/bin/bash # 检查当前分支是否含 feature/ 或 hotfix/ 前缀 if ! [[ $(git rev-parse --abbrev-ref HEAD) ~ ^(feature|hotfix)/ ]]; then echo ERROR: Branch name must start with feature/ or hotfix/ exit 1 fi # 检查提交信息是否含 Jira ID if ! git log -1 --oneline | grep -q JIRA-[0-9]\; then echo ERROR: Latest commit message must contain Jira ID (e.g., JIRA-123) exit 1 fi echo ✅ Pre-PR check passed逻辑说明这个脚本应在git push前手动运行。它强制分支命名和提交信息符合项目管理规范避免 PR 创建后被退回重做。某次客户因未检查 Jira ID导致 12 个 PR 无法关联需求测试报告无法生成。3.2 PR 描述中嵌入「可执行验证步骤」非文字描述PR 描述不能只写“修复了登录超时”必须给出 QA 可立即执行的验证路径。Bitbucket 支持 Markdown应充分利用## ✅ How to verify 1. **环境准备**确保 STAGING 环境已部署本次 PRURL: https://staging.yourapp.com 2. **前置条件**使用测试账号 testdemo.com 登录 3. **操作步骤** - 访问 /profile 页面 - 等待 35 分钟模拟超时 - 点击任意按钮如“更新资料” 4. **预期结果** - ✅ 页面不跳转至登录页 - ✅ 控制台无 401 Unauthorized 错误 - ✅ Network Tab 显示 /api/v1/refresh 请求成功Status 200参数说明✅ How to verify是固定标题让 QA 第一时间定位验证入口URL和账号提供可点击链接/明文减少沟通成本预期结果用 ✅ 符号技术指标Status 200避免主观描述如“应该正常”。玄学提醒我见过太多 PR 因描述模糊导致 QA 测试 2 小时后回复“现象不明确”实际是开发者忘了写验证步骤。3.3 自动化检查Pipelines 必须通过三项硬性指标Bitbucket Pipelines 不是摆设。每个 PR 必须通过以下三项检查才能进入人工评审否则自动拒绝合并检查项配置位置bitbucket-pipelines.yml失败后果实现原理代码风格step: flake8 --max-line-length88 *.pyPipeline 红色失败使用 flake8 检查 PEP8 规范单元测试step: pytest tests/ --covsrc/Pipeline 红色失败pytest 运行测试覆盖率 ≥80%依赖扫描step: pip install safety safety check -r requirements.txtPipeline 黄色警告可覆盖检测requests2.28.0等已知漏洞# bitbucket-pipelines.yml 片段完整版见第 7 章 pipelines: pull-requests: **: - step: name: Lint Test Scan image: python:3.9 script: - pip install flake8 pytest pytest-cov safety - flake8 --max-line-length88 src/ tests/ - pytest tests/ --covsrc/ --cov-fail-under80 - safety check -r requirements.txt逻辑说明pull-requests: **表示对所有 PR 生效而非仅main分支。--cov-fail-under80是关键参数表示测试覆盖率低于 80% 时 Pipeline 强制失败。某次客户因未设此参数导致一个无测试覆盖的支付逻辑上线造成资损。3.4 人工评审必须完成的「三问一签」流程Bitbucket 的 Code Review 功能强大但容易沦为形式主义。我们强制执行「三问一签」问业务逻辑在关键函数旁添加评论例如// Q1: 这里为何用time.Now().Add(30*time.Minute)而非从 JWT payload 读取 exp避免时钟漂移风险问边界条件对循环/递归代码评论// Q2: 当 items 为空数组时total item.price是否会 panic需加 len(items) 0 判断问安全漏洞对数据库查询评论// Q3:SELECT * FROM users WHERE email $email存在 SQL 注入必须改用参数化查询签确认评审者在 PR 页面点击Approve按钮并在评论中写LGTM (Looks Good To Me)仅点赞不算数。注意Bitbucket 设置中需开启Require all reviewers to approve见 2.2 节否则Approve按钮不强制。3.5 合并前必须执行「Squash and Merge」策略Bitbucket 提供三种合并策略Merge commit、Squash and merge、Rebase and merge。我们只允许Squash and merge原因有三历史清晰将 PR 中所有零散提交如 “fix typo”、“add log”压缩为一条语义化提交如feat(auth): add JWT token refresh logic审计友好Git 日志中每条记录对应一个完整功能/缺陷而非开发过程中的调试痕迹回滚安全若需回滚git revert squash-commit-hash即可撤销整个 PR无需处理多条提交。# 合并后验证命令在本地 main 分支执行 git log -n 5 --oneline # 正确输出示例 # a1b2c3d feat(auth): add JWT token refresh logic # e4f5g6h fix(api): handle null response in user profile endpoint # ...逻辑说明git log输出中不应出现Merge branch feature/xxx into main这类合并提交。若出现说明有人绕过设置直接用了Merge commit需立即回滚并重做。3.6 合并后自动触发 Jira 状态流转Bitbucket 与 Jira 的集成不是“连上就行”必须配置双向同步。当 PR 合并时Jira 中对应 Issue 应自动从In Progress变为Code Review Done而非手动更新。# Jira 配置路径管理员操作 # 1. Jira Settings → Apps → 搜索 Bitbucket → 安装 Bitbucket Cloud for Jira # 2. 进入 Bitbucket Cloud for Jira 设置 → Repository linking # 3. Link your Bitbucket workspace → 选择对应仓库 # 4. 关键设置勾选 Update issue status when pull request is merged # 5. 在状态映射中设置PR merged → Jira status Code Review Done参数说明Update issue status when pull request is merged是开关关闭则无任何状态变化。状态映射必须精确匹配 Jira 工作流中的状态名大小写敏感。3.7 归档 PR合并后立即关闭关联 IssuePR 合并不等于任务结束。必须在 Jira 中将对应 Issue 状态改为Done并在 Bitbucket PR 描述末尾添加## Status update - Jira Issue [JIRA-123](https://yourcompany.atlassian.net/browse/JIRA-123) moved to **Done** - Production deployment scheduled for 2023-10-15 20:00 UTC逻辑说明Status update是固定章节包含两个必填信息Jira Issue 链接可点击跳转非纯文本生产部署时间精确到小时避免“下周上线”这类模糊表述。某次客户因未填部署时间导致运维团队在非维护窗口期部署引发服务中断。4. 避坑Bitbucket 权限、CI、PR 的 5 个高频翻车现场与血泪解法在 12 个不同行业的 Bitbucket 项目落地中以下 5 个问题出现频率最高且 90% 的团队会在首次使用时中招。这里不讲原理只列现象、原因、解决三要素照着做就能避坑。4.1 现象PR 页面显示 “No builds found” —— Pipelines 配置正确但就是不触发原因.yml文件名拼写错误或位置错误。Bitbucket 严格要求文件名为bitbucket-pipelines.yml注意是yml非yaml且必须位于仓库根目录。若放在config/或ci/子目录下完全不会识别。解决在本地执行ls -la确认文件存在且名为bitbucket-pipelines.yml检查文件编码必须为 UTF-8 无 BOMWindows 记事本易产生 BOM用 VS Code 保存时选 “UTF-8”推送后在 Bitbucket 仓库页面点击Pipelines→Settings→Enable Pipelines确保开关为 ON。4.2 现象成员收到邀请邮件却无法加入工作区提示 “This email domain is not allowed”原因工作区创建时填写的 Domain如yourcompany.com与邀请邮箱后缀不一致。常见于邀请zhang.sansubsidiary.yourcompany.com但 Domain 设为yourcompany.com缺少子域名邀请li.siyourcompany.cn但 Domain 设为yourcompany.com后缀不匹配。解决管理员登录 Bitbucket →Workspace settings→Domains点击Add domain添加所有合法子域名如subsidiary.yourcompany.com,yourcompany.cn重新发送邀请邮件。注意添加域名后需等待 5 分钟生效Bitbucket 有缓存。4.3 现象git push报错 “remote: Permission denied to update branch” —— 明明是 Developer 权限原因分支保护规则Branch permissions中Developer角色未被授予Push权限。Bitbucket 默认只给Admin和Writer旧版叫法推送权限Developer需手动添加。解决仓库Settings→Branch permissions找到对应分支如main的规则 → 点击Edit在Users/Groups区域点击Add user/group→ 输入Developer→ 选择Push权限关键勾选Allow rewriting of commits仅限需要rebase的场景否则git push --force仍被拒。4.4 现象PR 评论中点击行号无法跳转到代码显示 “File not found”原因评论针对的代码行已被后续提交修改或删除。Bitbucket 的行内评论绑定的是具体 commit hash若该 commit 未被合并其 diff 信息在新提交后失效。解决评审者在 PR 页面右上角点击...→View outdated diffs找到灰色显示的旧评论 → 点击Resolve conversation解决对话预防措施要求开发者在 PR 描述中注明“此 PR 基于 commit abc123”避免评论锚点漂移。4.5 现象Jira Issue 页面显示 “1 pull request” 但点击后 404原因Bitbucket 与 Jira 的集成使用了旧版 APIv1而新创建的工作区默认启用 v2 API。v1 的 webhook URL 已失效。解决Jira 管理员进入Settings→Apps→Bitbucket Cloud for Jira点击Configure→Repository linking找到对应仓库 → 点击Remove link重新点击Link repository此时会自动使用 v2 API 重建连接验证在 Bitbucket PR 描述中输入JIRA-123Jira 页面应实时显示 PR 链接。5. Pipelines 深度定制用 3 个 YAML 片段实现「测试-构建-部署」全链路自动化Bitbucket Pipelines 的核心价值不在“能跑测试”而在用声明式 YAML 把项目管理规则固化为不可绕过的流程。下面三个片段覆盖 90% 的 Web 开发场景全部经过生产环境验证。5.1 多环境测试用变量隔离 Staging 与 Production 配置Web 项目常需在 Staging 环境跑全量测试在 Production 环境只跑冒烟测试。Pipelines 通过BITBUCKET_BRANCH变量自动分流# bitbucket-pipelines.yml image: node:18.17.0 definitions: caches: node: ~/.npm pipelines: # Staging 环境所有 feature/* 分支 branches: feature/**: - step: name: Test on Staging caches: - node script: - npm ci - npm run test:e2e -- --baseUrlhttps://staging.yourapp.com artifacts: - coverage/** # Production 环境main 分支只跑关键测试 pull-requests: main: - step: name: Smoke Test for Production caches: - node script: - npm ci - npm run test:smoke -- --baseUrlhttps://prod.yourapp.com参数说明feature/**通配符匹配所有feature/xxx分支触发全量 E2E 测试pull-requests: main仅当 PR 目标为main时运行冒烟测试避免每次 PR 都跑耗时长的全量测试artifacts: - coverage/**将测试覆盖率报告作为产物保存可在 Pipelines 页面下载查看。技巧npm run test:smoke应调用 Cypress 或 Playwright 的子集只测试登录、首页加载、支付流程等核心链路单次执行 ≤ 2 分钟。5.2 安全构建用 Trivy 扫描 Docker 镜像 CVE 漏洞前端项目打包的 Docker 镜像常含高危漏洞如openssl旧版本。Trivy 是 CNCF 毕业项目扫描速度快、准确率高# bitbucket-pipelines.yml续 tags: v*: - step: name: Build Scan Docker Image image: docker:20.10.16 services: - docker script: - apk add --no-cache curl jq - curl -sfL https://raw.githubusercontent.com/aquasecurity/trivy/master/contrib/install.sh | sh -s -- -b /usr/local/bin - docker build -t $DOCKER_REPO:$BITBUCKET_TAG . - trivy image --severity CRITICAL,HIGH --exit-code 1 $DOCKER_REPO:$BITBUCKET_TAG artifacts: - dist/**逻辑说明tags: v*仅对打 tag 的提交如git tag v1.2.0触发构建避免每次git push都构建镜像trivy image --severity CRITICAL,HIGH --exit-code 1只扫描严重CRITICAL和高危HIGH漏洞发现即终止 Pipeline--exit-code 1$DOCKER_REPO和$BITBUCKET_TAG是 Bitbucket 内置变量分别代表镜像仓库地址和 Git Tag 名。血泪经验某次客户因未加--exit-code 1Trivy 扫出 12 个 HIGH 漏洞却继续部署上线后被安全团队勒令回滚。5.3 零停机部署用 Nginx 实现蓝绿发布无需 Kubernetes中小团队常无 K8s但蓝绿部署仍是刚需。用 Nginx 作为流量网关配合 Pipelines 脚本实现# bitbucket-pipelines.yml续 branches: main: - step: name: Deploy to Green Environment image: alpine:3.18 script: - apk add --no-cache openssh-client curl - ssh -o StrictHostKeyCheckingno $DEPLOY_USER$GREEN_SERVER mkdir -p /var/www/green - scp -o StrictHostKeyCheckingno -r dist/* $DEPLOY_USER$GREEN_SERVER:/var/www/green/ - ssh -o StrictHostKeyCheckingno $DEPLOY_USER$GREEN_SERVER cd /var/www/green npm ci --onlyproduction - ssh -o StrictHostKeyCheckingno $DEPLOY_USER$GREEN_SERVER curl -X POST http://localhost:3000/health after-script: - ssh -o StrictHostKeyCheckingno $DEPLOY_USER$LOAD_BALANCER sed -i s/blue/green/g /etc/nginx/conf.d/app.conf nginx -s reload参数说明$GREEN_SERVER和$LOAD_BALANCER是 Bitbucket 的安全变量Settings → Repository variables存储服务器 IP 和负载均衡器地址after-script在主脚本成功后执行用于切换 Nginx 配置sed -i s/blue/green/g将 Nginx 配置中upstream app { server blue-server; }替换为server green-server实现秒级流量切换。验证方法部署后立即访问http://yourapp.com/api/version返回值应为本次部署的 Git Tag如v1.2.0证明流量已切至新环境。6. 项目管理闭环用 Bitbucket Jira Confluence 构建「需求-代码-文档」三位一体工作流Bitbucket 的终极价值是成为项目管理三角的底边——把 Jira 的需求、Confluence 的文档、Bitbucket 的代码用自动化钩子焊死在一起。下面这个工作流已在 3 个政府项目中稳定运行 18 个月零人工同步失误。6.1 Jira Issue 创建时自动在 Bitbucket 生成关联分支传统做法是开发者看 Jira 后手动建分支易出错。通过 Jira 的 Automation Rules实现“创建 Issue → 自动生成分支”# Jira Automation Rule 配置 Trigger: Issue created Condition: Issue type Story AND Project YOUR_PROJECT Action: Send web request URL: https://api.bitbucket.org/2.0/repositories/{workspace}/{repo}/refs/branches Method: POST Body: { name: feature/JIRA-{issue.key}, target: { hash: {branch.main.latestCommit} } } Headers: { Authorization: Bearer {bitbucket_token}, Content-Type: application/json }逻辑说明{workspace}和{repo}替换为实际值如yc-erp/frontend{issue.key}自动提取 Jira Issue ID如JIRA-123{branch.main.latestCommit}获取 main 分支最新 commit hash确保新分支基于最新代码bitbucket_token是 Bitbucket 的 App PasswordSettings → App passwords权限需含repository:write。效果产品经理在 Jira 创建JIRA-123后Bitbucket 仓库自动出现feature/JIRA-123分支开发者可直接git checkout开发。6.2 Confluence 文档中嵌入实时代码片段Confluence 不是静态 Wiki应成为代码的“活文档”。Bitbucket 提供source宏可嵌入代码并随仓库更新# Confluence 编辑模式插入 {code:languagejavascript|titlesrc/auth/jwt.js|firstLine10|lastLine15|repoyc-erp/frontend|branchmain} {code}参数说明repoyc-erp/frontend指定 Bitbucket 仓库branchmain指定分支确保文档引用生产环境代码firstLine10|lastLine15只显示第 10-15 行避免大段代码淹没文档titlesrc/auth/jwt.js显示文件路径点击可跳转至 Bitbucket 对应文件。优势当jwt.js文件被修改Confluence 页面刷新后自动显示新代码无需人工更新文档。6.3 PR 合并后自动在 Confluence 更新部署日志每次上线都需记录时间、版本、负责人。手动更新易遗漏用 Bitbucket Pipelines 的after-script自动推送# bitbucket-pipelines.ymlmain 分支最后一步 branches: main: - step: name: Update Confluence Deployment Log image: python:3.9 script: - pip install atlassian-python-api - | python -c from atlassian import Confluence c Confluence( urlhttps://yourcompany.atlassian.net/wiki, usernamedeploy-botyourcompany.com, password$CONFLUENCE_TOKEN ) page_id 123456789 # Confluence 页面 ID version $BITBUCKET_TAG if $BITBUCKET_TAG else $BITBUCKET_COMMIT[:7] content f* {version} deployed on {$(date %Y-%m-%d)} by {$(whoami)} c.append_page(page_id, content) 逻辑说明$CONFLUENCE_TOKEN是 Confluence 的 Personal Access TokenSettings → Personal access tokenspage_id是 Confluence 页面的数字 IDURL 中?pageId123456789c.append_page()在页面末尾追加一行格式为 * v1.本文还有配套的精品资源点击获取
