工具下載安裝

• git客戶端工具
• 圖形化操作工具TortoiseGit
• TortoiseGit漢化語言包

內部下載地址：ftp://192.168.3.2/版本管理/Git/ 帳號密碼:ftpdown down_888

1. Git-2.12.2.2-64-bit
2. TortoiseGit-2.4.0.2-64bit
3. TortoiseGit-LanguagePack-2.4.0.0-64bit-zh_CN

開始干活

常用配置

通過TortoiseGit工具的設置,可以提高日常操作代碼倉庫的效率,請根據(jù)自己后續(xù)的需要回看此點進行配置.

git進入設置菜單

1. 設置右鍵直接可以看到的菜單,比如拉取、提交边坤、推送痕貌、簽出等常用菜單項
2. 設置隱藏菜單項,即在二級菜單中你都找不到的,可以防止干擾,使用一定時間后可以根據(jù)自己的需要干掉一部分,清爽舒心
3. 查看差異及合并工具指定,此處強烈安利BCompare,自帶的工具讓人感到絕望
   
   具體配置項

克隆版本庫（下載代碼）

打開 公司內部代碼倉庫,定位參與開發(fā)的版本庫并打開到概況頁面（默認即進入概況頁）

克隆時選擇的網(wǎng)址

本地準備好存放代碼的目錄,右鍵克隆(git clone)并確認窗口內的目錄是否為想要存放代碼的位置,請一定按默認名稱存儲,防止多個項目的代碼搞混

工作目錄右鍵進行克隆

克隆地址設置

獲取最新代碼

首次克隆代碼,本地代碼倉庫為遠程倉庫設置的缺省分支的最新提交,若開發(fā)階段暫未啟用新分支的項目組可以不需要再次獲取代碼,否則通過右鍵菜單中的拉取（git pull）獲取最新提交的代碼.

拉取與獲取的區(qū)別签夭？（git pull & fetch）

• 拉取：獲取最新提交代碼 + 獲取
• 獲取：僅獲取遠程倉庫最新分支、標簽等指針類信息

分支策略（項目經(jīng)理關注）

git帶有非常強大的分支管理能力,可以滿足各類研發(fā)或迭代項目的版本控制需要,很多靈活高級的用法可以根據(jù)項目的需要去調整,大家可以根據(jù)相關的教程模擬測試并應用,此處不再贅述.本次僅以最簡單常見的敏捷開發(fā)過程中如何保障發(fā)布版本與開發(fā)不相干擾.

網(wǎng)店管家(云端版)分支及標簽

單主干模式由于所有開發(fā)人員都在維護同一套版本代碼,如果沒有自動集成及自動化測試支撐,無法確保主干代碼的穩(wěn)定性.通常已發(fā)布的產品,至少會有兩個主分支,其中之一對應生產環(huán)境,另一支對應開發(fā)環(huán)境,線上問題的修正與快速迭代同步進行.

• 默認創(chuàng)建的版本已存在master分支,此分支用于發(fā)布到生產環(huán)境,生產環(huán)境出現(xiàn)問題基于此分支創(chuàng)建新分支進行修復,修復完成后合并到master及開發(fā)分支.
• 創(chuàng)建一個用于新功能研發(fā)的分支develop,每次新功能的發(fā)布都基于此分支,發(fā)布后的分支需要及時合并到master分支.

如果項目組中開發(fā)成員較多,可以再切割為更小規(guī)模的小組用于某獨立新功能的研發(fā).

日常研發(fā)是否需要分拆多個分支進行,取決與團隊的規(guī)模,通過人員或功能的劃分盡可能的減少多人改寫同一代碼單元的可能性,以減少日常沖突出現(xiàn)的幾率.

創(chuàng)建分支

項目經(jīng)理根據(jù)研發(fā)團隊版本控制需要創(chuàng)建對應分支,可以通過簽出(git checkout)時選擇create new branch或直接右鍵創(chuàng)建分支(create branch).
開發(fā)成員根據(jù)為避免沖突及代碼覆蓋,可以簽出時創(chuàng)建本地工作分支(原因見如何減少沖突部分).

分支選擇（成員關注）

1. 研發(fā)角色
   根據(jù)項目經(jīng)理分配,管理與開發(fā)任務對應的開發(fā)分支,日常開發(fā)時,請確保分支選擇正確,每日開始工作前獲取最新代碼,確認分支名稱.

查看或查看分支名稱,通過菜單右鍵中的簽出（git check out)來操作或查看.

到需要提測發(fā)布階段時,從develop分支開出發(fā)布分支(release類型),系統(tǒng)測試完成后合并到develop及master分支并刪除該發(fā)布分支.

2. 維護角色
   值班或其他排查問題的同事,需要將分支定位到master分支進行跟蹤,發(fā)現(xiàn)緊急問題基于master分支開出修復新分支(hotfix類型),修復后及時合并到主干及開發(fā)分支并刪除修正分支.

提交代碼

提交與推送的區(qū)別(git commit & git push)
前置是提交到本地的代碼倉庫,后者是將本地代碼倉庫已提交的內容同步到遠程代碼倉庫

代碼做出更改后,右鍵選擇提交,備注本次提交變更的內容,或者在vs等ide中集成的工具直接提交.也可以提交并推送,推送時可能會遇到提示本地代碼倉庫版本較低或出現(xiàn)沖突的情況,具體處理見合并分支及沖突解決部分.

合并分支(merge)

1. 開發(fā)成員的代碼合并

每個開發(fā)的電腦上都相當于有一套版本庫,在將代碼推送到遠程倉庫時,就涉及代碼合并.

原因說明
從遠程拉取最新代碼時,相當于建立了一個遠程分支的分支,并基于此分支做后續(xù)改動,而遠程的分支又有其他同事在同步改動,此時就出現(xiàn)兩個不同的分支,所以在拉取代碼時也相當于做了一次代碼合并,一旦代碼存在沖突就需要做合并

2. 項目經(jīng)理的代碼合并

新功能的發(fā)布\生產環(huán)境bug修正,最終都需要合并到master或develop分支,如果功能劃分時重合度較高,此時合并代碼的工作量多\風險高.
具體合并的方法:

1. 先簽出到目標分支上,拉取最新代碼.
2. 操作合并(merge),選擇源分支(及需要合并到主干或開發(fā)分支的工作分支).
3. 通過日志與合并前的最后一次提交做對比,復核代碼的正確性.
4. 如果3中出現(xiàn)沖突,按下方解決沖突的方法處理.

沖突解決(resolve conflicts)

具體開發(fā)過程中會發(fā)現(xiàn),其實沖突做所難免,大家都需要知道如何正確的解決沖突.

1. 何為沖突

多人在同時維護同一份代碼文件且git無法判斷是否改動不同的代碼塊時,就需要人工介入?yún)f(xié)助完成無法自動合并的內容.

發(fā)現(xiàn)沖突

沖突處理的可選方案

2. 處理沖突

可以通過BCompare直觀的查看沖突的原因,從下圖中可以看出解決沖突涉及三個版本(BASE LOCAL REMOTE),其中BASE為沖突產生的兩個分支最近一次繼承的提交(都是從此出衍生而來).

解決沖突

根據(jù)實際情況整合得到正確的輸出在工作目錄下.

創(chuàng)建標簽(create tag)

標簽作用是定位到某個穩(wěn)定的版本,可以供發(fā)布時回滾或問題追溯,標簽的使用與分支基本一致,差別在于標簽不可再次提交改動,具體應用同如何簽出到某個分支.

• 項目進入發(fā)布階段時,項目經(jīng)理需要及時對穩(wěn)定的develop或master分支打上標簽
• 生產環(huán)境出現(xiàn)bug修復后及時給master分支加上新標簽

如何減少沖突

解決沖突是非常耗費精力且風險很高的一項工作,而我們通過一些技巧可以避開一些不必要的沖突.

1. 合理劃分各開發(fā)成員維護代碼的范圍,盡可能的減少多人維護同一單元的情況出現(xiàn).可以通過模塊的劃分\公共單元特定人維護等工作任務分配時進行物理隔離.
2. 合理拆分開發(fā)團隊,通過分支策略隔離日常開發(fā)過程中的沖突(注:不能解決發(fā)布時合并代碼的沖突).

3. 開發(fā)成員在具體開發(fā)過程中,盡量自行在本機工作區(qū)再次建立工作分支,在專項工作完成后再合并到開發(fā)分支并推送到遠程倉庫.

   
   
   git日常開發(fā)分支管理

少量修正代碼,可以不新建分支再合并,可以直接調整完后不提交,使用貯藏(stash save)將當前的變更存儲起來,然后再次拉取最新代碼,再彈出貯藏(pop stash).
另外可以通過貯藏列表(stash list)查看多次貯存的內容

如何避免覆蓋他人代碼

當你若無其事的推送完一次代碼,不久后隊友發(fā)現(xiàn)令人絕望的事故---提交的代碼不見了!
沒有動過他們的代碼\沒看到有任何沖突的提示,為什么???
具體的原因基于git自動合并代碼的機制,合并代碼時基準版本是local而不是remote,當發(fā)現(xiàn)你本地的文件較新時(與本地操作系統(tǒng)的文件系統(tǒng)有關),它可能會認為你把部分代碼刪除了,然后他人所加的代碼自然被無情的覆蓋.
為了減少不必要的麻煩(可能整個團隊都要為此做一次代碼恢復...),大家最好參照如何減少沖突部分推薦的做法進行日常的版本維護(可能有其它更實用的辦法,集思廣益).另外再每次推送代碼到遠程倉庫后,請按開發(fā)規(guī)約review提交的代碼,如果發(fā)現(xiàn)自己提交中包含多個未改動的文件,及時找項目經(jīng)理協(xié)調解決減少對其他成員的影響.

如何恢復被覆蓋代碼

1. 先定位到源頭,找到該成員提交前最后一位其他成員的提交
2. 本地代碼拉取到最新狀態(tài),復原(revert to this commit)指定的提交(含工作區(qū)與倉庫索引項,最下面的選項)
3. 推送到遠程倉庫,推送時把強制(force)選項中的 知道所有的變更(known changes) 勾選,確認后將強制把遠程倉庫的代碼恢復到此提交
4. 所有項目成員檢查本地代碼倉庫,是否包含源頭中被覆蓋的提交
5. 源頭及在被覆蓋的代碼基礎上做過代碼改動的成員,按如下步驟修復:
   5.1 確認所有內容提交后在此本地分支上建立一個新的分支
   5.2 將工作分支復原到未被影響的提交(可再拉取一次確保最新)
   5.3 將剛才新建的分支合并到工作分支,提交并推送到遠程倉庫

入門到精通(DIY)

• git中文手冊
• git官方手冊
• 廖雪峰Git教程