代碼管理中遇到的意外

代碼是企業在整個研發活動中非常重要的資產，如果代碼出現了問題，那麼為客戶提供的產品和服務，都會由於這些問題造成不可預知的事故，對企業造成負面影響。所以，如何讓代碼管理變得更加有序可靠，是廣大企業和研發團隊亟需重視的問題。

一個企業的研發團隊都是由多個開發人員組成的。不同的開發人員技術水平有差異，擅長的領域也有區別，並且軟件的開發的過程就是一個多人協作的過程，團隊成員使用 Gitee 時間不長，對 git 也在慢慢學習，那麼在這個過程中一定會有一些大大小小的意外，下面的這三個情況你一定遇到過：

• 幾個人開發的內容互相有影響
• 不知道誰把重要分支的代碼給修改了，或者乾脆直接把分支刪除了
• 合併代碼的時候，Code Review 浮於表面或乾脆沒有 CodeReview 環節

今天我們就針對上面這三個問題，為大家分享如何通過 Gitee 企業版的代碼託管功能解決這些問題，讓企業的代碼管理變得更加有序可靠。

Gitee企業版實踐

1.分支模型

無論是大企業還是小企業，在最開始，都會困惑於分支模型如何規劃。我們最常看到、最常聽到的一種分支模型就是上面這張 git-flow 分支模型的圖。但 git-flow 的分支模型，並不能適應每一個企業，分支模型和其他的管理模式一樣，一個企業需要有適合自己的模式。

企業想要構建適合自己業務特點的分支模型，首先要清楚分支的用途：

• 管理唯一產品版本的分支 master 就是用來管理產品最穩定代碼的分支，如果企業內開發場景非常簡單，那麼就可以直接在 master 分支上進行開發和發佈。隨着團隊規模的增加，在保障產品發佈版本代碼的穩定的情況下，會在其他分支進行開發，完成後將穩定的版本合入到 master 分支。
• 進行隨時更新的分支 git-flow 中，develop 分支就是做這個作用的。由於 master 分支只管理穩定的發佈版本代碼，開發過程就會將代碼提交到 develop 分支中，並且可以把 develop 的代碼發佈到測試環境中，完成測試、發佈後，再把 develop 分支的內容合併到 master 分支上面去。這樣就可以形成穩定的發佈分支和隨時更新的開發分支。
• 修復緊急缺陷的分支 在產品發佈之後，很有可能出現緊急的生產缺陷，這些生產缺陷我們需要進行修復，測試以後，才可以發佈新的生產版本。但是由於開發分支 develop 已經新增加了很多功能，不能直接從開發分支進行修改，發佈分支 master 直接修改會影響到發佈版本的管理，所以可以從 master 分支中，創建一個專門用來緊急修復缺陷的 hotfix 分支。我們在 hotfix 分支中進行修復和測試，完成後再合併到 master 分支上面去，完成發佈。
• 獨立的需求開發分支 在開發團隊規模增大之後，團隊內部開發人員較多，大家共同在開發分支 develop 進行編碼會造成大家的代碼互相影響，所以，可以為開發不同的需求，創建屬於這個需求自己的開發分支，在 git-flow 中提交 feature 分支。每一個開發人員在自己需求的開發分支 feature 上進行開發，完成後合入到 develop 中，這樣就可以保證 develop 分支的內容都是已經完成的需求，可以隨時進行測試。
• 設置專用的發佈分支 團隊規模不斷增大後，為了使開發的過程可以和投產驗證的過程獨立，在需要進行版本發佈的時候，就可以拉一條發佈分支 release 分支，在 release 分支上進行測試和缺陷修復，通過後再發佈到 master 分支。這樣，既不會影響到 develop 分支新功能的合併，又不影響發佈內容的驗證。

從上面這個過程就能看出來，分支模型一定是和開發工作的模式關聯起來的，也會隨着團隊規模和業務特定進行調整，比如說團隊給不同客戶的版本有差異，就會根據不同的客戶版本創建一個分支。適合自己團隊特點的分支模型，就是最好的。

2.保護分支

我們重要的分支因為開發人員的誤操作，導致分支上面的代碼不正常，或者重要的分支被刪除，這些情況會造成我們企業非常大的損失，會使我們花大量的時間去修復這些問題。所以，Gitee 企業版中也提供了相關的功能，最大程度地避免類似問題的發生。

Gitee 在分支管理中，提供了保護分支的功能，在企業裏面，我們可以把開發負責人設置成為倉庫的管理員，其他開發人員設置為開發者角色。這樣開發負責人就可以將重點分支比如 master 分支和 develop 分支設置為保護分支。

設置保護分支後，擁有開發者權限的普通開發人員，是無法直接將代碼提交到保護分支的，並且也無法將保護分支進行刪除，只能由擁有管理員權限的用戶進行操作，這樣就極大地幫助團隊將重要的代碼版本管控起來，不會受到開發人員意外操作的影響。

作為擁有管理員權限的開發負責人，可以通過設置保護分支規則，授權給其他開發人員代碼推送和代碼合併的權限。這樣可以讓團隊中的成員來幫助自己進行代碼審核，來維護保護分支上的代碼，還可以防止分支被誤刪除的情況發生。

但如果設置了保護分支，普通開發人員無法直接將代碼提交到保護分支上面來，那麼如何將代碼合併到保護分支上面來呢？這就會使用到 Gitee 企業版中的一個重要功能：代碼評審（Pull Request）。

3.代碼評審（Pull Request）

開發人員在完成對自己功能的開發後，需要將 feature 分支上面的內容合併到集成開發分支 develop 上面，就需要通過代碼評審（Pull Request）功能，把自己開發完成的內容，提交給開發負責人進行評審，在評審通過後，即可把代碼合併到目標分支上。

通過代碼評審的方式，可以保證團隊每一次對重要分支的修改，都能夠讓開發負責人清晰的看到代碼修改的內容並進行評審，並對每一次代碼合併的內容進行記錄留底，保證代碼合入的可靠性。

3.1 開發人員提交代碼評審

開發人員通過代碼評審功能，創建 Pull Request，選擇自己開發任務所在的分支，並選擇需要進行合入的目標分支。填寫本次提交變更的標題和描述信息，告訴評審人員本次需要代碼合入的內容。

開發人員提交時可以選擇評審人員，本次合併需要哪些開發人員進行評審。管理員可以通過系統設置進行評審的人員名單。這樣，必須在所選的評審人員和測試人員審批過後，代碼才可以合併。

在創建代碼評審時，可以看到我們本次開發代碼時，增加了多少次提交，改動了多少個文件。

填寫完成相關信息後，即可創建代碼評審請求，評審人員需要對代碼合併內容進行評審。

3.2 負責人檢查提交內容

評審人員在看到開發人員提交的代碼評審請求後，可以查看代碼評審的內容，包含代碼評審的描述信息，關聯的任務信息，了解開發人員提交代碼的背景信息，幫助評審人員更好的評審代碼。

在評審時，評審人員最需要的內容就是文件改動信息。評審人員在這裡可以看到開發人員提交的分支信息與需要合入到的目標分支上面的所有差異文件，並且修改的內容都會高亮進行標註，使評審人員可以快速定位到需要評審的內容。

在發現問題時，可以直接在代碼行間增加評論內容，指出開發人員的代碼編寫問題，開發人員可以在看到評審人所給出的問題後修復自己的代碼。

評審人員可以逐個文件進行審查，添加自己的評審意見，如果代碼存在較大問題，可以直接拒絕評審請求，被拒絕的代碼無法合入到目標分支中。

3.3 代碼審批通過後合併評審內容

開發人員進入到自己創建的評審請求後，可以看到評審人員對自己代碼的評審意見，可以根據評審意見進行代碼修改。在代碼修改完成後重新提交代碼。

評審人員需要再次對開發人員提交的代碼進行評審，滿足合入標準後，可以點擊評審通過，即可進行代碼合併。點擊合併分支後，開發人員完成的代碼，即可合入到目標分支上，完成整個代碼合入的過程。

完成代碼評審，代碼合入到目標分支後，代碼合入的內容，代碼評審的內容，全部都可以在代碼評審的歷史合併中看到，方便我們後續對代碼對變更進行追溯。

3. 代碼管理實踐總結

我們通過在企業內部建立符合企業開發團隊特點的分支模型，並通過 Gitee 企業版中提供的保護分支功能，及最重要的代碼評審（Pull Request）流程，可以保證我們通過Gitee 企業版，將代碼管理變得更加有序可靠，幫助企業避免因為代碼管理方面的混亂所造成的業務損失。