Git作為最流行的代碼版本控制工具，基本上已經(jīng)成為了程序員的一個(gè)標(biāo)配技能。無(wú)論使用GitHub，GitLib，Gitee等進(jìn)行代碼托管，均基于Git。下面聊一聊開(kāi)發(fā)人員必會(huì)的幾個(gè)Git技巧和團(tuán)隊(duì)協(xié)作的一些Git工作流。

1 Git 常用的超級(jí)實(shí)用命令

1.1 與倉(cāng)庫(kù)相關(guān)的操作

克隆代碼倉(cāng)庫(kù)到本地，開(kāi)發(fā)必用

git clone  < url >

查看本地倉(cāng)庫(kù)配置了那些對(duì)應(yīng)的遠(yuǎn)程倉(cāng)庫(kù)。

git remote -v

添加遠(yuǎn)程倉(cāng)庫(kù)

git remote add < name >< url >

更新遠(yuǎn)程倉(cāng)庫(kù)地址

git remote set -url --push < name >< newUrl >

拉取遠(yuǎn)程倉(cāng)庫(kù)

git pull < remoteName >< localBranchName >

推送本地倉(cāng)庫(kù)到遠(yuǎn)程倉(cāng)庫(kù)，默認(rèn)是當(dāng)前所在branch

git push < remoteName >< localBranchName >

1.2 分支的創(chuàng)建切換等相關(guān)操作

查看本地分支/所有分支

git branch  / git branch -a

查看遠(yuǎn)程分支

git branch -r

創(chuàng)建本地分支

git branch < name >

本地創(chuàng)建分支并和遠(yuǎn)程分支關(guān)聯(lián)，再切換到該分支。

git checkout -b < 本地分支名 > < 遠(yuǎn)程倉(cāng)庫(kù)名 >/< 遠(yuǎn)程分支名 >
git branch -b < 本地分支名 > < 遠(yuǎn)程倉(cāng)庫(kù)名 >/< 遠(yuǎn)程分支名 >

根據(jù)遠(yuǎn)程分支創(chuàng)建本地分支，但是不會(huì)切換到新分支，需要手動(dòng)checkout

git fetch < 遠(yuǎn)程倉(cāng)庫(kù)名 > < 遠(yuǎn)程分支名 >:< 本地分支名 >

創(chuàng)建新分支并立刻切換到改分支

git checkout -b < name >

創(chuàng)建遠(yuǎn)程分支：

git push origin < name >

刪除遠(yuǎn)程分支

git push origin:heads/< name >
也可以push一個(gè)空的本地分支，那么也將刪除遠(yuǎn)程分支

修改分支名

git branch -m < oldName > < newName >
git branch -m < newName >  (修改當(dāng)前BranchName)

1.3 Tag相關(guān)

查看Tag

git tag

創(chuàng)建Tag

git tag < name >

刪除Tag

git tag -d < name >

查看遠(yuǎn)程Tag

git tag -r

push Tag到遠(yuǎn)程倉(cāng)庫(kù)

git push origin < tagName >

刪除遠(yuǎn)程Tag

git push origin:refs/tags/< tagName >

1.4 git 提交相關(guān)

先add 然后在提交，不過(guò)add大多時(shí)候利用開(kāi)發(fā)工具來(lái)做比較方便。

git add newfile.txt 
git commit -m "the commit message"

reset相關(guān)的命令可以回滾剛才的add或者提交，重設(shè)當(dāng)前分支

git reset [--hard|soft|mixed] [< commit >或HEAD]

最后一個(gè)參數(shù)默認(rèn)為HEAD，HEAD~2表示上上一個(gè)版本，也可以是某一個(gè)commit id處。

常用的三個(gè)參數(shù)hard/mixed/spft

--hard 將之前的提交全部刪除stage區(qū)清空，

--mixed 將之前的提交刪除，但是將改動(dòng)移動(dòng)到stage區(qū)（也就是index中）。

--soft 提交不改變變，將HEAD指向某commit id，有點(diǎn)像checkout

1.5 合并

合并其他分支到當(dāng)前的分支

git merge

合并分支fixes和enhancements在當(dāng)前分支的頂部

git merge fixes enhancements

將一個(gè)commit 合并到當(dāng)前分支

git cherry-pick < commit id >

合并幾個(gè)連續(xù)的commit

git rebase -i 4e08572

下面給出一組Rebase 的詳細(xì)示例

（1）windows 下，輸入上述命令之后, 輸入i 進(jìn)入編輯窗口，更改rebase策略。詳細(xì)解釋都有提示，只需根據(jù)提示輸入即可。

（2）選好rebase策略之后按Esc推出 輸入"：x" 執(zhí)行 剛才的rebase操作，然后會(huì)看到修改提交的信息界面

（3）修改提交信息，按Esc退出，并輸入 "：x" 執(zhí)行rebase操作

然后看到rebase成功

e

以上就是一個(gè)簡(jiǎn)單的rebase操作。

1.6 log & show

查看最近的5次提交，按Q就直接退出。

git log -5

使用ASCII圖形表示分支合并歷史

git log --graph

顯示最近5次提交的詳細(xì)內(nèi)容

git show -5

2 Git Work Flow

2.1 Centralized Workflow

Centralized WorkFlow 這種模式對(duì)比熟悉SVN的開(kāi)發(fā)人員比較容易適應(yīng)。在Git 遠(yuǎn)程倉(cāng)庫(kù)有一個(gè)主分支，開(kāi)發(fā)人員也在自己的本地克隆了一個(gè)完全一樣的分支，開(kāi)發(fā)人員可以在本地的分支上隨意的進(jìn)行代碼編寫(xiě)，測(cè)試。當(dāng)完成當(dāng)前開(kāi)發(fā)工作之后，可以直接push到遠(yuǎn)程主分支上。就算是有沖突也可以快速的解決。

中心倉(cāng)庫(kù)式工作流對(duì)于小型開(kāi)發(fā)團(tuán)隊(duì)比較適用，人員少，改動(dòng)也就相對(duì)比較少，出現(xiàn)沖突的幾率也要少很多。就算是有沖突，合并也不會(huì)有太大問(wèn)題。顯然這種工作方式卻不適合大型團(tuán)隊(duì)，幾個(gè)開(kāi)發(fā)組同時(shí)開(kāi)發(fā)維護(hù)一個(gè)項(xiàng)目，這樣代碼會(huì)非?；靵y，每個(gè)人的提交都會(huì)影響其他組開(kāi)發(fā)的工作。如果再有不同組的開(kāi)發(fā)任務(wù)上線時(shí)間點(diǎn)不一樣，那么就是一場(chǎng)災(zāi)難。

2.2 Feature Branch Workflow

基于Feature Branch WorkFlow 的Git工作流，其基于一個(gè)中心倉(cāng)庫(kù)，主分支（也可以是其他的生產(chǎn)代碼分支）代表了項(xiàng)目歷史。每次有新的開(kāi)發(fā)任務(wù)的時(shí)候，基于主分支新創(chuàng)建一個(gè)Feature分支，和當(dāng)前任務(wù)相關(guān)的代碼都提交的這個(gè)Feature分支。

當(dāng)開(kāi)發(fā)工作進(jìn)行到一定階段，就可以提一個(gè)Pull Request代主分支，這個(gè)時(shí)候就可以讓同事去Review自己的代碼了。此時(shí)Review階段可能會(huì)有一些小問(wèn)題，或者同事給出了更好的建議，我們都可以針對(duì)性的修改代碼。

最后讓測(cè)試等工作都完成之后，就可以將Feature 分支合并到主分支上。最終測(cè)試完成之后就可以部署到生產(chǎn)上面。之后Feature分支可以視情況刪除，或者保留一段時(shí)間之后再刪除。

2.3 GitFlow WorkFlow

GitFlow WorkFlow是一種比較經(jīng)典的工作模式。

其主要有如下的一些分支協(xié)作。

Main/Master Branch （主分支）：維護(hù)著項(xiàng)目的歷史記錄，會(huì)記錄每一次上線的標(biāo)簽，并且可以看到每一次上線的一些新特性等。

Develop Branch （開(kāi)發(fā)分支）：基于主分支，主要是為了下一次上線所使用的開(kāi)發(fā)分支，可以接受Feature分支的Pull Request。當(dāng)所有的新特性都已經(jīng)合并完畢，那么就創(chuàng)建。

Release Branch （部署分支）：當(dāng)開(kāi)發(fā)分支已經(jīng)合并了足夠的特性分支代碼之后，會(huì)創(chuàng)建一個(gè)Release分支。此時(shí)Release分支不會(huì)接受任何Feature分支的Pull Request，僅接受一些Bug fix的Pull Request。Release分支部署上線之后，測(cè)試全部通過(guò)后會(huì)將代碼合并到Develop 分支和主分支。

Feature Branch （特性分支）：一般會(huì)基于開(kāi)發(fā)分支創(chuàng)建出一條針對(duì)某個(gè)功能的分支，開(kāi)發(fā)人員會(huì)基于這條分支進(jìn)行開(kāi)發(fā)和單元測(cè)試的工作，當(dāng)本Feature開(kāi)發(fā)完成之后。會(huì)將代碼合并到Develop分支上，之后可以選擇適時(shí)刪除次分支。

Hotfix Branch （修補(bǔ)分支）：針對(duì)與線上出現(xiàn)的緊急問(wèn)題，從主分支，也就是上一次上線的標(biāo)簽出創(chuàng)建一個(gè)Hotfix 分支。當(dāng)問(wèn)題解決之后，可能會(huì)有一次緊急的上線來(lái)解決之前發(fā)現(xiàn)的問(wèn)題。當(dāng)問(wèn)題解決之后，會(huì)將代碼合并到主分支，和開(kāi)發(fā)分支。以便下一次上線也會(huì)包含本次的緊急修復(fù)代碼。

Support Branch （備用支撐分支）：這個(gè)分支的應(yīng)用比較靈活，有時(shí)候如果項(xiàng)目上線的時(shí)候基于各種可能性, (比如某個(gè)依賴的系統(tǒng)上線失敗，或者其他不必要的特性上線失敗) 可能會(huì)需要準(zhǔn)備多個(gè)版本，那么Support Branch 就可以作為一條備用分支來(lái)使用。這個(gè)分支可以根據(jù)項(xiàng)目的實(shí)際情況來(lái)看是否需要使用！

各個(gè)Branch的示例關(guān)系可以看下圖

我們也可以使用git flow 的一些命令來(lái)使用這個(gè)工作模式，會(huì)有一些既有的命令，使用起來(lái)會(huì)比較規(guī)范，但是也會(huì)有一定復(fù)雜，項(xiàng)目中可以根據(jù)實(shí)際情況使用！

git flow 相關(guān)的一些命令

2.4 Forking Workflow

Forking WorkFlow 相對(duì)與上面的幾種協(xié)同工作方式有較大的不同。

其主要 公共遠(yuǎn)程倉(cāng)庫(kù) ， 私人遠(yuǎn)程倉(cāng)庫(kù) ，和 本地倉(cāng)庫(kù) 。

開(kāi)發(fā)人員一般會(huì)從公共遠(yuǎn)程倉(cāng)庫(kù)Fork一份完全一樣的代碼倉(cāng)庫(kù)到自己的 私人遠(yuǎn)程倉(cāng)庫(kù) 。對(duì)于私人遠(yuǎn)程倉(cāng)庫(kù)來(lái)說(shuō)，開(kāi)發(fā)人員是擁有者，擁有所有的權(quán)限。開(kāi)發(fā)人員可以在本地倉(cāng)庫(kù)提交之后隨時(shí)push到自己的私人遠(yuǎn)程倉(cāng)庫(kù)，隨時(shí)進(jìn)行Revert、Reset、Rebase等操作。

公共遠(yuǎn)程倉(cāng)庫(kù)為項(xiàng)目的組織官方倉(cāng)庫(kù)，保留有不同的分支，以及標(biāo)簽等?？梢杂伤饺诉h(yuǎn)程倉(cāng)庫(kù)提交Pull Request到公共遠(yuǎn)程倉(cāng)庫(kù)的某個(gè)分支，待同事或者一些Owner Review過(guò)之后，就可以合并到公共倉(cāng)庫(kù)。

Forking WorkFlow 也是比較推薦的一種方式，開(kāi)發(fā)人員push代碼之后，可以隨時(shí)在自己的提交基礎(chǔ)之上進(jìn)行Rebase操作，合并之前的許多提交，這樣提交歷史比較整潔，同時(shí)Review也比較方便。

3 Git 常見(jiàn)問(wèn)題及處理方法以及建議。

1. 使用Github合并PullRequest的時(shí)候，如果代碼有沖突，通過(guò)網(wǎng)頁(yè)解決沖突合并之后。Github會(huì)進(jìn)行 雙向合并 。
2. 關(guān)于Git協(xié)作，可以考慮Git Flow與Feature flow 還有Forking flow結(jié)合使用，F(xiàn)orking Flow有利于整理提交歷史，F(xiàn)eature branch對(duì)于代碼的管理比較友善。
3. 本地的代碼跑完一次測(cè)試的時(shí)候就可以提交一版，然后在需要push的時(shí)候在rebase合并一次。盡量完善自己的commit信息，寫(xiě)好每一次提交記錄。
4. 如果merge有問(wèn)題可以使用git merge --abort 解除merge， 然后再重新合并。
5. 多使用Git命令行來(lái)進(jìn)行日常的提交等工作，有助于更好的理解Git的工作原理，這樣在不同的IDE上都能比較容易的使用Git插件了。