[TOC]
基本概念
-
master指針：指向最新的提交
資料
http://sfault-image.b0.upaiyun.com/37/92/37923f2478edc5709b36562b26c9e008
全局配置
$ git config --global user.name "kk"
$ git config --global user.email "xxx@gmail.com"
編輯模式查看全局設(shè)置：
git config --global -e列表形式查看全局設(shè)置：
git config --global -l
使用GitHub時利耍，在本地創(chuàng)建SSH Key
ssh-keygen -t rsa -C "youremail@example.com"
如果一切順利的話蚌本，可以在用戶主目錄里（~/.ssh）找到.ssh目錄盔粹，里面有id_rsa和id_rsa.pub兩個文件，這兩個就是SSH Key的秘鑰對程癌，id_rsa是私鑰舷嗡，不能泄露出去，id_rsa.pub是公鑰嵌莉，可以放心地告訴任何人进萄。
第2步：登陸GitHub，打開“Account settings”锐峭，“SSH Keys”頁面：
然后中鼠，點“Add SSH Key”，填上任意Title沿癞，在Key文本框里粘貼id_rsa.pub文件的內(nèi)容
遠(yuǎn)程倉庫
克隆遠(yuǎn)程倉庫到本地
git clone git@github.com:michaelliao/gitskills.git克隆遠(yuǎn)程倉庫某個分支到本地
git clone -b <branch> <remote_repo>
例如：git clone -b 指定的分支名字給本地倉庫指定遠(yuǎn)程倉庫
關(guān)聯(lián)GitHub倉庫：
git remote add origin git@github.com:michaelliao/learngit.git顯示遠(yuǎn)程倉庫：
git remote show origin
第一次推送使用：
git push -u origin 分支名稱
之后推送使用：
git push origin maste查看遠(yuǎn)程倉庫地址
git remote -v取消關(guān)聯(lián)遠(yuǎn)程倉庫
git remote rm origin
初始化git倉庫
git init
git add .
git commit -m “xxxx"
文件操作
刪除所有文件
git rm * -r
刪除文件夾
git rm filename -r
忽略無需版本控制的文檔
echo “*.txt” > .gitignore
日志
查看commit日志
git reflog
或
git log
分支管理
- 查看當(dāng)前所在分支
git branch -a - 切換到某個分支
git checkout 分支名字
- 創(chuàng)建本地分支并切換到創(chuàng)建的分支：
git checkout -b your_branch - 提交該分支到遠(yuǎn)程倉庫
git push origin dev
- 追蹤遠(yuǎn)程分支
git branch --track release_2.3.0 origin/HEAD:refs/for/release_2.3.0 - 將本地分支push到遠(yuǎn)程分支援雇，（遠(yuǎn)程會自動創(chuàng)建your_branch分支），并關(guān)聯(lián)本地分支與遠(yuǎn)程分支
git push -u origin your_branch - 刪除遠(yuǎn)程分支
git push origin --delete <branchName> - 刪除本地分支
git branch -d your_branch
本地提交回滾
- 先重置本地在上次提交之后的修改（如果需要的話）
git checkout *.m - 重置為遠(yuǎn)程倉庫的最新版本
soft表示本地的修改還在本地文件中椎扬，不加的話那么本地的修改也沒了
git reset HEAD^ --soft
拉取遠(yuǎn)程代碼時沖突
- 保存本地修改到暫存區(qū)
git stash - 拉取遠(yuǎn)程代碼
git pull - 將暫存區(qū)內(nèi)容恢復(fù)到本地惫搏，有沖突時先解決沖突
git stash pop
git stash 的使用
- 列出所有暫時保存的工作
git stash list - 恢復(fù)某個暫時保存的工作
git stash apply stash@{1}
保存stash時設(shè)置stash名稱
git stash save "my_stash"丟棄最近一次stash的文件
git stash drop
合并某次提交 merge a specific commit in Git
git cherry-pick d42c389f
git merge 后 push 到 Gerrit 失敗，提示 no new changes
- 在
git merge的時候盗舰，加上--no-ff參數(shù)晶府，是為了讓它生成一個新的 commit桂躏，這樣就可以提交了~（不過生成的 gerrit change 是看不到改動信息的）
tag 操作
- 查看tag
git tag - 創(chuàng)建 本地 tag
git tag 1.0.0
或者
git tag -m "first release" 0.1.0 - 推送 本地 tag 到遠(yuǎn)程服務(wù)器
git push origin 1.0.0 - 或者推送所有tags到遠(yuǎn)程服務(wù)器
git push --tags - 刪除本地 tag
git tag -d 1.0.0 - 刪除遠(yuǎn)程 tag
- 先刪除本地 tag
git tag -d 1.0.0 - 然后push
git push origin --delete tag 1.0.0
fatal: remote origin already exists.錯誤解決
- 先刪除遠(yuǎn)程 Git 倉庫
git remote rm origin
2 再添加遠(yuǎn)程 Git 倉庫
git remote add origin git@github.com:FBing/Java-code-generator
git ignore
- 創(chuàng)建
.gitignore文件
touch .gitignore
忽略規(guī)則示例
# 這是注釋行钻趋，將被忽略
*.a # 忽略所有以.a為擴(kuò)展名的文件
!lib.a # 但是名為lib.a的文件或目錄不要忽略，即使前面設(shè)置了對*.a的忽略
/TODO # 只忽略此目錄下的TODO文件剂习，子目錄中的TODO文件不忽略
build/ # 忽略所有build目錄下的文件蛮位，但如果是名為build的文件則不忽略
doc/*.txt # 忽略文件如doc/notes.txt，但是文件如doc/server/arch.txt不忽略
例如忽略下圖的GPUImage.framework框架
SystemVedio/GPUImage/GPUImage.framework
只追蹤某幾個文件
#忽略所有文件鳞绕，注意放在開頭
/*
#除src文件夾外
!/src
#除bin文件夾外
!/bin
#總的效果就是git只跟蹤src和bin兩個文件夾
merge 與 rebase 的區(qū)別
參考：https://www.zhihu.com/question/36509119/answer/131513261
搞清楚這個問題首先要搞清楚merge和rebase背后的含義失仁。
merge：會產(chǎn)生一次合并提交
先看merge，官方文檔給的說明是：
git-merge - Join two or more development histories together
顧名思義们何，當(dāng)你想要兩個分支交匯的時候應(yīng)該使用merge萄焦。
根據(jù)官方文檔給的例子，是master merge topic冤竹，如圖：
A---B---C topic
/
D---E---F---G---H master
然而在實踐中拂封，在H這個commit上的merge經(jīng)常會出現(xiàn)merge conflict。為了避免解決沖突的時候引入一些不必要的問題鹦蠕，工程中一般都會規(guī)定no conflict merge冒签。比如你在github上發(fā)pull request，如果有conflict就會禁止merge钟病。
所以才會有題主問的問題：在當(dāng)前的topic分支萧恕，想要引入master分支的F刚梭、G commit上的內(nèi)容以避免merge conflict，方便最終合并到master票唆。
這種情況下用merge當(dāng)然是一個選項朴读。用merge代表了topic分支與master分支交匯，并解決了所有合并沖突惰说。然而merge的缺點是引入了一次不必要的history join磨德。如圖：
A--B--C-X topic
/ /
D---E---F---G---H master
其實仔細(xì)想一下就會發(fā)現(xiàn)，在引入master分支的F吆视、G commit這個問題上典挑，我們并沒有要求兩個分支必須進(jìn)行交匯(join)，我們只是想避免最終的merge conflict而已啦吧。
rebase：將其他分支的內(nèi)容整合到當(dāng)前分支您觉，改變當(dāng)前分支branch out的位置
rebase是另一個選項。rebase的含義是改變當(dāng)前分支branch out的位置授滓。這個時候進(jìn)行rebase其實意味著琳水，將topic分支branch out的位置從E改為G，如圖：
A---B---C topic
/
D---E---F---G master
在這個過程中會解決引入F般堆、G導(dǎo)致的沖突在孝，同時沒有多余的history join。但是rebase的缺點是淮摔，改變了當(dāng)前分支branch out的節(jié)點私沮。如果這個信息對你很重要的話，那么rebase應(yīng)該不是你想要的和橙。rebase過程中也會有多次解決同一個地方的沖突的問題仔燕，不過可以用squash之類的選項解決。個人并不認(rèn)為這個是rebase的主要問題魔招。
綜上晰搀，其實選用merge還是rebase取決于你到底是以什么意圖來避免merge conflict。實踐上個人還是偏愛rebase办斑。一個是因為branch out節(jié)點不能改變的情況實在太少外恕。另外就是頻繁從master merge導(dǎo)致的冗余的history join會提高所有人的認(rèn)知成本。
