git 指令

1 檢視遠端分支

$ git branch -a

* br-2.1.2.2

master

remotes/origin/HEAD -> origin/master

remotes/origin/br-2.1.2.1

remotes/origin/br-2.1.2.2

remotes/origin/br-2.1.3

remotes/origin/master

2 檢視本地分支

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)

$ git branch

3 建立分支

$ git branch test

test

線面是把分支推到遠端分支

$ git push origin test

4 切換分支到test

$ git checkout test

M jingwei-server/src/main/java/com/taobao/jingwei/server/service/cmd/GetCustomerTarCmd.java

M jingwei-server/src/main/java/com/taobao/jingwei/server/util/ServerUtil.java

Switched to branch 'test'

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (test)

br-2.1.2.2

* test

M 表示cong 原來分支（上一次修改沒有送出br-2.1.2.2）帶過來的修改

5 删除本地分支 git branch -d xxxxx

$ git checkout br-2.1.2.2

Switched to branch 'br-2.1.2.2'

$ git br

$ git br -d test

Deleted branch test (was 17d28d9).

6 檢視本地和遠端分支 -a。前面帶*号的代表你目前工作目錄所處的分支

remotes/origin/HEAD -> origin/master #啥意思呢？

”在clone完成之後，Git 會自動為你将此遠端倉庫命名為origin（origin隻相當于一個别名，運作git remote –v或者檢視.git/config可以看到origin的含義），并下載下傳其中所有的資料，建立一個指向它的master 分支的指針，我們用(遠端倉庫名)/(分支名) 這樣的形式表示遠端分支，是以origin/master指向的是一個remote branch（從那個branch我們clone資料到本地）“

這個是執行 git remote -v 的結果，看出來origin其實就是遠端的git位址的一個别名。

$ git remote -v

origin git@xxxx/jingwei.git (fetch)

origin git@xxxx/jingwei.git (push)

7 删除遠端版本

git push origin :br-1.0.0

删除遠端分支

git branch -r -d origin/branch-name

git push origin :branch-name

放棄本地修改，恢複代碼

git fetch --all

git reset --hardb origin/master

git pull

解決沖突，合并分支

Step 1. Fetch and check out the branch for this merge request

git fetch origin

git checkout -b 1231_incident_share origin/1231_incident_share

Step 2. Review the changes locally

Step 3. Merge the branch and fix any conflicts that come up

git checkout mk-test

git merge --no-ff 1231_incident_share

Step 4. Push the result of the merge to GitLab

git push origin mk-test

技巧：

下面是一個送出了 4 次的分支效果，每個節點的意思是

節點名(commit 資訊 - SHA1)

：

A(add A - 510fdc) -> B(add B - 0406b6) -> C(add C - 39a9c2) -> D(add D - 3131e0)<目前>

修改最近一次的送出資訊

将上次送出的資訊（add D），修改為

push D

，可以通過 commit 的 amend 指令進行修改，如下：

git commit --amend
# 執行指令後，會進入到一個互動視窗，可以在互動視窗内修改上次的送出資訊

利用 rebase 對送出進行各種修改

rebase 的常用操作分為這麼幾步：

選擇操作的起點位置， git rebase -i SHA1
指定每個節點的操作方式， 保留/删除/修改/... ，進入操作
進入下一步操作/終止操作， git rebase --continue ， git rebase --abort

比如我們要将節點 B 的 commit 資訊（add B），修改為

push B

，那麼按照上述的操作指南，可以執行（第一步）：

# 第一步，進入 B 之前的節點，A
git rebase -i 510fdc # 510fdc 是 A 節點的 SHA1

此時會進入一個互動視窗，内容大緻為：

pick B 0406b6
pick C 39a9c2
pick D 3131e0

你需要看懂這個結構，不過也不用緊張，它很簡單。由于我們将操作指針指向了 A，是以它會展示 A 以後的所有送出記錄，根據連結清單順序排列，依次展示節點 B、C、D，前面的一個英文單詞是操作指令，總共有這麼幾種指令：

pick ，保留節點，不做任何變更
edit ，保留節點，修改内容
drop ，删除節點，删除本次送出
reword ，保留節點，修改送出資訊
squash ，保留節點修改，并且與上一個節點合并，也就是兩次送出并做一次
fixup ，保留節點修改，忽略本次送出資訊
exec ，run command (the rest of the line) using shell

用的比較多的是前三個，可以隻關注前三個。我們需要修改下互動視窗的内容，改為（第二步）：

+ edit B 0406b6
- pick B 0406b6
pick C 39a9c2
pick D 3131e0

上面是 diff，實際内容是：

edit B 0406b6
pick C 39a9c2
pick D 3131e0

此時會進入一個臨時 git 分支，大緻是這樣：

branch(0406b6):

由于你告訴了 git 要對 B 節點就行修改，是以它就停在了 B 處理，等着你修改，此時，你可以通過 amend 指令修改送出資訊：

branch(0406b6): git commit --amend
# 進入互動視窗，将 commit 資訊修改為 push B

操作完成後，執行（第三步）：

git rebase --continue

由于你告訴 git 隻需要操作一個節點，是以它會回到最初的位置<目前>，否則的話，它會繼續進入下一個臨時 git 分支。當然，如果你進入第三步以後，突然又不想修改了，可以執行：

git rebase --skip

跳過對本節點的修改。

以上就是 rebase 的基本使用方法，那麼留下幾個思考題，讀者可以自行操作：

通過 rebase 删除 C 節點（drop）
通過 rebase 合并 A 和 B 節點的修改（squash）
交換 B 和 C 的送出順序

将一個分支的修改合并到另一個分支

通過

git cherry-pick SHA1

這個指令可以可以完成目标，

master: A(add A - 510fdc) -> B(add B - 0406b6) -> C(add C - 39a9c2)<目前>
                                     \
dev:                             D(add D - 4569c2) -> E(add E - 087342)

如果我們想把 dev 分支 D 節點的修改合并到 master 分支，可以執行：

# 首先確定自己在 master 分支上，git branch master
git cherry-pick 4569c2 # 4569c2 為 D 節點的 SHA1

快速定位一個 bug 在哪次修改上

假設我們在本地送出了一堆 commit，正準備 push 到倉庫之前，發現有一個 bug，但是記不起來是哪一次 commit 造成的了，怎麼辦？我們需要通過

reset/rebase/stash

等操作復原到上一個狀态進行測試，但是這樣會很麻煩，而且效率不一定很高，git 為我們提供了更加便捷的工具

git bisect

，通過二分法找 bug。它提供的指令也很直白：

git bisect start                 # 進入二分查找
git bisect good [good-commit-id] # 設定沒問題的版本 SHA1，排查起點
git bisect bad [bad-commit-id]   # 設定有問題的版本 SHA1，排查終點
# 此時 git 就會自動進入到中間版本狀态

進入中間版本狀态，測試後，如果有問題，就标記為 bad，如果沒有問題，就标記為 good，如下：

git bisect bad  # 有問題
git bisect good # 沒問題

當你找到問題以後，可以執行 reset 回到初始狀态：

git bisect reset

然後通過上面介紹的 rebase edit 操作對錯誤分支進行修改。