Git on 華為云DevCloud

1 文章目的

本文主要幫助已經掌握或者想要掌握Git的開發者，如何更好的應用Git，以及更好的將Git與DevCloud結合應用。

2?概述

2.1?版本控制系統介紹

從狹義上來說，版本控制系統是軟件項目開發過程中管理代碼所有修訂版本的軟件，能夠存儲、追蹤文件的修改歷史，記錄多個版本的開發和維護，事實上我們可以將任何對項目有幫助的文檔交付版本控制系統進行管理。版本控制系統（Version Control Systems）主要分為兩類，集中式和分布式。

2.1.1?集中式版本控制系統

集中式版本控制系統的特點是只有一臺中央服務器，存放著所有研發數據,而其它客戶端機器上保存的是中央服務器最新版本的文件快照，不包括項目文件的變更歷史。所以，每個相關人員工作開始前，都需要從這臺中央服務器同步最新版本,才能開始工作。

集中式版本控制系統的優點：

1.?操作簡單，使用沒有難度，可輕松上手。

2.?文件夾級權限控制，權限控制粒度小。

3.?對客戶端配置要求不高，無需存儲全套代碼。

集中式版本控制系統的缺點：

1.?網絡環境要求高，相關人員必須聯網才能工作。

2.?中央服務器的單點故障影響全局，如果服務器宕機，所有人都無法工作。

3.?中央服務器在沒有備份的情況下，磁盤一旦被損壞，將丟失所有數據。

2.1.2?分布式版本控制系統

分布式版本控制系統的特點是每個客戶端都是代碼倉庫的完整鏡像，包括項目文件的變更歷史。所有數據分布的存儲在每個客戶端，不存在中央服務器。可能有人會問，我們公司使用Git分布式存儲工具，也有“中央服務器”啊？其實,這個所謂的“中央服務器”僅僅是用來方便管理多人協作，任何一臺客戶端都可以勝任它的工作，它和所有客戶端沒有本質區別。

分布式版本控制系統的優點：

1.?版本庫本地化，版本庫的完整克隆，包括標簽、分支、版本記錄等。

2.?支持離線提交，適合跨地域協同開發。

3.?分支切換快速高效，創建和銷毀分支廉價。

分布式版本控制系統的缺點：

1.?學習成本高，不容易上手。

2.?只能針對整個倉庫創建分支，無法根據目錄建立層次性的分支。

3?前提條件

3.1?華為云賬號

使用華為軟件開發服務，首先需要注冊一個華為云賬號。

3.2?Git客戶端

Git是一款開源的分布式版本控制系統(Distributed Version Control System) ，誕生于2002年，由Linux之父Linus Torvalds帶領Linux開源社區開發完成，初衷是用其管理Linux內核的龐大的開源代碼。在當今敏捷開發成為主流,研發周期短，跨地域協同開發多的大形勢下，選擇Git版本管理工具是大勢所趨。國內外有很多基于Git的云端代碼托管服務，華為軟件開發服務（Devcloud）配置管理服務就是其中之一。

代碼托管（CodeHub）是面向軟件開發者提供的基于Git的在線代碼托管服務，包括代碼克隆/下載/提交/推送/比較/合并/分支等。代碼一鍵下載到本地，基于本地IDE開發，開發完畢一鍵推送云端，實現線上線下協同開發

3.2.1?Git Bash 下載安裝

Git?Bash客戶端軟件是本地PC使用git必須安裝的軟件，如果本地沒有安裝，請到https://git-scm.com/downloads下載。

安裝成功以后，在開始菜單中會增加Git Bash選項。

3.2.2?配置個人信息

安裝完成，運行Git Bash，在彈出終端頁面按照下面操作進行個人配置。

3.2.3?生成密鑰

運行Git Bash, 生成一對SSH密鑰，在彈出的終端中輸入下面命令，回車后會提示您輸入一個密碼，建議不輸入，一路回車即可。

此時，會在~/.ssh文件夾下生成了一對密鑰，公鑰id_rsa.pub和私鑰id_rsa，私鑰無需處理，保存在本機就可以了，公鑰的內容需要拷貝到軟件開發服務中。

3.3?已經創建好的項目

創建項目

在華為云官網首頁 ???產品????軟件開發服務，進入華為軟件開發服務首頁。

點擊右上角“新建”按鈕新建項目

輸入項目名稱，選擇開發流程，輸入項目描述，點擊“新建”按鈕即完成了一個項目的創建。

4?Devcloud場景應用

4.1?CodeHub操作

4.1.1?新建空倉庫

在開發云代碼服務中，點擊上方“新建倉庫”按鈕

新倉庫的詳細配置如下:

新建成功

4.1.2?粘貼ssh公鑰

第一步：運行Git?Bash，在終端執行如下命令，會將.ssh文件夾下的id_rsa.pub公鑰內容（灰色背景的字符串）打印到終端，拷貝這些字符串，注意不要有多余的空格。

第二步：在開發云代碼服務中，點擊右上角的“設置SSH密鑰”

第三步：繼續點擊右上角的“添加SSH密鑰”

第四步：粘貼拷貝的公鑰字符串，添加“標題”，點擊“新建”就可以了。

4.2?云端倉庫功能一覽

功能

描述

新建倉庫

用戶可以在項目中創建一個或多個代碼倉庫。

倉庫克隆

用戶可以使用克隆功能將代碼下載到本地進行開發。

分支管理

用戶開發過程中可以使用拉取分支功能進行不同特性和補丁的開發。

標簽管理

產品開發或迭代過程可以使用標簽記錄版本迭代。

分支合并

在特性或補丁開發完成后可以使用分支合并功能將特性或補丁合入主干分支。

分支保護

倉庫管理員可以使用分支保護功能控制分支的刪除和代碼提交。

提交代碼

開發過程中通過提交方式將代碼提交到倉庫中。

拉取代碼

通過拉取代碼可以獲取遠端倉庫的的最新代碼。

推送代碼

通過推送代碼功能將本地庫代碼上傳到遠端倉庫。

代碼閱讀

可以通過Web在線方式閱讀代碼。

在線修改

可以通過Web在線方式修改。

活動記錄

倉庫代碼提交、成員變更等信息都可以通過活動記錄查看，方便管理者審核或追溯代碼。

倉庫模板

提供有代表性的倉庫模板，用戶可以根據倉庫模板創建代碼倉庫。

倉庫成員管理

倉庫管理員可以設置用戶是否可以訪問倉庫并設置訪問權限。

倉庫關注

用戶可以關注經常使用的倉庫，倉庫關注后會默認排在前面方面查看。

密鑰管理

用戶默認不感知，在創建代碼檢查任務或編譯構建任務時會自動添加部署密鑰，在代碼檢查或編譯構建下載代碼時根據部署密鑰下載，部署密鑰只能用于下載代碼不能上傳代碼，保證安全性。

5?Git本地研發場景

5.1?克隆代碼

在本地準備克隆代碼的目標文件夾，右鍵打開git bash終端

執行如下命令：

5.2?代碼提交

一次修改被成功提交到遠端倉庫會歷經四個階段，1本地工作區->2緩存區->3版本庫->4遠端版本庫，通過執行相應的Git命令，文件在這四個區域跳轉，并呈現不同的狀態，主要涉及三步操作：

#git add/rm filename ????//將新增、修改或者刪除的文件增加到暫存區

#git commit ?–m “commit message” ??//將已暫存的文件提交到本地倉庫

#git push????//將本地代碼倉庫修改推送到遠端倉庫

5.3?分支操作

5.3.1?新建分支

Git新建分支的本質就是創建一個指向最后一次提交的可變指針，所以，Git分支的創建不是復制版本庫的內容，僅僅是新建了一個指針，它以40個字符長度SHA-1字串形式保存在文件中。

#git branch?branchName?commitID

基于commitID即某一個全球版本號拉出新分支，如果沒有commitID則基于當前分支的HEAD拉出新分支。

如下圖新建feature分支執行的命令為git branch feature

5.3.2?切換分支

#git checkout?branchName

如下圖切換到feature分支執行的命令為git checkout?feature

5.3.3?分支合并

無論哪種工作流都會涉及到分支合并（把一個分支中的修改整合到當前分支），主要有兩種方法：三方合并（merge）?和衍合（rebase）。我們通過對同一種場景進行不同操作體會兩種合并方法的區別。

場景：master分支新增了C4節點， hotfix分支新增了C3節點，現將hotfix分支合并到master分支：

1.?三方包括hotfix新增節點C3，master新增節點C4，以及兩者的共同祖先節點C2。這種合并操作簡單，但新增合并節點C5，形成了環形，版本記錄可讀性差。

#git checkout master

#git merge hotfix

2.?衍合先將master分支新增節點C4以補丁形式保存在.git/rebase目錄中，然后同步hotfix分支最新代碼，再應用補丁C4’。

#git checkout master

#git rebase hotfix

5.3.4?沖突解決

類型一：兩個合并分支修改了同一行代碼

解決方法：

1.?分析哪種修改方法正確，手動合并；

2.?提交修改。

類型二：文件被重命名為不同的名字

解決方法：

1.?確認哪個名字是正確的，刪除錯誤的；

2.?提交修改。

6?Git工作流

什么是Git工作流？你可以理解為代碼管理的分支策略，它不僅僅是版本管理范疇，更服務于項目流程管理和團隊協同開發。所以，我們有必要制定適合自己研發場景的工作流。

下面介紹四種工作流的工作方式、優缺點，以及使用中的一些注意事項。

1.?集中式工作流

2.?功能分支工作流

3.?gitflow工作流（Devcloud推薦）

4.?forking工作流

6.1?集中式工作流

集中式工作流適合5人左右小開發團隊，或是剛從SVN工具轉型為Git的團隊，它只有一個默認的maste分支（相當于svn的trunk主分支），所有人的修改都是在master分支上進行的。但是，這種工作流無法充分發揮git優勢和多人協同，不推薦使用。

工作方式：

開發人員將master分支從中央倉庫克隆到本地，修改完成后再推送回中央倉庫master分支。

優點：

不涉及分支交互操作

缺點：

1.?不適合人員較多的團隊，當人員10+時，解決開發人員之間的代碼沖突會耗費很多時間；

2.?master分支提交頻繁；

3.?master分支不穩定，不利于集成測試。

Tips：如何盡量避免產生沖突和不合理的提交歷史？

開發人員在開發一個新功能之前，一定要在本地同步中央倉庫最新代碼，使自己的工作基于最新的代碼之上；開發完成后，在提交新功能到中央倉庫前，需要先fetch中央庫的新增提交，并rebase自己的提交。這樣做的目的是，把自己的修改加到中央倉別人已經提交的修改之上，使最終的提交記錄是一個完美的線性歷史，而不是環形。

舉例：

1.?開發人員A和開發人員B同時在某個時間拉取了中央倉庫的代碼

2.?開發人員A先完成了自己的工作，并提交到中央倉庫

3.?開發人員B需要在本地執行git pull –rebase中央倉庫的新提交，這時開發人員B的本地倉庫就包含了開發人員A修改的內容，并在A的基礎上增加了自己的修改

4.?開發人員B將代碼推送到中央倉庫

6.2?功能分支工作流

通過新建幾個功能分支，增加開發者的交流和協作，它的理念是所有的功能開發都應該在master分支外的一個獨立分支進行，這種方式隔離了開發者的工作空間不被互相干擾，保證了master分支的穩定性。

工作方式：

開發人員每次在開始新功能開發前，需要在master分支上拉取一個新分支，并起個有描述性的名字，比如video-output或issue-#1061，這樣可以讓分支用途明確。功能分支不但存在開發人員本地倉庫，也應該推送到中央倉庫，這樣就可以在代碼不合入master分支的情況下與其他開發人員分享代碼。

優點：

分支合并前可以使用pull request進行code review；

降低了master分支的提交頻率

缺點：

只有一個master分支作為集成，仍然不是很穩定，不適合大型開發

6.3?Gitflow工作流

Gitflow一般用于管理大型項目，它為不同的分支分配一個很明確的工作角色，并定義分支之間什么時候進行交互。

工作方式：

master分支：生產分支，最穩定的版本，一直是ready to deploy狀態。不接受開發人員直接commit，只接受從其他分支merge操作。在很多企業中，這個分支被默認開啟分支保護，只有維護者可以操作。

hotfix分支：從master分支拉取的臨時修復分支，用于解決一線緊急bug。bug解決后需要合入master分支并打上新的版本號，這個修改也需要同時合入develop分支。

develop分支：從master分支拉取的開發分支，用于功能集成。包含所有要發布到下一個Release的代碼用于開發集成、系統測試。

release分支：臨近既定的發布日，就從develop分支上拉取一個release分支，任何不在當前分支中的新功能都推到下個發布中。release分支用于發布，所以從當前時間點之后新的功能不能再加到這個分支上，這個分支只做Bug修復、文檔生成和其它面向發布的任務。當對外發布的工作都完成了，release分支合并到master分支并分配一個版本號打好Tag；另外，這些從release分支新做的修改要反向合并回develop分支。

feature分支：開發者使用的特性分支，父分支是develop分支，當新功能完成時，合入develop分支。新功能提交從不直接與master分支交互。

###############################################################################

開發人員提交新功能的兩種途徑：

1.?團隊有專人review審核新功能

a)?開發人員將feature分支推送到華為軟件開發云代碼托管平臺（中央倉庫）

b)?發起一個從feature分支合并到develop分支的pull request請求，并指給review專員

c)?review專員審核。如果通過，將feature分支的新功能合并到develop分支，并刪除feature分支；如果未通過，拒絕該請求并注明拒絕原因。

2.?開發人員自審核新功能

a)?開發人員在本地倉庫將feature分支合并到develop分支，并刪除feature分支

b)?將本地develop分支的修改推送到華為軟件開發云代碼托管平臺（中央倉庫）

###############################################################################

優點：

1.?使用一個用于發布準備的專門分支（release分支），使得一個團隊可以在完善當前的發布版本的同時，可以在develop分支并行繼續開發下個版本的功能。這也打造了可視化的發布階段，團隊成員都可以在倉庫網狀結構中可以看到發布狀態；

2.?使用緊急修復分支（hotfix分支）讓團隊可以處理緊急問題的同時而不打斷其它工作或是等待下一個發布再合入hotfix修改。我們可以把hotfix分支想成是一個直接在master分支上處理的臨時發布；

3.?大型項目人員協作頻繁，流程較多，合理的多角色分支幫助研發有條不紊進行；

4.?更符合devops理念。

缺點：

1.?學習成本較高；

2.?如果團隊不遵守使用約定，帶來的影響更大。

6.4?forking工作流

Forking工作流區別于前三種工作流的最大特點是每個開發人員都有一個從公共倉庫fork出來的屬于自己的公共倉。Forking工作流適合外包、眾包以及眾創和開源場景。接包方的開發人員從項目公共倉fork自己的公共倉庫進行操作，并不需要被項目公共倉直接授權。

工作方式：

將“項目公共倉”fork出一個“個人公共倉”

將“個人公共倉”clone到“本地倉庫”

操作“本地倉庫”，修改完成后提交到“個人公共倉”

為“個人公共倉”提交一個pull request給項目維護者，申請代碼合入“項目公共倉”

項目維護者在本地review、驗證本地提交，審核通過后push進入“項目公共倉”

Tip：如果開發人員A的代碼未被審核通過合入“公共倉庫”，而此代碼對開發人員B有借鑒作用，開發人員B可以直接從開發人員A的“個人公共倉”拉取代碼。

優點：

1.?開發人員之間若需要代碼協作，可以直接從其他人的“個人公共倉”拉取，無需等到代碼提交到項目公共倉；

2.?“項目公共倉”無需為每個代碼貢獻者授權；

3.?項目維護者通過審核pull request成為代碼安全的重要防線；

4.?倉庫分支的選擇可以根據項目實際情況綜合使用前三種工作流。

缺點：

1.?提交步驟繁瑣，開發人員代碼到最終版本庫的周期較長。

研發團隊可以根據實際研發場景制定合理的工作流，能有效提高項目管理水平和團隊協同開發能力，?并通過華為軟件開發云CodeHub平臺，高效、安全的管理代碼資產，將更多的精力集中在業務開發上，實現持續集成、持續交付和快速迭代的目標。

7?FAQ

華為云社區Devcloud產品答疑FAQ

http://forum.huaweicloud.com/forum-642-1.html

8?附錄

8.1?軟件開發云（DevCloud）用戶指南

1、視頻教程

【新手訓練營】幾分鐘教你掌握各個服務基本操作

項目管理??配置管理??流水線??代碼檢查??編譯構建??測試管理??部署??發布

【云途進階課】場景化教學，從實戰中玩轉軟件開發云

Web應用場景——開發一套EHR系統：規劃階段??開發階段??交付階段

App應用場景——打造一款趣味交友App：規劃階段??開發階段??交付階段

遷移上云秘籍

1、從SVN遷移到GIT最強指南

2、為何選擇Git版本控制系統

3、Git的工作模式

4、如何將本地代碼提交到托管平臺

git 軟件開發云 DevCloud

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。