1. 首頁 > 生活百科 > >

計算機編程代碼大全 代碼版本管理工具

生活百科分支


代碼管理中遇到的意外 代碼是企業在整個研發活動中非常重要的資產，如果代碼出現了問題，那么為客戶提供的產品和服務，都會由于這些問題造成不可預知的事故，對企業造成負面影響 。所以，如何讓代碼管理變得更加有序可靠，是廣大企業和研發團隊亟需重視的問題 。
一個企業的研發團隊都是由多個開發人員組成的 。不同的開發人員技術水平有差異，擅長的領域也有區別，并且軟件的開發的過程就是一個多人協作的過程，團隊成員使用 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 分支新功能的合并，又不影響發布內容的驗證 。從上面這個過程就能看出來，分支模型一定是和開發工作的模式關聯起來的，也會隨著團隊規模和業務特定進行調整，比如說團隊給不同客戶的版本有差異，就會根據不同的客戶版本創建一個分支 。適合自己團隊特點的分支模型，就是最好的 。

猜你喜歡