今天我們來詳解一下git的各種命令,此為git的第一篇，后續還會有好幾篇，希望大家看了能有所進步
第一篇的命令
Git Commit
Git 倉庫中的提交記錄保存的是你的目錄下所有文件的快照，就像是把整個目錄復制，然后再粘貼一樣，但比復制粘貼優雅許多！
Git 希望提交記錄盡可能地輕量，因此在你每次進行提交時，它並不會盲目地復制整個目錄。條件允許的情況下，它會將當前版本與倉庫中的上一個版本進行對比，並把所有的差異打包到一起作為一個提交記錄。
Git 還保存了提交的歷史記錄。這也是為什么大多數提交記錄的上面都有父節點的原因 。對於項目組的成員來說，維護提交歷史對大家都有好處。
關於提交記錄太深入的東西咱們就不再繼續探討了，現在你可以把提交記錄看作是項目的快照。提交記錄非常輕量，可以快速地在這些提交記錄之間切換！
Git Branch
Git 的分支也非常輕量。它們只是簡單地指向某個提交紀錄 —— 僅此而已。所以許多 Git 愛好者傳頌：
早建分支！多用分支！
這是因為即使創建再多分的支也不會造成儲存或內存上的開銷，並且按邏輯分解工作到不同的分支要比維護那些特別臃腫的分支簡單多了。
只要記住使用分支其實就相當於在說：“我想基於這個提交以及它所有的父提交進行新的工作。”
分支與合並
將兩個分支合並到一起。就是說我們新建一個分支，在其上開發某個新功能，開發完成后再合並回主線。
咱們先來看一下第一種方法 —— git merge。在 Git 中合並兩個分支時會產生一個特殊的提交記錄，它有兩個父節點。翻譯成自然語言相當於：“我要把這兩個父節點本身及它們所有的祖先都包含進來。”
1.我們准備了兩個分支，每個分支上各有一個獨有的提交。這意味着沒有一個分支包含了我們修改的所有內容。咱們通過合並這兩個分支來解決這個問題。
我們要把 bugFix 合並到 master 里
git merge bugFix
哇哦！看見了嗎？首先，master 現在指向了一個擁有兩個父節點的提交記錄。假如從 master 開始沿着箭頭向上看，在到達起點的路上會經過所有的提交記錄。這意味着 master 包含了對代碼庫的所有修改。
git合並分支的第二種方法
Git Rebase
Rebase 實際上就是取出一系列的提交記錄，“復制”它們，然后在另外一個地方逐個的放下去。
Rebase 的優勢就是可以創造更線性的提交歷史，這聽上去有些難以理解。如果只允許使用 Rebase 的話，代碼庫的提交歷史將會變得異常清晰。
還是准備了兩個分支；注意當前所在的分支是 bugFix（星號標識的是當前分支）
我們想要把 bugFix 分支里的工作直接移到 master 分支上。移動以后會使得兩個分支的功能看起來像是按順序開發，但實際上它們是並行開發的。
咱們這次用 git rebase 實現此目標
執行 git rebase master
運行結果：
注意，提交記錄 C3 依然存在（樹上那個半透明的節點），而 C3' 是我們 Rebase 到 master 分支上的 C3 的副本。
現在唯一的問題就是 master 還沒有更新，下面咱們就來更新它吧……
現在我們切換到了 master 上。把它 rebase 到 bugFix 分支上
執行git rebase master
運行結果：
