標簽： Git
描寫性文字：
不要問我為何用這類騷豬風格的標題，現在寫博文，標題不騷，人家都不樂意看~
接觸Git到現在有1年多了，對Git使用也是日漸精進，雖然說不上很熟絡，但也算
入門，決定年前總結下，所以有了此文。Git博大精深，還有很多的東西需要學習，
比如自己搭建啊，1些便利工具的使用啊，1些疑問雜癥解決方案啊等等，固然
這就是下1話的事了。本文講述的是Git基礎的1些東西，沒有Git大法那個系列
那末通熟易懂，但是還是對關鍵性的知識點進行了淺析，相信看完本文你的Git
使用會更進1步，謝謝~
按大類劃分，分為兩種狀態：Tracked(已跟蹤)和Untracked(未跟蹤)，
根據是：該文件是不是已加入版本控制？
流程簡述：
假定某個項目已加入版本控制系統
- 1.新建1個文件，該文件處于 Untracked 狀態；
- 2.通過git add命令添加到緩存區，此時文件處于Tracked狀態又或說
此時這個文件已被版本控制系統所跟蹤，而且他處于Staged(暫存)狀態；- 3.通過git commit命令把暫存區的文件提交提交到本地倉庫，此時文件
處于Unmodified(未修改)狀態；- 4.此時如果去編輯這個文件，文件又會變成Modified(修改)狀態；
Git關心的是：文件整體是不是產生變化，而SVN關心的是：文件內容的具體差異！
SVN每次提交記錄的是：哪些文件進行了修改，和修改了哪些行的哪些內容
如圖：版本2中記錄的是文件A和C的變化，而版本3中記錄文件C的變化，以此類推；
而Git中，其實不保存這些前后變化的差異數據，而是保證全部緩存區中的所有文件，
又叫快照，有變化的文件保存，沒變化的文件不保存，而是對上1次的保存的快照
做1個鏈接！由于這類不同的保存方式，Git切換分支的速度比SVN快很多！
分為4個對象：
blob對象：寄存文件數據；
tree對象：目錄，內容為blob對象的指針或其他tree對象的指針
commit對象：快照，包括指向前1次提交對象的指針，commit相干的信
通過索引找到文件快照。
tag對象：1種特殊的commit對象，1般對某次重要的commit加TAG，以示重要(方便找)
辨別global 和 local，前者代表 全局設置，就是設置了在全部系統中，
所有的帶Git版本管理的項目都是這樣的配置；后者代表 本地設置 即在某個項目
中獨立的設置，后者優先級高于前者。比如全局設置的用戶名是”Coder-pig”，本地
設置的是”Jay”，commit的時候author就是Jay而不是Coder-pig。
處理命令行，還可以直接修改對應文件：
全局配置文件：etc/gitconfig
本地配置文件：當前倉庫/.git/config
# 安裝完Git后第1件要做的事，設置用戶信息(global可換成local在單獨項陌生效)： git config --global user.name "用戶名" # 設置用戶名 git config --global user.email "用戶郵箱" #設置郵箱 git config --global user.name # 查看用戶名是不是配置成功 git config --global user.name # 查看郵箱是不是配置 # 其他查看配置相干 git config --global --list # 查看全局設置相干參數列表 git config --local --list # 查看本地設置相干參數列表 git config --system --list # 查看系統配置參數列表 git config --list # 查看所有Git的配置(全局+本地+系統)
git help 命令 # 如：git help init
git init 倉庫名 # 創建1個新的帶Git倉庫的項目 git init # 為已存在的項陌生成1個Git倉庫
可使用git add 文件名，將工作空間的文件添加到暫存區，或批量添加文件
git add 文件名 # 將工作區的某個文件添加到暫存區 git add -u # 添加所有被tracked文件中被修改或刪除的文件信息到暫存區，不處理untracked的文件 git add -A # 添加所有被tracked文件中被修改或刪除的文件信息到暫存區，包括untracked的文件 git add . # 將當前工作區的所有文件都加入暫存區 git add -i # 進入交互界面模式，按需添加文件到緩存區
附：交互界面模式示例
上圖流程：
1.先在GitForTest的文件夾里創建了兩個文件
2.鍵入git add -i，進入后，鍵入4，選擇添加untracked的文件
3.他給我們列出了untracked的文件，然后我們根據序號來添加文件
4.輸入?會彈出相干提示，然后直接回車，結束選擇！
5.然后再次輸入git add -i，輸入4，可以看到已不存在untacked的文件了！
將未tracked的文件添加到緩存區后，Git就會開始跟蹤這個文件了！
對1些比如：自動生成的文件，日志，臨時編譯文件等，就
沒必要進行跟蹤了，這個時候可以編寫.gitignore文件，在里面
把不需要跟蹤的文件或文件夾都寫上，git就不會對這些文件進行跟蹤！
另外.gitignore文件與.git文件夾在同級目錄下！
如果不想自己寫，可以直接到：https://github.com/github/gitignore 復制粘貼！
也能夠自行編寫，支持簡化了的正則表達式(規范與示例模板摘自：Git王者超神之路)
- * ： 匹配零個或多個任意字符
- [abc]：只匹配括號內中的任意1個字符
- [0⑼]：- 代表范圍，匹配0⑼之間的任何字符
- ?：匹配任意1個字符
- *：匹配任意的中間目錄，例如a/*/z可以匹配:a/z,a/b/z,a/b/c/z等
示例模板：
# 疏忽所有以 .c結尾的文件 *.c # 但是 stream.c 會被git追蹤 !stream.c # 只疏忽當前文件夾下的TODO文件, 不包括其他文件夾下的TODO例如: subdir/TODO /TODO # 疏忽所有在build文件夾下的文件 build/ # 疏忽 doc/notes.txt, 但不包括多層下.txt例如: doc/server/arch.txt doc/*.txt
# 疏忽所有在doc目錄下的.pdf文件
doc/**/*.pdf
git commit -m "提交說明" # 將暫存區內容提交到本地倉庫 git commit -a -m "提交說明" # 跳過緩存區操作，直接把工作區內容提交到本地倉庫
如果不加-m “提交說明”，git會讓用你讓默許編輯器(如vi)來編寫提交說明，
vi難用(最少我不會用)，要末別漏掉-m “提交說明”，要末自己設置編譯器：
git config --global core.edit 喜歡的編輯器
除此以外，有時可能需要修改上次提交的內容，比如修改提交說明，或修改文件等：
# 合并暫存區和最近的1次commit，生成新的commit并替換掉老的
# 如果緩存區沒內容，利用amend可以修改上次commit的提交說明
# 注：由于amend后生成的commit是1個全新的commit，舊的會被
# 刪除，所以別在公共的commit上使用amend！切記！
git commit --amend
git commit --amend --no-edit # 沿用上次commit的提交說明
git status # 查看工作區與暫存區確當前情況 git status -s # 讓結果以更簡短的情勢輸出
git diff # 工作區與緩存區的差異 git diff 分支名 #工作區與某分支的差異，遠程分支這樣寫：remotes/origin/分支名 git diff HEAD # 工作區與HEAD指針指向的內容差異 git diff 提交id 文件路徑 # 工作區某文件當前版本與歷史版本的差異 git diff --stage # 工作區文件與上次提交的差異(1.6 版本前用 --cached) git diff 版本TAG # 查看從某個版本后都改動內容 git diff 分支A 分支B # 比較從分支A和分支B的差異(也支持比較兩個TAG) git diff 分支A...分支B # 比較兩分支在分開后各自的改動 # 另外：如果只想統計哪些文件被改動，多少行被改動，可以添加 --stat 參數
git log # 查看所有commit記錄(SHA-A校驗和，作者名稱，郵箱，提交時間，提交說明) git log -p -次數 # 查看最近多少次的提交記錄 git log --stat # 簡略顯示每次提交的內容更改 git log --name-only # 僅顯示已修改的文件清單 git log --name-status # 顯示新增，修改，刪除的文件清單 git log --oneline # 讓提交記錄以精簡的1行輸出 git log –graph –all --online # 圖形展現分支的合并歷史 git log --author=作者 # 查詢作者的提交記錄(和grep同時使用要加1個--all--match參數) git log --grep=過濾信息 # 列出提交信息中包括過濾信息的提交記錄 git log -S查詢內容 # 和--grep類似，S和查詢內容間沒有空格 git log fileName # 查看某文件的修改記錄，找背鍋專用
除此以外，還可以通過 –pretty 對提交信息進行定制，比如：
更多規則與定制以下(摘自：Git王者超神之路)，或參見：Viewing the Commit History：
format對應的經常使用占位符：(注：作者是指最后1次修改文件的人，提交者是提交該文件的人)
| 占位符 | 說明 | 占位符 | 說明 |
|---|---|---|---|
| %H | 提交對象（commit）的完全哈希字串 | %h | 提交對象的簡短哈希字串 |
| %T | 樹對象（tree）的完全哈希字串 | %t | 樹對象的簡短哈希字串 |
| %P | 父對象（parent）的完全哈希字串 | %p | 父對象的簡短哈希字串 |
| %an | 作者（author）的名字 | %ae | 作者的電子郵件地址 |
| %ad | 作者修訂日期（可以用 –date= 選項定制格式） | %ar | 按多久之前的方式顯示 |
| %cn | 提交者(committer)的名字 | %ce | 提交者的電子郵件地址 |
| %cd | 提交日期 | %cr | 提交日期，按多久之前的方式顯示 |
| %s | 提交說明 |
|
|
1些其他操作：
| 選項 | 說明 |
|---|---|
| -p | 按補釘格式顯示每一個更新之間的差異 |
| –stat | 顯示每次更新的文件修改統計信息(行數) |
| –shortstat | 只顯示 –stat 中最后的行數修改添加移除統計 |
| –name-only | 僅在提交信息后顯示已修改的文件清單 |
| –name-status | 顯示新增、修改、刪除的文件清單 |
| –abbrev-commit | 僅顯示 SHA⑴ 的前幾個字符，而非所有的 40 個字符 |
| –relative-date | 使用較短的相對時間顯示（比如，“2 weeks ago”） |
| –graph | 顯示 ASCII 圖形表示的分支合并歷史 |
| –pretty | 格式定制，可選選項有：oneline，short，full，Fullerton和format(后跟指定格式) |
還有1些限制log輸出的選項
| 選項 | 說明 |
|---|---|
| -(n) | 僅顯示最近的 n 條提交 |
| –since, –after | 僅顯示指定時間以后的提交。 |
| –until, –before | 僅顯示指定時間之前的提交。 |
| –author | 僅顯示指定作者相干的提交。 |
| –committer | 僅顯示指定提交者相干的提交。 |
| –grep | 僅顯示含指定關鍵字的提交 |
| -S | 僅顯示添加或移除某個關鍵字的提交 |
git brame 文件名 # 查看某文件的每行代碼的作者，最新commit和提交時間
可以為常見的命令起個簡單的別名，就不用每次都敲完全命令，比如可以設置：
status為st，checkout為co ; commit為ci ; branch為br等
git config --global alias.st status
對某些提交，我們可以為它打上Tag，表示這次提交很重要，
比如為1些正式發布大版本的commit，打上TAG，當某個版本
出問題了，通過TAG可以快速找到此次提交，拿到SHA1值，再
去查找問題，比起1個個commit看，省事很多！
Git標簽分兩種：輕量標簽 和 附加標簽
前者只是在提交上加個Tag，指向提交的Hash值；
而后者還會保存打標簽者的信息，時間和附加信息；
git tag 標記內容 # 輕量標簽 git tag -a 標記內容 -m "附加信息" # 附加標簽
如果想為之前的某次commit打TAG的話，可以先找出SHA1值，設置調下述命令：
git tag -a 標記內容 版本id # 比如：git tag -a v1.1 bcfed96
默許情況，git push不會把標簽推送TAG到遠程倉庫，如果想推送到服務器，可以：
git push origin 標記內容 # 推送某標簽到 # 刪除所有本地倉庫中不存在的TAG： git push origin --tags
另外，可以在新建分支的時候也加上TAG
git checkout -b 分支名 標記內容
最后，還可以用show命令查看標簽對應的信息
git show 標記內容
如果在工作區直接刪除被Git Tracked的文件，暫存區中還會存在該文件，
此時鍵入：git status，會是這樣：
Git告知你工作區的文件被刪除，你可以 刪掉暫存區里的文件或 恢復被刪文件
# 刪除暫存區中的文件： git rm 文件名
git commit -m "提交說明" # 誤刪恢復文件 git checkout -- 文件名 # 另外注意：git checkout會拋棄當前工作區的更改!!!不可恢復！！！務必謹慎！！！
如果更改后add到了暫存區，想恢復原狀，下述指令可讓文件恢復原狀：
git reset HEAD 文件名
git checkout 文件名
文件已commit了，想恢復成上次commit的版本或上上次，可以：
git reset HEAD^ # 恢復成上次提交的版本 git reset HEAD^^ # 恢復成上上次提交的版本，就是多個^，以此類推或用~次數 git reset --hard 版本號 # git log查看到的SHA1值，取前7位便可，根據版本號回退
reset命令其實就是：重置HEAD指針，讓其指向另外一個commit
而這個動作可能會對工作區與緩存區造成影響，舉個例子
- 本來的分支線：- A - B - C (HEAD, master)
- git reset B后：- A - B (HEAD, master)
解釋：看不到C了，但是他還是存在的，可以通過git reset C版本號找回，條件是
C沒有被Git當作垃圾處理掉(1般是30天)。
reset3個可選參數解析：
- –soft：只是改變HEAD指針指向，緩存區和工作區不變；
- –mixed：修改HEAD指針指向，暫存區內容丟失，工作區不變；
- –hard：修改HEAD指針指向，暫存區內容丟失，工作區恢復之前狀態；
Git會記住你輸入的每一個Git指令，比如上面的git reset 切換成1個舊的
commit，然后git log后發現新提交的記錄沒了，想切換回新的那次commit，
可以先調git reflog 獲得新commit的SHA1碼，然后git reset 回去。
git reflog
注意：這個指令記錄不會永久保存！Git會定時清算用不到的對象！！！
有時可能我們想撤消某次提交所做的更改，可使用revert命令
git revert HEAD # 撤消最近的1個提交 git revert 版本號 # 撤消某次commit
不是真的把提交給撤消了，而是生成1個新的提交來覆蓋舊的提交，被撤消的提交
和新的提交記錄都會保存！！！不信你再調1次revert HEAD 會發現被撤消的更改
又變回來了，另外，每次revert后，都需要發起新的commit！
簡單點說，撤消的只是文件變化，提交記錄照舊是存在的！
git show 提交id # 查看某次commit的修改內容
git rev-parse 分支名 # 查看分支commit的版本號，可以寫HEAD
由于你的某次誤操作致使commit丟失，如果git reflog都找不到，你
可以斟酌使用git fsck，找到丟失的對象的版本id，然后恢復便可。
git fsck --lost-found
提交記錄串成的時間線，默許初始創建的分支(時間線) —— master分支，
如果不切換到其他分支上，每次commit生成的快照都會串在這條分支上！
另外還有個 —— HEAD指針，該指針指向正在工作的本地分支，前面的版
本回退其實修改的就是這個HEAD指針的指向！
比如：在master分支上履行4次commit，分支的狀態圖以下
不難發現這樣的規律：
- 每次commit，master都會向前移動1步，指向最新的提交
- HEAD則指向正在工作的本地分支，而git reset修改的就是HEAD指針的指向！
通過兩個場景來體會創建其他分支的必要性
- 場景1：
項目1般都是1步步迭代升級的，有大版本和小版本的更新：大版本1般是改
頭換面的更新，比如UI大改，架構大改，版本是：v2.0.0這樣；小版本的更新
1般是UI小改，Bug修復優化等，版本是：v2.0.11這樣；
只有1條master分支，意味著：你的分支線會非常非常的長,假設你已發布
到了第2個大版本，然后用戶反饋第1個版本有很嚴重的BUG，這時候候想切回
第1個版本改BUG，然后改完BUG切會第2個大版本，想一想夠戧。- 場景2：
只有1個master分支的話，假設某次提交沖突了，而這個沖突很難解決或
解決不了， 那末，那個全部開發就卡住在這里了，沒法繼續向落后行了！
為了解決只有1個master分支引發的問題，可以引入分支管理，最簡單的1種策略以下：
在master分支上開辟1個新的develop分支，然后我們根據功能或業務，再在develop
分支上另外開辟其他分支，完成份支上的任務后，再將這個分支合并到develop分支上！
master與develop分支都作為長時間分支，而其他創建的分支作為臨時性分支！
簡述各個分支的劃分：
git branch 分支名 # 創建分支 git branch # 查看本地分支
比如在master分支上創建develop分支，此時的分支狀態以下：
git checkout 分支名 # 切換分支 git checkout -b 分支名 # 創建分支同時切換到這個分支
切換到develop分支后，改點東西，再commit，此時的分支狀態以下：
git checkout master 切回master分支，打開之前修改的文件，發現內容
并沒有產生更改，由于剛剛的更改是在develop上提交的，而master上沒有
變化，此時的分支狀態以下：
Git中，可使用 git merge 和 git rebase 兩個命令來進行分支的合并
git merge合并分支
合并的方式分為兩種：快速合并 和 普通合并，二者的區分在于：
前者合并后看不出曾做過合并，而后合并后的歷史會有分支記錄，如圖：
快速合并：
普通合并 ：
示例：
快速合并，把develop分支合并到master分支上，來到master分支后，鍵入下述命令
git merge develop
打開文件：
普通合并，切到develop分支下，修改note_2.txt的內容，再通過下述指令合并分支：
注：–no-ff參數表示禁用快速合并！
git merge --no-ff -m "合并的信息(TAG)" develop
分支線情況：
git reabse合并分支
rebase(衍合)，發現很多所謂的教程把這個東西寫得太深奧了，其實并沒有
那末復雜，只是這類合并會使得樹整潔，易于跟蹤，舉個簡單的例子來對照下
有1個項目由兩個人同時開發， 當前遠程倉庫的提交記錄是這樣的：
然后A和B各自開了1個條分支來完成相應功能，接著他們在自己的
分支上都做了屢次的commit，此時兩人的分別分支線是這樣的：
A先合并，再到B合并，這里我們假定兩人做的是完全不關聯的模塊，合并沒有沖突
merge合并
rebase合并
用法：
git rebase 想合并到哪一個分支的分支名
在我們合并分支的時候，有時會遇到合并沖突，然后合并失敗的問題，
此時需要我們先解決沖突后才能進行合并，個人開發倒很少會遇到，多人
開發的時候遇到合并沖突則是家常便飯。
1個最簡單的例子，A和B在develop分支上開辟出兩個分支來完成相干的
功能，A做完了，把自己的分支合并到develop分支，此時develop分支向前
移動了幾次commit，接著B也完成了他的功能，想把自己分支合并到develop
分支，如果改動的文件和和A改動的文件相同的話，此時就會合并失敗，
然后需要處理完沖突，才能夠繼續合并！簡單摹擬下這個例子，先試試merge！
merge分支后處理沖突
打開沖突文件，然后處理沖突部份，保存甚么代碼你自己決定，處理完后把
<<< 和 >>> 這些去掉：
處理后：
然后add，然后commit便可，合并結束：
此時的分支線：
接著試試
rebase分支后處理沖突
重新來1遍，然后把A直接merge到master，再切到B，rebase master，此時出現
合并沖突，這里有3個可選的操作：
git rebase --continue # 處理完沖突后，繼續處理下1個補釘 git rebase --abort # 放棄所有的沖突處理，恢復rebase前的情況 git rebase --skip # 跳過當前的補釘，處理下1個補釘，不建議使用，補釘部份的commit會丟失！
好的，有3次補釘要處理，1個個來：
處理后：
接著git add 添加修改后的文件，git rebase –continue繼續處理補釘：
接側重復之前的進程：
處理后：
第3個補釘是與A分支無關聯的改動，所以沒有沖突，所以也就直接合并了！
如果合并中途出了甚么過失可以git rebase –abort 恢復rebase前的狀態！
最后看下分支線會發現是1條直線，這也是用rebase合并分支的優點：
附上栗子，可以自己試試：GitTest.7z
對合并完的分支，基本都沒甚么作用了，可使用下述命令刪除：
git branch -d 分支名 # 刪除分支，分支上有未提交更改是不能刪除的 git branch -D 分支名 # 強行刪除分支，雖然這個分支上有未提交的更改
兩步，找出被刪除分支的最新commit的版本號，然后恢復分支
git log --branches="被刪除的分支名" # 找到被刪分支最新的commitb版本號 git branch 分支名 版本號(前7位便可) # 恢復被刪分支
有時我們可能在某個分支上正編寫著代碼，然后有1些突發的情況，需要
我們暫時切換到其他分支上，比如要緊急修復bug，或切換分支給同事
review代碼，此時如果直接切換分支是會提示切換失敗的，由于這個分支
上做的更改還沒有提交，你可以直接add后commit，然后再切換，不過我們
習慣寫完某個功能再提交，我們想：
先暫存這個分支上的改動，切去其他分支上弄完事，然后回來繼續
繼續在之前的改動上寫代碼。
那末可使用：
git stash # 保存當前的改動
然后放心的切換分支，然后再切換回來，接著使用：
git stash apply # 恢復保存改動
另外有1點1定要注意！！！可以stash多個改動！！如果你切換
到另外一個分支又stash了，然后切換回來stash apply是恢復成另外一個
分支的stash！！！
如果你這樣stash了屢次的話，我建議你先鍵入：
git stash list # 查看stash列表
找到自己想恢復的那個
比如我這里恢復的應當是netword上的stash，而第1個stash是devlop上的
直接git stash apply恢復的就是這個，但是恢復的應當是network的那個stash：
git stash apply stash@{1}
就是這樣，按自己需要恢復便可！
git branch -m 老分支名 新分支名 # 分支重命名
用于代碼托管，可以自己搭建遠程倉庫，或選擇專業的代碼托管平臺：
自己搭建的好處有：可控，內網安全，可以做1些定制，比如集成編譯，IM等，
固然，肯定是需要1些學習本錢的，(PS：我廠就是自己搭的Gitlab)
常見的代碼托管平臺(自己搜關鍵字去~)：
Github，Git@OSC，GitCafe，GitLab，coding.net，gitc，BitBucket，Geakit，Douban CODE
首先建立好與本地倉庫同名的遠程倉庫，然后復制下遠程倉庫的地址，比如：
鍵入下述命令關聯本地與遠程倉庫
git remote add origin 遠程倉庫地址
可以鍵入下述命令可查看遠程倉庫狀態
接著把本地倉庫推送到遠程倉庫，這里的 -u參數 作為第1次提交使用，
作用是把本地master分支和遠程master分支關聯起來(設置默許遠程主機)，
后續提交不需要這個參數！
git push -u origin master
另外，如果想修改遠程倉庫地址，可鍵入：
git remote set-url origin 遠程倉庫地址 # 也能夠先刪除origin后再添加 git remote rm origin # 刪除倉庫關聯 git remote add origin 遠程倉庫地址 # 添加倉庫關聯
或直接修改.git文件夾中的config文件，直代替換圈住位置
還要說明1點，origin 其實不是固定的東西，只是后面倉庫地址的1個 別名！！
可以寫成其他的東西，然后你也能夠設置多個倉庫關聯，用不同的別名標志，比如：
git remote add github https://github.com/coder-pig/SimpleTea.git git remote add osc git@git.oschina.net:coder-pig/SimpleTea.git
把項目推送到遠程倉庫后，其他開發者就能夠把項目clone到本地
git clone 倉庫地址 # 克隆項目到當前文件夾下 git clone 倉庫地址 目錄名 # 克隆項目到特定目錄下
關于獲得遠程服務器更新的方式有兩種，他們分別是fetch和pull，
雖然都可以獲得遠程服務器更新，但是二者卻又是不1樣的。
git fetch：
僅僅只是從遠處服務器獲得到最新版本到本地，假設你不去合并(merge)
的話，本地工作空間是不會產生變化的！比如：
我們在Github上創建1個README.md文件，然后調 git fetch 去獲得遠程
倉庫的更新。
git pull：
1步到位，或說：pull = fetch + merge，比如：一樣修改Github上的
README.md 文件，然后git pull 同步遠程倉庫的更新
區分不言而喻，實際開發中，使用git fetch會更安全1些，畢竟merge的時候
我們可以查看更新的情況，再決定是不是進行合并，固然看實際需要吧！
依照前面所講，在本地開辟分支來完成某些工作，本地提交了屢次后，
你想把分支推送到遠程倉庫，此時遠程倉庫并沒有這個分支，你可以：
git push origin 分支名 # 推送本地分支的內容到遠程分支
git branch -r # 查看所有分支
git checkout -b 本地分支 遠程分支 # 會在本地新建分支，并自動切換到該分支 git fetch origin 遠程分支:本地分支 # 會在本地新建分支，但不會自動切換，還需checkout git branch --set-upstream 本地分支 遠程分支 # 建立本地分支與遠程分支的鏈接
git push origin :分支名 # 就是前面的本地分支名改成1個問號而已
先刪除遠程分支，然后重命名本地分支，接著再Push到遠程倉庫
不知道仔細的你有無發現，倉庫地址除Https外，還有1個SSH，
這里我們簡單介紹下二者的區分，第1點：使用Https url可以任意克隆
Github上的項目；而是用SSH url克隆的話，你必須是項目的具有者或
管理員，而且還要添加SSH Key，否則會沒法克隆。還有1點是，
Https每次push都需要輸入用戶名和密碼，而使用SSH則不需要輸入
用戶名如果配置SSH Key時設置了密碼，則需要輸入密碼，否則直接
git push就能夠了！
另外，SSH，Secure shell(安全外殼協議)，專為遠程登陸會話
與其他網絡服務提供安全性的協議，而SSH傳輸的數據是可以經過緊縮的，
可以加快傳輸的速度，出于安全性與速度，我們優先斟酌使用SSH協議，
而SSH的安全驗證規則又分為基于密碼和基于密鑰兩種！
我們這里用的是基于第2種的，即在本地創建1對密鑰，
公鑰(id_rsa.pub)和私鑰(id_rsa),然后把公鑰的內容貼到
Github賬號的ssh keys中，這樣就建立了本地和遠程的認證關系，
當我們再push到遠程倉庫，會將你本地的公共密鑰與服務器的進行匹配，
如果1致驗證通過直接推送更新！
下面我們來建立ssh key，首先來到電腦的根目錄下，這里假定我們沒
創建過SSH key：
履行完ssh-keygen那個指令后，后面順次要你輸入文件名，
直接回車會生成兩個默許的秘鑰文件，接著提示輸入密碼，
直接回車，如果這里你輸入密碼了的話，那末push的時候
你還是需要輸入密碼，接著又輸多1次密碼，一樣回車，
然后出現最下面的這串東西就說明ssh key已創建成功了！
我們接著可以用編輯器打開id_rsa.pub文件或鍵入:
