GIT簡史

和Linus的Linux分不開识脆，2002前善已，Linux居然是Linus本人親自手工合并代碼

2002-2005年换团，使用商業(yè)軟件BitKeeper，授權(quán)Linux社區(qū)免費(fèi)使用

2005年開發(fā)Linux Samba的Andrew 試圖破解BitKeeper協(xié)議偎球，被發(fā)現(xiàn)了衰絮，收回使用權(quán)

然后Linus花了兩周用C寫了一個分布式版本控制系統(tǒng)：git

2008年磷醋，github上線，git稱為最流行的分布式版本控制系統(tǒng)

git詞匯表（工作區(qū)淌友，版本庫震庭，暫存區(qū)）

其他版本控制系統(tǒng)以文件變更列表的方式存儲信息：存儲的是差異積累你雌，但是git不是

Git 更像是把數(shù)據(jù)看作是對小型文件系統(tǒng)的一組快照。 每次你提交更新肴颊，或在 Git 中保存項目狀態(tài)時渣磷，它主要對當(dāng)時的全部文件制作一個快照并保存這個快照的索引醋界。 為了高效，如果文件沒有修改袜硫，Git 不再重新存儲該文件，而是只保留一個鏈接指向之前存儲的文件帚称。 Git 對待數(shù)據(jù)更像是一個快照流闯睹。小型文件系統(tǒng)

git log中看到的hash是數(shù)據(jù)存儲前作的校驗和sha-1

branch:Git 的分支實質(zhì)上僅是包含所指對象校驗和（長度為 40 的 SHA-1 值字符串）的文件，所以它的創(chuàng)建和銷毀都異常高效

git status -s：文件的狀態(tài)

????已提交（已經(jīng)保存在本地版本庫 git commit）－－－> 本地版本庫 repository(.git directory

????已暫存（git add）－－－>暫存區(qū)staging area

????已修改（已經(jīng)修改始花，但是還沒有add）－－－>工作區(qū)working directory

????未跟蹤 untracked ：之前的快照中不包含這些文件－－－>工作區(qū)working directory

被忽略的基本操作（diff, mv, rm)

git diff:

????不加參數(shù)只顯示尚未暫存的改動酷宵，而不是自上次提交以來所做的所有改動浇垦，一般是git status 和git add之間使用

? ? --staged／--cached：查看已暫存的將要添加到下次提交里的內(nèi)容

git commit：

????-a(跳過暫存區(qū)）?

????-m（直接寫message的subject信息）

git rm：

????git rm xxx = rm xxx && git add

????如果刪除之前修改過并且已經(jīng)放到暫存區(qū)域的話荣挨，則必須要用強(qiáng)制刪除選項-f

????讓文件保留在磁盤默垄，但不讓 Git 繼續(xù)跟蹤，使用--cached選項（把本應(yīng)忽略的文件提交的時候）

????支持模式匹配

git mv:

????git mv A B = mv A B & git rm A & git add B

自定義（別名寡壮， .gitignore)

alias:

????git config --global?alias.co?checkout

????git config --global alias.unstage 'reset HEAD --'

????git config --global alias.last 'log -1 HEAD’

????git config --global alias.visual '!gitk'

.gitignore:

????無需納入 Git 的管理况既，也不希望它們總出現(xiàn)在未跟蹤文件列表

????所有空行或者以 ＃ 開頭的行都會被 Git 忽略。

????可以使用標(biāo)準(zhǔn)的 glob 模式匹配(shell 所使用的簡化了的正則表達(dá)式)

星號（*）匹配零個或多個任意字符悲靴；

[abc]匹配任何一個列在方括號中的字符

問號（?）只匹配一個任意字符癞尚；

方括號中使用短劃線分隔兩個字符（比如[0-9]表示匹配所有 0 到 9 的數(shù)字）乱陡。

使用兩個星號（*) 表示匹配任意中間目錄憨颠，比如`a/**/z` 可以匹配a/z,a/b/z或 `a/b/c/z`等

匹配模式可以以（/）開頭防止遞歸爽彤。

匹配模式可以以（/）結(jié)尾指定目錄。

要忽略指定模式以外的文件或目錄往核，可以在模式前加上驚嘆號（!）取反嚷节。

代碼回退（reset, revert, checkout)

git commit?—amend：

????一著急提交信息寫錯了／漏提交文件了： 最后只有一次提交

git reset：

????不小心 git add了和本次commit無關(guān)的東西: git reset HEAD file_name ? （--mixed是默認(rèn)參數(shù)）

????如果你在引用的尾部加上一個^硫痰， Git 會將其解析為該引用的上一個提交：HEAD^：“HEAD 的父提交”

????merge 解決沖突時碍论，搞花了，git reset --hard HEAD

????3個參數(shù):

--soft：撤銷了上一次git commit命令

--mixed：撤銷一上次提交税娜，但還會取消暫存所有的東西敬矩。 于是蠢挡，我們回滾到了所有g(shù)it add和git commit的命令執(zhí)行之前

--hard：你撤銷了最后的提交、git add和git commit命令以及工作目錄中的所有工作

git checkout （discard)

????改花了涧卵，不想要了腹尖，還原成本地版本庫的樣子）：git checkout?— file_name

????reset會移動 HEAD 分支的指向热幔，而checkout則移動 HEAD 自身

git revert:

git revert -m 1parent

多人協(xié)作（fetch, pull, push, blame, 沖突）

pull：

????=fetch+merge

commit message的一些約定：

如何編寫commit message：?https://chris.beams.io/posts/git-commit/

git emoji約定：https://gitmoji.carloscuesta.me/

git push：

????不帶參數(shù)會默認(rèn)push 到 origin branch_name, 但是不管tag

沖突：

????both modified

????解決沖突绎巨，add场勤，再commit

????默認(rèn)的commit信息中會告訴你沖突文件是什么

git log：

git log --left-right master…experiment：選擇出被兩個引用中的一個包含但又不被兩者同時包含的提交

git stash:

????切分支前，暫存還不想提交的代碼

git stash

git stash list

git stash apply

cherry-pick：

假設(shè)我們有個穩(wěn)定版本的分支舶沛，叫v2.0，另外還有個開發(fā)版本的分支v3.0撼港，我們不能直接把兩個分支合并骤竹，這樣會導(dǎo)致穩(wěn)定版本混亂蒙揣，但是又想增加一個v3.0中的功能到v2.0中，這里就可以使用cherry-pick

操縱歷史（ rebase)

rebase:實質(zhì)是丟棄一些現(xiàn)有的提交罩息，然后相應(yīng)地新建一些內(nèi)容一樣但實際上不同的提交

rebase的含義：

????把你的commit一個接一個的重現(xiàn)在某個分支的頂端

????保持你的commits的順序

不要對在你的倉庫外有副本的分支執(zhí)行rebase

否則瓷炮，人民群眾會仇恨你递宅，你的朋友和家人也會嘲笑你，唾棄你

一個基于rebase的workflow－－atlassian

這個模型基于rebase的第二種含義

過程：

基于master拉分支

開發(fā)過程中淋昭，如果master有變化响牛，重復(fù)：

????git fetch origin

????git rebase origin/master

如果多人合作赫段，重復(fù)：

????git fetch origin

????git rebase origin/branch

上面兩個過程可能有conflicts，rebase的沖突是一個一個出來的

git push

當(dāng)pull request 被approved

????git rebase -i origin/master

此時push糯笙，可能會需要-force贬丛，因為在改變public branch的歷史

最后merge到master：

????git checkout master

????git pull

????git merge --no-ff branch

這些配置，讓上面的過程更順暢：

git config --global branch.autosetuprebase always

git config --global pull.rebase preserve #(this is a very recent and useful addition that appeared in git 1.8.5)

git workflows?

git flow第一批模型：

????核心是master 分支和develop分支给涕，這兩個分支的生命周期是永遠(yuǎn)

????master分支永遠(yuǎn)是可部署到生產(chǎn)環(huán)境的狀態(tài)豺憔，develop是下一個準(zhǔn)發(fā)布版本

????當(dāng)develop分支OK了，可以發(fā)布了够庙，merge 回master恭应，在master上打上release tag

????支持性分支（這里所有的分支分類都只是約定的使用規(guī)范）：

????feature/topic分支（主要用于不確定發(fā)布時間或者不確定最后會不會被采納的新特性）

????????一般從develop開分支,OK后，merge回develop分支

????????merge回develop使用—no-ff 參數(shù)

????????需要注意的是這里的feature branch不會出現(xiàn)在origin里耘眨，也就是不會push到origin/feature branch

????release分支

????????用來支持下次發(fā)布的分支，也是從develop拉分支

????????merge回master剔难，給master打tag

????????merge回develop（這兩部也建議使用—no-ff參數(shù)）

????????刪除release分支

????hotfix分支

????????一般從master拉分支胆屿，解決生產(chǎn)環(huán)境的嚴(yán)重bug（必須立即修復(fù)的那種）

????????merge回master，給master打tag

????????merge回develop（這兩部也建議使用—no-ff參數(shù)）偶宫；如果此時有release分支非迹，可以merge回release分支來代替

????????刪除release分支

github flow：

輕量，非常簡潔纯趋，適合有持續(xù)集成每天多次部署的團(tuán)隊

基于master開分支（branch）

在分支上完成開發(fā)

開pull request,并基于PR進(jìn)行code review

????pull request可以在開分支的初期就開憎兽，便于和其他人進(jìn)行初期構(gòu)想的討論

????在分支上的提交會自動更新在pull request上

部署分支到生產(chǎn)環(huán)境

驗證分支是否OK

????如果不OK，使用master重現(xiàn)部署生產(chǎn)環(huán)境

????如果OK吵冒，merge master纯命，刪除分支

核心：master上的代碼始終是可部署的，這里的可部署是指已經(jīng)實際在生產(chǎn)環(huán)境驗證過了

gitlab workflows：

????production branch:app發(fā)布或者有發(fā)布window時桦锄，每次merge master 并不意味著現(xiàn)在master就能部署

production branch代表了生產(chǎn)環(huán)境代碼扎附，每次實際上線，將master merge到production branch结耀，然后上線

? ??env branches:

a staging environment：master代碼

a pre-production environment：開master和pre-production branch 的merge request,

a production environment:從把pre-production merge到production branch

? ??release branches:

從master拉release分支

'upstream first’policy：bug修復(fù)先merge到master留夜，然后再cherry-pick到release branch

pull request vs. merge request：

pull request: github等匙铡，第一個動作是pull feature branch

merge request: gitlab, 最后一個動作是merge

都可以在branch開始后就開（WIP時可以不分配給任何人）

pull request／merge request merge的時候：

創(chuàng)建一個merge commit

默認(rèn)使用--no-ff 參數(shù)

在descritption里寫issue number可以關(guān)聯(lián)并在merge后自動關(guān)閉對應(yīng)的issue

擴(kuò)展閱讀

????PRO GIT BOOK 2nd Edition:(有中文版）

????????https://git-scm.com/book/zh/v2

????.gitignore:

????????https://github.com/github/gitignore

????How to Write a Git Commit Message:

????????https://chris.beams.io/posts/git-commit/

????????https://gitmoji.carloscuesta.me/

????workflows and branching models and strategies:

????????A Successful Git branching model:http://nvie.com/posts/a-successful-git-branching-model/

????????Github workflow：https://help.github.com/articles/what-is-a-good-git-workflow/

????????atlassian：https://www.atlassian.com/blog/archives/simple-git-workflow-simple

????????gitlab:https://docs.gitlab.com/ee/workflow/gitlab_flow.html