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

1 Git 常用的超級實用命令

1.1 與倉庫相關(guān)的操作

克隆代碼倉庫到本地，開發(fā)必用

git clone  < url >

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

git remote -v

添加遠(yuǎn)程倉庫

git remote add < name >< url >

更新遠(yuǎn)程倉庫地址

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

拉取遠(yuǎn)程倉庫

git pull < remoteName >< localBranchName >

推送本地倉庫到遠(yuǎn)程倉庫，默認(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)程倉庫名 >/< 遠(yuǎn)程分支名 >
git branch -b < 本地分支名 > < 遠(yuǎn)程倉庫名 >/< 遠(yuǎn)程分支名 >

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

git fetch < 遠(yuǎn)程倉庫名 > < 遠(yuǎn)程分支名 >:< 本地分支名 >

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

git checkout -b < name >

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

git push origin < name >

刪除遠(yuǎn)程分支

git push origin:heads/< name >
也可以push一個空的本地分支，那么也將刪除遠(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)程倉庫

git push origin < tagName >

刪除遠(yuǎn)程Tag

git push origin:refs/tags/< tagName >

1.4 git 提交相關(guān)

先add 然后在提交，不過add大多時候利用開發(fā)工具來做比較方便。

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

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

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

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

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

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

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

--soft 提交不改變變，將HEAD指向某commit id，有點像checkout

1.5 合并

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

git merge

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

git merge fixes enhancements

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

git cherry-pick < commit id >

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

git rebase -i 4e08572

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

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

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

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

然后看到rebase成功

e

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

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

2.2 Feature Branch Workflow

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

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

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

2.3 GitFlow WorkFlow

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

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

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

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

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

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

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

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

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

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

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

2.4 Forking Workflow

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

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

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

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

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

3 Git 常見問題及處理方法以及建議。

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