Bitbucket 代碼庫的常規操作
代碼提交
儘管越來越多的開發者轉向使用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進行操作可能更為便捷。
