程式碼管理中遇到的意外
程式碼是企業在整個研發活動中非常重要的資產，如果程式碼出現了問題，那麼為客戶提供的產品和服務，都會由於這些問題造成不可預知的事故，對企業造成負面影響。所以，如何讓程式碼管理變得更加有序可靠，是廣大企業和研發團隊亟需重視的問題。
一個企業的研發團隊都是由多個開發人員組成的。不同的開發人員技術水平有差異，擅長的領域也有區別，並且軟體的開發的過程就是一個多人協作的過程，團隊成員使用 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 企業版，將程式碼管理變得更加有序可靠，幫助企業避免因為程式碼管理方面的混亂所造成的業務損失。
Gitee 企業版 - 企業級 DevOps 研發效能管理平臺
中還有很多的功能，可以幫助企業在研發活動中，大大提升企業的研發效率，並且讓程式碼質量產生明顯提升。後續我們也會不斷輸出在專案管理、程式碼管理方面的實踐，幫助企業使用者在 Gitee 上更好地進行研發管理，讓企業的研發速度緊緊跟隨企業業務發展的腳步。
