這篇文章是針對git版本控制和工作流的總結(jié),如果有些朋友之前還沒使用過git,對git的基本概念和命令不是很熟悉券犁,可以從以下基本教程入手:
基本概念
Git是什么油吭?
Git是分布式版本控制系統(tǒng),與SVN類似的集中化版本控制系統(tǒng)相比毡琉,集中化版本控制系統(tǒng)雖然能夠令多個團隊成員一起協(xié)作開發(fā),但有時如果中央服務(wù)器宕機的話妙色,誰也無法在宕機期間提交更新和協(xié)同開發(fā)桅滋。甚至有時,中央服務(wù)器磁盤故障身辨,恰巧又沒有做備份或備份沒及時丐谋,那就可能有丟失數(shù)據(jù)的風險。
但Git是分布式的版本控制系統(tǒng)煌珊,客戶端不只是提取最新版本的快照号俐,而且將整個代碼倉庫鏡像復制下來。如果任何協(xié)同工作用的服務(wù)器發(fā)生故障了定庵,也可以用任何一個代碼倉庫來恢復吏饿。而且在協(xié)作服務(wù)器宕機期間踪危,你也可以提交代碼到本地倉庫,當協(xié)作服務(wù)器正常工作后猪落,你再將本地倉庫同步到遠程倉庫贞远。
為什么要使用Git
- 能夠?qū)ξ募?strong>版本控制和多人協(xié)作開發(fā)
- 擁有強大的分支特性,所以能夠靈活地以不同的工作流協(xié)同開發(fā)
- 分布式版本控制系統(tǒng)笨忌,即使協(xié)作服務(wù)器宕機兴革,也能繼續(xù)提交代碼或文件到本地倉庫,當協(xié)作服務(wù)器恢復正常工作時蜜唾,再將本地倉庫同步到遠程倉庫杂曲。
- 當團隊中某個成員完成某個功能時,通過pull request操作來通知其他團隊成員袁余,其他團隊成員能夠review code后再合并代碼擎勘。
Git有哪些特性
- 文件三種狀態(tài)(modified, staged, committed)
- 直接記錄快照,而非差異比較
- 多數(shù)操作僅添加操作
- 近乎所有操作都是本地執(zhí)行
- 時刻保持數(shù)據(jù)完整性
有關(guān)以上特性的詳細解釋颖榜,請查看Pro git的git基礎(chǔ)章節(jié)
Git基本工作流程
- 在git版本控制的目錄下修改某個文件
- 使用
git add
命令對修改后的文件快照棚饵,保存到暫存區(qū)域 - 使用
git commit
命令提交更新,將保存在暫存區(qū)域的文件快照永久轉(zhuǎn)儲到 Git 目錄中
Git基本技巧
- 自動補全
- Git 命令別名
關(guān)于具體如何使用自動補全和命名別名技巧掩完,請查看Pro git的技巧和竅門
Git版本控制
創(chuàng)建倉庫
- git init
- git clone
- git config
保存修改
- git add
- git commit
查看倉庫
- git status
- git log --oneline
撤銷修改
查看之前的commit
- git checkout <commit> <file>
- git checkout <commit>
- git checkout <branch>
撤銷公共修改
- git revert <commit>
撤銷本地修改
- git reset
- git clean
重寫Git歷史記錄
- git commit --amend
- git rebase
- git reflog
Git協(xié)作開發(fā)
分支
- git branch
- git checkout
- git merge
倉庫同步
- git remote
- git fetch
- git pull
- git push
Git工作流
由于git擁有強大的分支特性噪漾,它的工作流比較靈活而缺乏約束,于是參考Atlassian Git Tutorial的Comparing Workflows章節(jié)提供四種Git工作流:
- Centralized Workflow
- Feature Branch Workflow
- Gitflow Workflow
- Forking Workflow
以上工作流只是參考指南且蓬,而不是具體規(guī)則欣硼。你可以根據(jù)自己實際情況來選擇適合自己的工作流或微調(diào)來滿足自己的需要。
Centralized Workflow
過渡到分布式版本控制系統(tǒng)看起來像一個艱巨的任務(wù)恶阴,但如果你充分利用好git的話诈胜,你不必改變你既有的工作流,你的團隊可以采用與之前使用SVN一樣的方式來開發(fā)項目冯事。
如何工作
- 從遠程倉庫(central repository)克隆工程到本地倉庫(local repository) ---
git clone
- 在本地倉庫編輯文件和提交更新 ---
git add
和git commit
- fetch遠程倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面 ---
git fetch
和git rebase
或git pull --rebase
- push本地主分支(master branch)到遠程倉庫 ---
git push
管理沖突
何時發(fā)生沖突:在開發(fā)者發(fā)布它們功能之前焦匈,他們需要fetch遠程倉庫已更新的commit到本地倉庫和rebase到已更新的commit的上面。有時昵仅,本地提交與遠程提交會發(fā)生沖突缓熟,git會暫停rebase過程來讓你手動解決沖突。
如何解決沖突:你可以使用
git status
和git add
來手動解決合并時沖突摔笤。
Feature Branch Workflow
Feature Branch Workflow的主要思想就是在開發(fā)每個功能時都應(yīng)該創(chuàng)建一個獨立的分支而不只是使用主分支够滑。由于每個分支是獨立且互不影響,這就意味著主分支不會包含broken code籍茧,對持續(xù)集成環(huán)境是很有幫助的版述。
如何工作
- 仍然使用遠程倉庫(central repository)和主分支(master branch)仍記錄官方工程的歷史
- 開發(fā)者每次開發(fā)新功能時都創(chuàng)建一個新分支 ---
git checkout -b
- Feature branches應(yīng)該推送到遠程倉庫(central repository) ---
git push
- 發(fā)送pull request來請求管理員能否合并到主分支(master branch)
- 發(fā)布新功能到遠程倉庫(central repository)
Pull Request
Pull request是一種當開發(fā)者完成一個新功能后向其他團隊成員發(fā)送通知的機制梯澜。它的使用過程如下:
- 開發(fā)者可以通過Github或Bitbucket發(fā)送pull request
- 其他的團隊成員審查寞冯、討論和修改代碼
- 項目維護者合并新增功能分支到主分支(master branch)渴析,然后關(guān)閉pull request
Gitflow Workflow
Feature Branch Workflow是一種非常靈活的開發(fā)方式。對于一些規(guī)模比較大的團隊吮龄,最好就是給特定的分支賦予不同的角色俭茧。除了功能分支(feature branch),Gitflow Workflow還使用獨立的分支來準備發(fā)布(preparing)漓帚,維護(maintaining), 和記錄版本(recording releases)母债。下面我會逐個介紹這個幾個分支:Historical Branches、Feature Branches尝抖、Release Branches和Maintenance Branches毡们。
Historical Branches
- master分支保存官方發(fā)布歷史
- develop分支衍生出各個feature分支
Feature Branches
- feature分支使用develop分支作為它們的父類分支
- 當其中一個feature分支完成后,它會合并會develop分支
- feature分支應(yīng)該從不與master分支直接交互
Release Branches
- release分支主要用來清理釋放昧辽、測試和更新文檔
- 一旦develop分支獲得足夠的功能來發(fā)布時衙熔,你可以從develop衍生出一個release分支
- 一旦準備好上架,release合并到master分支并且標記一個版本號
- 另外搅荞,還需要合并回develop分支
Maintenance Branches
- maintenance分支用來快速給已發(fā)布產(chǎn)品修復bug或微調(diào)功能
- 它從master分支直接衍生出來
- 一旦完成修復bug红氯,它應(yīng)該合并回master分支和develop分支
- master應(yīng)該被標記一個新的版本號
標記Tags
使用兩個命令來給master分支標記版本號:
git tag -a 0.1 -m "Initial public release" master
git push origin master --tags
Forking Workflow
Forking Workflow與以上討論的工作流很不同咕痛,一個很重要的區(qū)別就是它不只是多個開發(fā)共享一個遠程倉庫(central repository),而是每個開發(fā)者都擁有一個獨立的服務(wù)端倉庫塞栅。也就是說每個contributor都有兩個倉庫:本地私有的倉庫和遠程共享的倉庫。
Forking Workflow這種工作流主要好處就是每個開發(fā)者都擁有自己的遠程倉庫腔丧,可以將提交的commits推送到自己的遠程倉庫构蹬,但只有工程維護者才有權(quán)限push提交的commits到官方的倉庫悔据,其他開發(fā)者在沒有授權(quán)的情況下不能push。Github很多開源項目都是采用Forking Workflow工作流科汗。
如何工作
- 在服務(wù)器上有一個官方公共的倉庫
- 開發(fā)者fork官方倉庫來創(chuàng)建它的拷貝藻烤,然后存放在服務(wù)器上
- 當開發(fā)者準備好發(fā)布本地的commit時,他們push commit到他們自己的公共倉庫
- 在自己的公共倉庫發(fā)送一個pull request到官方倉庫
- 維護者pull貢獻者的commit到他自己的本地倉庫
- 審查代碼確保它不會破壞工程头滔,合并它到本地倉庫的master分支
- push master分支到服務(wù)器上的官方倉庫
- 其他開發(fā)者應(yīng)該同步官方倉庫。