Git 版本控制學習指南(2021版)-有解無憂

介紹：GitGuide 致力于打造最易懂的 Git 版本控制入門教程，讓天下沒有難學的 Git 版本控制

本文已經收錄至開源專案GitGuide

專案地址：https://github.com/coderit666/GitGuide

給我一個 Star！ ?

如果您喜歡或者打算使用這個專案來學習或者來開始你的 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自學網站推薦: https://backlog.com/git-tutorial/cn/

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 "your_email@example.com"
- 6.2復制剛才生成的公鑰
- 6.3將生成好的SSH Key 添加到GitHub
- 6.4測驗是否配置成功 ssh -T git@github.com
- 如果后面出現 : Hi ****! You’ve successfully authenticated, but GitHub does not provide shell access.證明成功
7.利用SSH Key操作GitHub