版本控制的起源
- 現(xiàn)在的軟件項目通常是由一個研發(fā)小組共同分析,設(shè)計,編碼,維護(hù)以及測試的
- 針對團(tuán)隊開發(fā)需要解決以下問題:
- 備份多個版本,費(fèi)空間,費(fèi)時間
- 難以恢復(fù)至以前正確版本
- 難以解決代碼沖突困難
- 難以追溯問題代碼的修改人和修改時間
- 無法進(jìn)行權(quán)限控制
- 項目版本發(fā)布困難
- 源代碼管理工具就是為了解決上述問題應(yīng)運(yùn)而生的
版本控制
- 是維護(hù)工程藍(lán)圖的標(biāo)準(zhǔn)做法,能追蹤工程藍(lán)圖從誕生一直到定案的過程,是一種記錄若干文件內(nèi)容變化,以便將來查閱特定版本修訂情況的系統(tǒng)
- 如果是團(tuán)隊開發(fā),使用版本控制是強(qiáng)制性的
- 如果是單人開發(fā),也強(qiáng)烈建議現(xiàn)在就開始使用版本控制
- 使用版本控制
- 不會對現(xiàn)有工作造成任何損害
- 不會增加工作量
- 添加新的功能拓展時,會變得更加容易
常見版本控制工具
- CVS開啟版本控制之門
- SVN集中式版本控制之王者
- 又稱subversion,是CVS的接班人,是一款
集中式源代碼管理工具,曾經(jīng)是絕大多數(shù)開源軟件的代碼管理工具,前幾年在國內(nèi)軟件企業(yè)使用最為普遍
- 又稱subversion,是CVS的接班人,是一款
- GIT分布式版本控制之偉大作品
- 一款
分布式源代碼管理工具,目前國內(nèi)企業(yè)幾乎都已經(jīng)從SVN到GIT的轉(zhuǎn)換
- 一款
- 分布式與集中式最大的區(qū)別
- 在集中式下,開發(fā)者只能將代碼提交到服務(wù)器,在分布式下,開發(fā)者可以在本地提交
- 在集中式下,只有遠(yuǎn)程服務(wù)器上有代碼數(shù)據(jù)庫,在分布式下,每個開發(fā)者機(jī)器上都有一個代碼數(shù)據(jù)庫
Git和SVN的簡單對比
- 速度
- 在很多情況下,git的速度遠(yuǎn)遠(yuǎn)比SVN快
- 結(jié)構(gòu)
- SVN是集中式管理,git是分布式管理
- 其他
- SVN使用分支比較笨拙,git可以輕松擁有無限個分支
- SVN必須聯(lián)網(wǎng)才能正常工作,git支持本地版本控制工作
- 舊版本的SVN會在每一個目錄置放一個.svn,git只會在根目錄擁有一個.git
Git簡介
- GIT是一款自由和開源的
分布式版本控制系統(tǒng),用于敏捷高效地處理任何或小或大的項目 - 在世界上所有的分布式版本控制工具中,git是最快,最簡單,最流行的,是Linux之父李納斯的第二個偉大作品
Git工作原理
-
工作區(qū)(Working Directory): 倉庫文件夾里面,除了
.git目錄以外的內(nèi)容 -
版本庫(Repository): .git目錄,用于儲存記錄版本信息
- 版本庫中的暫緩區(qū)(stage)
- 版本庫中的分支(master): git自動創(chuàng)建的第一個分支
- 版本庫中的HEAD指針: 用于指向當(dāng)前分支
GIT單人開發(fā)
準(zhǔn)備工作(只做一次)
- 創(chuàng)建一個工作區(qū)
- 在工作區(qū)中打開git終端
- 通過git init指令,初始化版本庫
- 通過git config user.name "姓名" / git config user.email "郵箱"設(shè)置用戶名和郵箱
- 通過git config -l查看設(shè)置情況
開發(fā)階段
- 編寫代碼
- 通過git add 文件名 / git add .添加到版本庫的暫緩區(qū)中
- 通過git commit -m"說明"將暫緩區(qū)的文件添加到HEAD指針指向的分支中(默認(rèn)只有一個分支,master分支,也稱之為主分支)
注意點(diǎn)
- 不是寫一句代碼就add commit一次,應(yīng)該是完成一個功能后在add commit
- commit時-m注釋一定要認(rèn)真編寫,與當(dāng)前提交內(nèi)容保存一致
單人使用Git管理項目好處
- 可以通過git status查看哪些文件沒有被管理,修改了哪些文件,紅色(沒有被管理或者被修改了),綠色(在暫緩區(qū))
- 可以通過git diff查看具體修改了哪些代碼
- 可以通過git log / git reflog查看項目演變歷史
- 可以通過git reset --hard 版本號在任意版本之間切換
- 無需備份多個文件,每次commit提交Git會自動備份
多人開發(fā)
在遠(yuǎn)程服務(wù)器上創(chuàng)建一個共享版本庫
- 項目負(fù)責(zé)人打開遠(yuǎn)程的服務(wù)器,然后創(chuàng)建一個工作區(qū)
- 在遠(yuǎn)程服務(wù)器上打開工作區(qū),在工作區(qū)中打開Git終端工具
- 在Git終端工具中輸入 git init --bare
- 經(jīng)過以上幾步,就代表遠(yuǎn)程服務(wù)器上的共享版本庫已經(jīng)創(chuàng)建好了
開發(fā)人員下載遠(yuǎn)程版本庫
- 開發(fā)人員在自己的電腦上打開Git終端工具
- 從遠(yuǎn)程服務(wù)器上下載當(dāng)前項目的共享版本庫 git clone 遠(yuǎn)程服務(wù)器共享版本庫的地址 (和單人開發(fā)使用Git的區(qū)別:單人開發(fā)是自己創(chuàng)建版本庫,而多人開發(fā)是從遠(yuǎn)程服務(wù)器下載版本庫)
開發(fā)階段(和單人開發(fā)一樣)
- 設(shè)置用戶名和郵箱
- 編寫代碼
- git add . 添加到暫緩區(qū)
- git commit -m 添加到HEAD指針指向的分支
- 注意點(diǎn)
- commit是將編寫好的代碼提交到本地的版本庫,所以其他的開發(fā)人員是拿不到我們提交的代碼的
- 如果想讓其他開發(fā)人員也能拿到我們提交的代碼,還必須將編寫好的代碼提交到遠(yuǎn)程的服務(wù)器
- 通過 git push 將代碼提交到遠(yuǎn)程的服務(wù)器
- 其他開發(fā)人員只需要通過 git pull 就可以拿到更新的代碼了
多人開發(fā)使用Git注意點(diǎn)
- 不能將不能運(yùn)行的代碼提交到本地和遠(yuǎn)程服務(wù)器
- 如果服務(wù)器上有其他開發(fā)人員的更新內(nèi)容,那么我們不能直接通過push將我們的代碼提交到服務(wù)器
- 如果服務(wù)器上有其他開發(fā)人員更新的內(nèi)容,我們必須先將其他開發(fā)人員更新的內(nèi)容更新到本地之后才能通過push提交我們的內(nèi)容
- 如果我們更新的內(nèi)容和其他同事更新的內(nèi)容有沖突(修改了同一文件的同一行代碼),這個時候需要我們自己手動修改沖突,修改完沖突后才能將代碼提交到遠(yuǎn)程服務(wù)器
- 只要開發(fā)完了一個功能就要立即提交代碼,因為在企業(yè)中誰后提交誰就負(fù)責(zé)解決沖突,誰的工作量就會變大
Git分支使用
如何查看有多少個分支
- 通過git branch指令就可以查看當(dāng)前的版本庫中有多少個分支
- 如果當(dāng)前的版本庫是空的,無法查看
- 如果通過git branch指令查看當(dāng)前的版本庫中有多少個分支,輸出的內(nèi)容中哪一個分支前面有*號就代表當(dāng)前的HEAD指針指向哪一個分支,我們提交的代碼就會提交到指向的分支中
如何創(chuàng)建一個分支
- 通過git branch 分支名稱 來創(chuàng)建一個新的分支
- 在哪個分支中創(chuàng)建了新的分支,那么創(chuàng)建出來的新的分支就會繼承當(dāng)前分支的所有狀態(tài)
- 例如
- 在master分支中做了兩個操作,然后在master分支中創(chuàng)建了Dev分支,那么創(chuàng)建出來的Dev分支就會繼承master分支中的這兩個操作
- 一旦分支被創(chuàng)建出來之后,分支就是獨(dú)立的,分支之間不會相互影響
如何切換分支
- 通過git switch 分支名稱 來修改HEAD指針的指向
- 只要HEAD指針的指向發(fā)生了改變,那么commit的代碼就會發(fā)生改變
- HEAD指針指向誰commit提交的代碼就提交到哪個分支中
如何合并分支
- 可以通過git merge 分支名稱 來合并分支
- 例如
- 在master分支中執(zhí)行 git merge Dev就代表需要將Dev分支中的代碼都合并到master分支中
- 在Dev分支中執(zhí)行 git merge master就代表需要將master分支中的代碼都合并到Dev分支中
如何刪除分支
- 通過git branch -d 分支名稱 來刪除本地的分支
- 通過git push origin --delete 分支名稱 來刪除遠(yuǎn)程服務(wù)器的分支
Gitflow工作流程
準(zhǔn)備階段
- 初始化遠(yuǎn)程工作區(qū)和共享版本庫
- 項目經(jīng)理初始化項目,并在master定制標(biāo)記
- 將master分支提交到遠(yuǎn)程服務(wù)器
- 項目經(jīng)理基于master分支創(chuàng)建Develop分支
- 項目經(jīng)理將新建的分支提交到遠(yuǎn)程的服務(wù)器
- 項目經(jīng)理給開發(fā)人員分配工作
開發(fā)階段
- 開發(fā)人員基于develop分支創(chuàng)建功能分支
- 開發(fā)人員在自己的分支上add commit push
- 開發(fā)完成告訴項目經(jīng)理,由項目經(jīng)理審核代碼并合并到develop分支
準(zhǔn)備上線階段
- 項目經(jīng)理基于develop分支創(chuàng)建release分支
- 測試人員獲取release分支代碼進(jìn)行測試
- 發(fā)現(xiàn)bug由開發(fā)人員基于release分支創(chuàng)建bugfix分支進(jìn)行修復(fù)
- 開發(fā)人員修復(fù)完成后重新合并到release分支
- 項目經(jīng)理將測試和修復(fù)完所有bug的最終代碼合并到master分支和develop分支
正式上線階段
- 項目經(jīng)理給master分支制定標(biāo)記
- 項目經(jīng)理將標(biāo)記提交到遠(yuǎn)程服務(wù)器
- 項目完成上線
上線之后
- 項目上線后如果出現(xiàn)了緊急bug
- 基于master分支創(chuàng)建hotfix分支,在該分支上修復(fù)bug
- 修復(fù)完成后重新合并到master分支和develop分支
- 項目經(jīng)理在master分支定制標(biāo)記
