版本控制工具

版本控制的起源

  • 現(xiàn)在的軟件項目通常是由一個研發(fā)小組共同分析,設計,編碼,維護以及測試的
  • 針對團隊開發(fā)需要解決以下問題:
    • 備份多個版本,費空間,費時間
    • 難以恢復至以前正確版本
    • 難以解決代碼沖突困難
    • 難以追溯問題代碼的修改人和修改時間
    • 無法進行權(quán)限控制
    • 項目版本發(fā)布困難
  • 源代碼管理工具就是為了解決上述問題應運而生的

版本控制

  • 是維護工程藍圖的標準做法,能追蹤工程藍圖從誕生一直到定案的過程,是一種記錄若干文件內(nèi)容變化,以便將來查閱特定版本修訂情況的系統(tǒng)
    • 如果是團隊開發(fā),使用版本控制是強制性的
    • 如果是單人開發(fā),也強烈建議現(xiàn)在就開始使用版本控制
  • 使用版本控制
    • 不會對現(xiàn)有工作造成任何損害
    • 不會增加工作量
    • 添加新的功能拓展時,會變得更加容易

常見版本控制工具

  • CVS開啟版本控制之門
  • SVN集中式版本控制之王者
    • 又稱subversion,是CVS的接班人,是一款集中式源代碼管理工具,曾經(jīng)是絕大多數(shù)開源軟件的代碼管理工具,前幾年在國內(nèi)軟件企業(yè)使用最為普遍
  • GIT分布式版本控制之偉大作品
    • 一款分布式源代碼管理工具,目前國內(nèi)企業(yè)幾乎都已經(jīng)從SVN到GIT的轉(zhuǎn)換
  • 分布式與集中式最大的區(qū)別
    • 在集中式下,開發(fā)者只能將代碼提交到服務器,在分布式下,開發(fā)者可以在本地提交
    • 在集中式下,只有遠程服務器上有代碼數(shù)據(jù)庫,在分布式下,每個開發(fā)者機器上都有一個代碼數(shù)據(jù)庫
Git和SVN的簡單對比
  • 速度
    • 在很多情況下,git的速度遠遠比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指針: 用于指向當前分支

GIT單人開發(fā)

準備工作(只做一次)
  1. 創(chuàng)建一個工作區(qū)
  2. 在工作區(qū)中打開git終端
  3. 通過git init指令,初始化版本庫
  4. 通過git config user.name "姓名" / git config user.email "郵箱"設置用戶名和郵箱
  5. 通過git config -l查看設置情況
開發(fā)階段
  1. 編寫代碼
  2. 通過git add 文件名 / git add .添加到版本庫的暫緩區(qū)中
  3. 通過git commit -m"說明"將暫緩區(qū)的文件添加到HEAD指針指向的分支中(默認只有一個分支,master分支,也稱之為主分支)

注意點

  1. 不是寫一句代碼就add commit一次,應該是完成一個功能后在add commit
  2. commit時-m注釋一定要認真編寫,與當前提交內(nèi)容保存一致
單人使用Git管理項目好處
  1. 可以通過git status查看哪些文件沒有被管理,修改了哪些文件,紅色(沒有被管理或者被修改了),綠色(在暫緩區(qū))
  2. 可以通過git diff查看具體修改了哪些代碼
  3. 可以通過git log / git reflog查看項目演變歷史
  4. 可以通過git reset --hard 版本號在任意版本之間切換
  5. 無需備份多個文件,每次commit提交Git會自動備份

多人開發(fā)

在遠程服務器上創(chuàng)建一個共享版本庫
  1. 項目負責人打開遠程的服務器,然后創(chuàng)建一個工作區(qū)
  2. 在遠程服務器上打開工作區(qū),在工作區(qū)中打開Git終端工具
  3. 在Git終端工具中輸入 git init --bare
  4. 經(jīng)過以上幾步,就代表遠程服務器上的共享版本庫已經(jīng)創(chuàng)建好了
開發(fā)人員下載遠程版本庫
  1. 開發(fā)人員在自己的電腦上打開Git終端工具
  2. 從遠程服務器上下載當前項目的共享版本庫 git clone 遠程服務器共享版本庫的地址 (和單人開發(fā)使用Git的區(qū)別:單人開發(fā)是自己創(chuàng)建版本庫,而多人開發(fā)是從遠程服務器下載版本庫)
開發(fā)階段(和單人開發(fā)一樣)
  1. 設置用戶名和郵箱
  2. 編寫代碼
  3. git add . 添加到暫緩區(qū)
  4. git commit -m 添加到HEAD指針指向的分支
  5. 注意點
    • commit是將編寫好的代碼提交到本地的版本庫,所以其他的開發(fā)人員是拿不到我們提交的代碼的
    • 如果想讓其他開發(fā)人員也能拿到我們提交的代碼,還必須將編寫好的代碼提交到遠程的服務器
    • 通過 git push 將代碼提交到遠程的服務器
    • 其他開發(fā)人員只需要通過 git pull 就可以拿到更新的代碼了
多人開發(fā)使用Git注意點
  1. 不能將不能運行的代碼提交到本地和遠程服務器
  2. 如果服務器上有其他開發(fā)人員的更新內(nèi)容,那么我們不能直接通過push將我們的代碼提交到服務器
  3. 如果服務器上有其他開發(fā)人員更新的內(nèi)容,我們必須先將其他開發(fā)人員更新的內(nèi)容更新到本地之后才能通過push提交我們的內(nèi)容
  4. 如果我們更新的內(nèi)容和其他同事更新的內(nèi)容有沖突(修改了同一文件的同一行代碼),這個時候需要我們自己手動修改沖突,修改完沖突后才能將代碼提交到遠程服務器
  5. 只要開發(fā)完了一個功能就要立即提交代碼,因為在企業(yè)中誰后提交誰就負責解決沖突,誰的工作量就會變大

Git分支使用

如何查看有多少個分支
  • 通過git branch指令就可以查看當前的版本庫中有多少個分支
  • 如果當前的版本庫是空的,無法查看
  • 如果通過git branch指令查看當前的版本庫中有多少個分支,輸出的內(nèi)容中哪一個分支前面有*號就代表當前的HEAD指針指向哪一個分支,我們提交的代碼就會提交到指向的分支中
如何創(chuàng)建一個分支
  • 通過git branch 分支名稱 來創(chuàng)建一個新的分支
  • 在哪個分支中創(chuàng)建了新的分支,那么創(chuàng)建出來的新的分支就會繼承當前分支的所有狀態(tài)
    • 例如
    • 在master分支中做了兩個操作,然后在master分支中創(chuàng)建了Dev分支,那么創(chuàng)建出來的Dev分支就會繼承master分支中的這兩個操作
  • 一旦分支被創(chuàng)建出來之后,分支就是獨立的,分支之間不會相互影響
如何切換分支
  • 通過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 分支名稱 來刪除遠程服務器的分支

Gitflow工作流程

準備階段
  1. 初始化遠程工作區(qū)和共享版本庫
  2. 項目經(jīng)理初始化項目,并在master定制標記
  3. 將master分支提交到遠程服務器
  4. 項目經(jīng)理基于master分支創(chuàng)建Develop分支
  5. 項目經(jīng)理將新建的分支提交到遠程的服務器
  6. 項目經(jīng)理給開發(fā)人員分配工作
開發(fā)階段
  1. 開發(fā)人員基于develop分支創(chuàng)建功能分支
  2. 開發(fā)人員在自己的分支上add commit push
  3. 開發(fā)完成告訴項目經(jīng)理,由項目經(jīng)理審核代碼并合并到develop分支
準備上線階段
  1. 項目經(jīng)理基于develop分支創(chuàng)建release分支
  2. 測試人員獲取release分支代碼進行測試
  3. 發(fā)現(xiàn)bug由開發(fā)人員基于release分支創(chuàng)建bugfix分支進行修復
  4. 開發(fā)人員修復完成后重新合并到release分支
  5. 項目經(jīng)理將測試和修復完所有bug的最終代碼合并到master分支和develop分支
正式上線階段
  1. 項目經(jīng)理給master分支制定標記
  2. 項目經(jīng)理將標記提交到遠程服務器
  3. 項目完成上線
上線之后
  1. 項目上線后如果出現(xiàn)了緊急bug
  2. 基于master分支創(chuàng)建hotfix分支,在該分支上修復bug
  3. 修復完成后重新合并到master分支和develop分支
  4. 項目經(jīng)理在master分支定制標記
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容