歸納整理Git版本控制學習指南

推薦學習：《》

版本控制的起源

• 現在的軟體專案通常是由一個研發小組共同分析、設計、編碼、維護以及測試的
• 針對團隊開發需要解決以下問題：
  • 備份多個版本，費空間，費時間
  • 難於恢復至以前正確版本
  • 難以解決程式碼衝突困難
  • 難於追溯問題程式碼的修改人和修改時間
  • 無法進行許可權控制
  • 專案版本釋出困難
• 原始碼管理工具就是為了解決上述問題應運而生的

版本控制(Revision Control)

• 是維護工程藍圖的標準做法，能追蹤工程藍圖從誕生一直到定案的過程。是一種記錄若干檔案內容變化，以便將來查閱特定版本修訂情況的系統
  • 如果是團隊開發，使用版本控制是強制性的！
  • 如果是單人開發，也強烈建議現在就開始使用版本控制!

• 使用版本控制可以：
  • 不會對現有工作造成任何損害
  • 不會增加工作量
  • 新增新的功能拓展時，會變得更加容易

常見版本控制工具

• CVS 開啟版本控制之門
  • CVS 1990年誕生，遠古時代的主流原始碼管理工具
• SVN 集中式版本控制之王者
  • SVN:又稱subversion，是CVS的接班人，是一款集中式原始碼管理工具。曾經是絕大多數開源軟體的程式碼管理工具(google code)，前幾年在國內軟體企業使用最為普遍
• GIT 分散式版本控制之偉大作品
  • GIT:一款分散式原始碼管理工具，目前國內企業幾乎都已經完成了從SVN到GIT的轉換

• 集中式原始碼管理
  

• 分散式原始碼管理
  

• 分散式和集中式的最大區別在於：

  • 在集中式下, 開發者只能將程式碼提交到伺服器, 在分散式下, 開發者可以本地提交
  • 在集中式下, 只有遠端伺服器上有程式碼資料庫, 在分散式下, 每個開發者機器上都有一個程式碼資料庫

• SVN(集中式)
  

• GIT(分散式)
  

Git和 SVN 的簡單對比

• 速度
  • 在很多情況下，git的速度遠遠比SVN快
• 結構
  • SVN是集中式管理，git是分散式管理
• 其他
  • SVN使用分支比較笨拙，git可以輕鬆擁有無限個分支
  • SVN必須聯網才能正常工作，git支援本地版本控制工作
  • 舊版本的SVN會在每一個目錄置放一個.svn，git只會在根目錄擁有一個.git

GIT簡介

• GIT是一款自由和開源的分散式版本控制系統，用於敏捷高效地處理任何或小或大的專案
• 在世界上所有的分散式版本控制工具中，git是最快、最簡單、最流行的
• 是Linux之父李納斯的第二個偉大作品
  • 2005年由於BitKeeper軟體公司對Linux社群停止了免費使用權。
  • Linus為了輔助Linux核心的開發(管理原始碼),迫不得己自己開發了一個分散式版本控制工具，從而Git誕生了

GIT工作原理

• 如果想學好GIT必須先了解GIT的工作原理
• 工作區(Working Directory): 倉庫資料夾裡面, 除了.git目錄以外的內容
• 版本庫(Repository):.git目錄, 用於儲存記錄版本資訊
  • 版本庫中的暫緩區(staga):
  • 版本庫中的分支(master): git自動建立的第一個分支
  • 版本庫中的**HEAD指標:**用於指向當前分支

• git add和git commit命名作用
  • git add: 把檔案修改新增到暫緩區
  • 
  • git commit: 把暫緩區的所有內容提交到當前HEAD指標指向的分支
  • 

GIT使用環境

• 多人開發時需要一個共用版本庫, 單人開發初始化一個本地庫即可
• 共用版本庫的形式:
  • 本地共用庫: 資料夾/U盤/硬碟
  • 遠端共用庫: 自己搭建git伺服器/託管到第三方平臺(github/oschina等)
• 無論是單人開發還是多人開發, 使用者端都可以使用命令列或者圖形化介面使用git

GIT命令-個人開發

• git help ：git指令幫助手冊

  • 檢視其他指令的做法：git help 其他指令

• git init : 倉庫初始化(個人倉庫)

  • 倉庫檔案目錄

  HEAD:	指向當前分支的一個提交
  description:	專案的描述資訊
  config:	專案的設定資訊
  info/:	裡面有一個exclude檔案，指定本專案要忽略的檔案
  objects/:	Git物件庫(commit/tree/blob/tag)
  refs/:	標識每個分支指向哪個提交
  hooks/:	預設的hook指令碼

• GIT設定設定資訊

  • 設定使用者名稱：git config user.name "使用者名稱"（用於跟蹤修改記錄）
  • 設定郵箱：git config user.email "郵箱"（用於多人開發間的溝通）
  • git config -l : 檢視設定資訊
  • git config -e : 編輯設定資訊

• git status ：查檔案的狀態

  • 檢視某個檔案的狀態：git status 檔名
  • 檢視當前路徑所有檔案的狀態：git status

• git add ：將工作區的檔案儲存到暫緩區

  • 儲存某個檔案到暫緩區：git add 檔名
  • 儲存當前路徑的所有檔案到暫緩區：git add .（注意，最後是一個點 . ）

• git commit：將暫緩區的檔案提交到當前分支

  • 提交某個檔案到分支：git commit -m 」註釋」 檔名
  • 儲存當前路徑的所有檔案到分支：git commit -m 」註釋」

• git log ：檢視檔案的修改紀錄檔

  • 檢視某個檔案的修改紀錄檔：git log 檔名
  • 檢視當前路徑所有檔案的修改紀錄檔：git log
  • 用一行的方式檢視簡單的紀錄檔資訊：git log ––pretty=oneline
  • 檢視最近的N次修改：git log –N（N是一個整數）

• git diff ：檢視檔案最新改動的地方

  • 檢視某個檔案的最新改動的地方：git diff 檔名
  • 檢視當前路徑所有檔案最新改動的地方：git diff

• git reflog ：檢視分支參照記錄（能夠檢視所有的版本號）

• git rm：刪除檔案（刪完之後要進行commit操作，才能同步到版本庫）

• git reset：版本回退（建議加上––hard引數，git支援無限次後悔）

  • 回退到上一個版本：git reset ––hard HEAD^
  • 回退到上上一個版本：git reset ––hard HEAD^^
  • 回退到上N個版本：git reset ––hard HEAD~N（N是一個整數）
  • 回退到任意一個版本：git reset ––hard 版本號（版本號用7位即可）

• Git忽略提交規則 - .gitignore設定

  • 別看了, 你想要的都在這企業開發專用連結

#               表示此為註釋,將被Git忽略*.a             表示忽略所有 .a 結尾的檔案!lib.a          表示但lib.a除外/TODO           表示僅僅忽略專案根目錄下的 TODO 檔案，不包括 subdir/TODO
build/          表示忽略 build/目錄下的所有檔案，過濾整個build資料夾；
doc/*.txt       表示會忽略doc/notes.txt但不包括 doc/server/arch.txt
 
bin/:           表示忽略當前路徑下的bin資料夾，該資料夾下的所有內容都會被忽略，不忽略 bin 檔案
/bin:           表示忽略根目錄下的bin檔案
/*.c:           表示忽略cat.c，不忽略 build/cat.c
debug/*.obj:    表示忽略debug/io.obj，不忽略 debug/common/io.obj和tools/debug/io.obj
**/foo:         表示忽略/foo,a/foo,a/b/foo等
a/**/b:         表示忽略a/b, a/x/b,a/x/y/b等!/bin/run.sh    表示不忽略bin目錄下的run.sh檔案*.log:          表示忽略所有 .log 檔案
config.php:     表示忽略當前路徑的 config.php 檔案 
/mtk/           表示過濾整個資料夾*.zip           表示過濾所有.zip檔案/mtk/do.c       表示過濾某個具體檔案
 
被過濾掉的檔案就不會出現在git倉庫中（gitlab或github）了，當然本地庫中還有，只是push的時候不會上傳。
 
需要注意的是，gitignore還可以指定要將哪些檔案新增到版本管理中，如下：!*.zip!/mtk/one.txt
 
唯一的區別就是規則開頭多了一個感嘆號，Git會將滿足這類規則的檔案新增到版本管理中。為什麼要有兩種規則呢？
想象一個場景：假如我們只需要管理/mtk/目錄中的one.txt檔案，這個目錄中的其他檔案都不需要管理，那麼.gitignore規則應寫為：：/mtk/*
!/mtk/one.txt
 
假設我們只有過濾規則，而沒有新增規則，那麼我們就需要把/mtk/目錄下除了one.txt以外的所有檔案都寫出來！
注意上面的/mtk/*不能寫為/mtk/，否則父目錄被前面的規則排除掉了，one.txt檔案雖然加了!過濾規則，也不會生效！
 
----------------------------------------------------------------------------------
還有一些規則如下：
fd1/*
說明：忽略目錄 fd1 下的全部內容；注意，不管是根目錄下的 /fd1/ 目錄，還是某個子目錄 /child/fd1/ 目錄，都會被忽略；
 
/fd1/*
說明：忽略根目錄下的 /fd1/ 目錄的全部內容；
 
/*
!.gitignore
!/fw/ 
/fw/*
!/fw/bin/
!/fw/sf/
說明：忽略全部內容，但是不忽略 .gitignore 檔案、根目錄下的 /fw/bin/ 和 /fw/sf/ 目錄；注意要先對bin/的父目錄使用!規則，使其不被排除。

GIT命令-團隊開發

• git init --bare : 倉庫初始化(共用倉庫)
  • 注意: 不要直接在共用倉庫中編寫程式碼
• git clone：下載遠端倉庫到本地
  • 下載遠端倉庫到當前路徑：git clone 倉庫的URL
  • 下載遠端倉庫到特定路徑：git clone 倉庫的URL 存放倉庫的路徑
• git pull：下載遠端倉庫的最新資訊到本地倉庫
• git push：將原生的倉庫資訊推播到遠端倉庫
  • 提交時如果遠端倉庫有其它人提交的最新程式碼, 必須先pull, 再提交
• 衝突解決:
  • 當多個人同時修改了同一個檔案時, 後提交的需要先從伺服器pull程式碼到問題, 手動解決完衝突之後再push到遠端伺服器

<<<<<<< HEAD
	你原生的新增的程式碼=======
	伺服器上和你衝突的程式碼>>>>>>> e9609de28b65bf97539f94c6458cdebdf2711c9f

GIT經典協同模型

• 中心倉庫：包含master和develop兩個分支

• 分支分類

  • 主要分支：master和develop分支
  • 支援性分支：特性分支，釋出分支，熱修補程式分支

• 對於商業級專案，真正開發過程中都是基於develop分支進行的，develop分支是開發主線！

• master分支中，只存放相對穩定的分支，例如：0.1版本, 0.2版本

• 在實際產品開發中，需要「規劃版本」，例如：將100個功能規劃到5個不同的版本上

• 發現bug，要基於「上一個最穩定的版本」進行修復，這是熱修補程式分支存在的意義！

• 理解清楚版本管理分支的特性，是迭代式開發的重要基礎！
  

• git branch : 檢視所有分支

• git branch 分支名稱 : 建立分支

• 新建立的分支中的內容和master分支中的內容一樣

• git checkout 分支名稱 : 切換到指定分支
• git merge 分支名稱 : 合併分支
  • 將當前所在分支和指定名稱分支進行合併
• git branch -d 分支名稱 : 刪除指定分支

• 不能在當前分支中刪除自己

使用GIT我們應該

• 經常更新：降低衝突的可能性
• 提交前需在本機測試通過：降低將問題程式碼傳到版本庫
• 提交時一定寫備註：方便其他員工檢視和自己以後回顧
• 對於不需要提交的檔案不要提交到版本庫

提示:

• 每次提交之前先更新
• 每天下班前提交當天編譯通過的程式碼
• 每天上班第一件事情更新前一天的程式碼

GITHUB使用

• 1.註冊GitHub賬號
  • 
• 2.登入GitHub
  • 
• 3.點選你的倉庫
  • 
• 4.建立一個新的倉庫
  • 
• 5.新建的倉庫可以下載, 但是提交需要賬號密碼
• 6.設定SSH Key
  • 6.1開啟git 命令列工具
  • 輸入指令ssh-keygen -t rsa -b 4096 -C "[email protected]"
  • 
  • 6.2複製剛才生成的公鑰
  • 
  • 
  • 6.3將生成好的SSH Key 新增到GitHub
  • 
  • 
  • 
  • 6.4測試是否設定成功 ssh -T [email protected]
  • 如果後面出現 : Hi ****! You’ve successfully authenticated, but GitHub does not provide shell access.證明成功
• 7.利用SSH Key操作GitHub
  • 

oschina使用

• 和 GitHub 方法相同

推薦學習：《》

以上就是歸納整理Git版本控制學習指南的詳細內容，更多請關注TW511.COM其它相關文章！