經過前面理論的學習,相信對git的模型已經有了一個比較深入的認識,在講解常用開發指令之前,先看下git整體操作流程
我們按照一個正常的開發流程來學習,我們現在要開始開發了,首先我們需要把遠端倉庫同步到本地
git clone https://github.com/generalthink/git_learn.git
運作完上面的指令,在我們的目前工作目錄就會有一個git_learn的檔案夾,其中存在.git目錄(git維護倉庫的基本)以及和遠端倉庫一樣的檔案,現在我們的代碼環境就和遠端倉庫一緻了,我們就可以開始我們的開發流程了。
開發流程
一般來說，無論是開發新功能(feature)還是修改bug(issue)我們都不會直接在主幹上進行開發，而是會在分支上進行開發，然後驗證無誤之後在同步到master。
現在突然有了一個bug我們要新開一個分支來解決這個bug,那麼我們應該怎麼做呢?
首先，建立一個bugFix分支,并切換到這個分支
git branch bugFix
git checkout bugFix
或者
git checkout -b bugFix
建立一個分支,隻是多了一個指針指向目前最新的送出而已,後面所有的送出都基于目前的分支,星号代表目前分支。
然後，找到bug的原因，修改對應的檔案，現在我們修改了幾個檔案,需要送出将它加入到我們本地倉庫,同步到遠端倉庫會在後面的文章講解。
- 加入修改的檔案到暫存區
git add *.java
上面的操作實際上是使檔案工作目錄和暫存區的版本一緻,但是現在和倉庫的版本還不一緻.想要檢視具體存在哪些檔案需要送出可以使用
git status
檢視。
- 送出檔案到本地倉庫
git commit -m "fix bug"
commit
指令實際上是讓index中檔案在暫存區和倉庫的版本保持一緻,經過這個步驟,工作目錄,暫存區以及倉庫的版本都是一緻了，下面的圖是送出前後commit objects(可以檢視資料模型那篇文章)的變化。
你在修改bug的同時,其他人已經往主幹分支上送出了其他功能的代碼或者你本地本來就存在兩個不同的分支,是以修複了這個bug之後,我們的倉庫看上去是這樣的
合并分支
這個bug修複後,被測試驗證通過了,然後接下來想要把這個分支的代碼合并到主幹分支(或者合并兩個不同的分支),常用的合并方式有2種
git merge
将bugFix合并到master分支上
//切換到master分支
git checkout master
git merge bugFix
看到了沒有,master指向了一個擁有兩個父節點的送出記錄,如果從master開始沿着箭頭向上看,在到達起點的路上會經過所有的送出記錄,這意味着 master 包含了對代碼庫的所有修改。
這個時候如果你還想把master分支合并到bugFix分支也是可以的
git checkout bugFix
git merge master
因為 master 繼承自 bugFix，Git 什麼都不用做，隻是簡單地把 bugFix 移動到 master 所指向的那個送出記錄。
現在所有送出記錄的顔色都一樣了，這表明每一個分支都包含了代碼庫的所有修改！
git rebase
第二種合并分支的方法是 git rebase。Rebase 實際上就是取出一系列的送出記錄，“複制”它們，然後在另外一個地方逐個的放下去。
Rebase 的優勢就是可以創造更線性的送出曆史.
git rebase master
現在 bugFix 分支上的工作在 master 的最頂端，同時我們也得到了一個更線性的送出序列。
注意，送出記錄 C3 依然存在（樹上那個虛線節點），而 C3’ 是我們 Rebase 到 master 分支上的 C3 的副本。
現在唯一的問題就是 master 還沒有更新，下面咱們就來更新它吧
git checkout master
git rebase bugFix
由于 bugFix 繼承自 master，是以 Git 隻是簡單的把 master 分支的引用向前移動了一下而已。
點贊關注不迷路