Git 學習筆記

一.Git 的産生

作者：林納斯·托瓦茲（Linus Torvalds），Linux 的偉大的副産物

Linus 在 1991 年建立了開源的 Linux 之後靠着開發者共同維護。

2002 以前，contributors 把源代碼檔案通過 diff 的方式發給 Linus，Linus 和維護者

手工方式

merge。

維護者受不了了，Linus 選擇了 BitKeeper，并且很喜歡 BitKeeper.

理查德・斯托爾曼（Richard Stallman）自由軟體倡導者，精神領袖，GNU計劃創造者

并且有人開始對 BitKeeper 逆向，破解，BitKeeper 收回了 Linus 的免費使用權。

Linus 不得不要寫一個自己的版本控制系統：

1.速度優勢，有能力高效管理類似 Linux 核心一樣的超大規模項目（速度和資料量）
2.對非線性開發模式的強力支援（允許上千個并行開發的分支）
3.完全分布式
4.簡單易用的設計

Linus 不到兩周時間， C 寫了一個分布式版本控制系統，1300 行左右，之後靠 contributors 去壯大。

身世評價:

親爹：Linus

幹爹：世界各地 contributors

外表：Source Tree, TortoiseGit 等等等

内涵：這裡

二. 集中式與分布式

集中化的版本控制系統：SVN

單一的集中管理的伺服器，儲存所有檔案的修訂版本，協同者通過用戶端連到這台伺服器，檢視送出記錄或者進行送出。checkout 的隻是某個版本的代碼，沒有任何版本資訊記錄。

分布式版本控制系統：Git

用戶端并不隻提取最新版本的檔案快照，而是把代碼倉庫

完整地鏡像

克隆（clone）提取（fetch) 到本地

1.分布式，去中心化
2.本地送出
- 斷網送出
- 小步送出，顆粒化，跟蹤代碼時，更加細膩
- 不用 sever，也可以進行版本控制
3.高速度，是以 commit，checkout 變得飛快

三. Git 結構模型

為什麼要了解 Git 結構模型？

我在哪？
我的代碼呢?
螢幕上的提示資訊到底是讓我幹嘛?

兩區兩庫：

Workspace：工作區，就是你在電腦裡能看到的目錄
Index / Stage：暫存區，在暫存區的東西，才能 commit 到 Repository
Repository：本地倉庫
Remote：遠端倉庫

六指令：

add：增加
commit：送出
push：推送
fetch：拉取
checkout：檢出
pull：fetch + merge

四. Git 配置及指令

1.配置 Git

//檢視配置

git config --global --list

//編輯配置

git config --global --edit

//設定送出人

git config --global user.name "John Doe"

//設定郵件

git config --global user.email [email protected]

//設定編輯器

git config --global core.editor emacs

git有3個配置檔案，分别是倉庫配置檔案、全局配置檔案、系統配置檔案。

/etc/config 系統配置檔案作用于整個系統的設定

位于git目錄的config檔案 (也就是 .git/config) 目前項目配置

~/.gitconfig 全局配置檔案配置一些全局都需要用到設定。作用于目前賬号的設定。

如：常用的使用場景

設定别名

//設定lg指令檢視分支圖

git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit"                

//設定co指令等同于 checkout

git config --global alias.co checkout

//設定分頁器,不分頁
git config --global core.pager 'less -F -X'

2.有趣的git常用指令學習

LearnGit

3.對branch的了解

4.常見的問題

merge 和 rebase 的取舍

rebase: 保證了送出點的幹淨有序。單分之多人開發的情況，建議rebase保證直覺性。

merge: 更加詳細了記錄了開發路線。多分支合并建議merge保留完整路徑。

rebase的沖突解決，

git rebase --continue

後悔藥 reset revert reflog

reset

類似 SVN 的revert，将目前分支送出重置回某個送出點。

git reset [commit]

//--soft --mixed --hard

注意：不要對已經在遠端伺服器的 commit 進行 reset

revert

對某一次送出做一次反向操作，并且送出建立一個新送出

git revert [commit]

reflog

列出 HEAD 經曆過的記錄，神器~

git reflog

五. Git 開發模型–GitFlow

Git Flow 是什麼

Git Flow是建構在Git之上的一個組織軟體開發活動的模型，是在Git之上建構的一項軟體開發最佳實踐。Git Flow是一套使用Git進行源代碼管理時的一套行為規範和簡化部分Git操作的工具。

2010年5月，在一篇名為“一種成功的Git分支模型”的博文中，@nvie介紹了一種在Git之上的軟體開發模型。通過利用Git建立和管理分支的能力，為每個分支設定具有特定的含義名稱，并将軟體生命周期中的各類活動歸并到不同的分支上。實作了軟體開發過程不同操作的互相隔離。這種軟體開發的活動模型被nwie稱為“Git Flow”。

一般而言，軟體開發模型有常見的瀑布模型、疊代開發模型、以及最近出現的靈活開發模型等不同的模型。每種模型有各自應用場景。Git Flow重點解決的是由于源代碼在開發過程中的各種沖突導緻開發活動混亂的問題。是以，Git flow可以很好的于各種現有開發模型相結合使用。

在開始研究Git Flow的具體内容前，下面這張圖可以看到模型的全貌（引自nvie的博文)：

Git Flow中的分支

Git Flow模型中定義了主分支和輔助分支兩類分支。其中主分支用于組織與軟體開發、部署相關的活動；輔助分支組織為了解決特定的問題而進行的各種開發活動。

主分支

主分支是所有開發活動的核心分支。所有的開發活動産生的輸出物最終都會反映到主分支的代碼中。主分支分為master分支和development分支。

master分支

master分支上存放的應該是随時可供在生産環境中部署的代碼（Production Ready state）。當開發活動告一段落，産生了一份新的可供部署的代碼時，master分支上的代碼會被更新。同時，每一次更新，最好添加對應的版本号标簽（TAG）。

develop分支

develop分支是儲存目前最新開發成果的分支。通常這個分支上的代碼也是可進行每日夜間釋出的代碼（Nightly build）。是以這個分支有時也可以被稱作“integration branch”。

當develop分支上的代碼已實作了軟體需求說明書中所有的功能，通過了所有的測試後，并且代碼已經足夠穩定時，就可以将所有的開發成果合并回master分支了。對于master分支上的新送出的代碼建議都打上一個新的版本号标簽（TAG），供後續代碼跟蹤使用。

是以，每次将develop分支上的代碼合并回master分支時，我們都可以認為一個新的可供在生産環境中部署的版本就産生了。通常而言，“僅在釋出新的可供部署的代碼時才更新master分支上的代碼”是推薦所有人都遵守的行為準則。基于此，理論上說，每當有代碼送出到master分支時，我們可以使用Git Hook觸發軟體自動測試以及生産環境代碼的自動更新工作。這些自動化操作将有利于減少新代碼釋出之後的一些事務性工作。

輔助分支

輔助分支是用于組織解決特定問題的各種軟體開發活動的分支。輔助分支主要用于組織軟體新功能的并行開發、簡化新功能開發代碼的跟蹤、輔助完成版本釋出工作以及對生産代碼的缺陷進行緊急修複工作。這些分支與主分支不同，通常隻會在有限的時間範圍記憶體在。

輔助分支包括：

用于開發新功能時所使用的feature分支；
用于輔助版本釋出的release分支；
用于修正生産代碼中的缺陷的hotfix分支。

以上這些分支都有固定的使用目的和分支操作限制。從單純技術的角度說，這些分支與Git其他分支并沒有什麼差別，但通過命名，我們定義了使用這些分支的方法。

feature分支

使用規範：

可以從develop分支發起feature分支
代碼必須合并回develop分支
feature分支的命名可以使用除 master ， develop release-* hotfix-* 之外的任何名稱

feature分支（有時也可以被叫做“topic分支”）通常是在開發一項新的軟體功能的時候使用，這個分支上的代碼變更最終合并回develop分支或者幹脆被抛棄掉（例如實驗性且效果不好的代碼變更）。

一般而言，feature分支代碼可以儲存在開發者自己的代碼庫中而不強制送出到主代碼庫裡。

release分支

可以從develop分支派生
必須合并回develop分支和master分支
分支命名慣例： release-*

release分支是為釋出新的産品版本而設計的。在這個分支上的代碼允許做小的缺陷修正、準備釋出版本所需的各項說明資訊（版本号、釋出時間、編譯時間等等）。通過在release分支上進行這些工作可以讓develop分支空閑出來以接受新的feature分支上的代碼送出，進入新的軟體開發疊代周期。

當develop分支上的代碼已經包含了所有即将釋出的版本中所計劃包含的軟體功能，并且已認證所有測試時，我們就可以考慮準備建立release分支了。而所有在目前即将釋出的版本之外的業務需求一定要確定不能混到release分支之内（避免由此引入一些不可控的系統缺陷）。

成功的派生了release分支，并被賦予版本号之後，develop分支就可以為“下一個版本”服務了。所謂的“下一個版本”是在目前即将釋出的版本之後釋出的版本。版本号的命名可以依據項目定義的版本号命名規則進行。

hotfix分支

可以從master分支派生
必須合并回master分支和develop分支
hotfix-*

除了是計劃外建立的以外，hotfix分支與release分支十分相似：都可以産生一個新的可供在生産環境部署的軟體版本。

當生産環境中的軟體遇到了異常情況或者發現了嚴重到必須立即修複的軟體缺陷的時候，就需要從master分支上指定的TAG版本派生hotfix分支來組織代碼的緊急修複工作。

這樣做的顯而易見的好處是不會打斷正在進行的develop分支的開發工作，能夠讓團隊中負責新功能開發的人與負責代碼緊急修複的人并行的開展工作。

更進一步

Git Flow開發模型從源代碼管理角度對通常意義上的軟體開發活動進行了限制。應該說，為我們的軟體開發提供了一個可供參考的管理模型。Git Flow開發模型讓nvie的開發代碼倉庫保持整潔，讓小組各個成員之間的開發互相隔離，能夠有效避免處于開發狀态中的代碼互相影響而導緻的效率低下和混亂。

git筆記

二. 集中式 與 分布式