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
* br-2.1.2.2
master

3 创建分支

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git branch test

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git branch
* br-2.1.2.2
master
test

线面是把分支推到远程分支 

$ git push origin test

4 切换分支到test
shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git branch
* br-2.1.2.2
master
test

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ 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)
$ git branch
br-2.1.2.2
master
* test

M 表示cong 原来分支（上一次修改没有提交br-2.1.2.2）带过来的修改
5 删除本地分支   git branch -d xxxxx

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

$ git checkout br-2.1.2.2
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 'br-2.1.2.2'

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git br
* br-2.1.2.2
master
test

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git br -d test
Deleted branch test (was 17d28d9).

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (br-2.1.2.2)
$ git br
* br-2.1.2.2
master

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)

shuohailhl@SHUOHAILHL-PC /f/ggg/jingwei (test)
$ git branch -a
br-2.1.2.2
master
* test
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

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 的常用操作分为这么几步：

1. 选择操作的起点位置，git rebase -i SHA1
2. 指定每个节点的操作方式，保留/删除/修改/...，进入操作
3. 进入下一步操作/终止操作，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 操作对错误分支进行修改。