git 只merge部分_[Skill]俩小时掌握多人开发中git的主要用法

前言

几个月前看完了git文档，但是在实际开发中对很多git命令的具体影响仍有疑惑，比方说pull、fetch和rebase三个命令和检出位置拎不清。

Git - Bookgit-scm.com

安利一个git可视化练习的网站，画俩小时把所有题目都做完就足以掌握多人开发中git的主要用法，对各种git操作的影响也可以通过可视化一览无遗。

Learn Git Branchinglearngitbranching.js.org

遂又花了一个小时整理了一些操作的可视化细节，有时间的话推荐直接在网站上刷一下题目。

基础

# 提交commit
git commit -m "msg"# 创建并切换到分支
git checkout -b bugFix# merge分支
git checkout -b bufFix
git commit
git checkout master
git commit
git merge bugFix # 把bugFix分支merge到master上

其中merg分支的可视化：

高级

移动分支

# 使用提交记录上的标签（哈希值）来指定提交记录
git checkout C4
git checkout HEAD^
git checkout HEAD~4# 强制移动master分支
git branch -f master HEAD~3

撤销分支

git reset通过把分支记录回退几个提交记录来实现撤销改动。但是这种方法对大家一起使用的远程分支是无效的。需要使用git revert。

git reset HEAD~1
git revert HEAD

移动提交记录

将本地分支的指定commit工作复制到其他分支上

git cherry-pick C2 C4

交互式的rebase

git rebase -i HEAD~4

杂项

只取一个提交记录

适用于bufFix中有多个无效提交记录（比如打印debug日志），我们只需要取一个提交记录到主分支上即可。

git rebase -i 和 git cherry-pick均可实现

tag

tag可以指向某个提交记录的标识，比如软件发布新的大版本，或者修正一些重要的bug或者是增加了某些新特性。

git tag v1 C1

git describe

用于帮助你在提交历史中移动了多次后找到方向

# 语法：
git describe <ref>
# <ref>是任意能被git识别成提交记录的引用，如果你没有指定的话，git会以你目前所检出的位置（HEAD）。
# 输出结果：
<tag>_<numCommits>_g<hash>
# tag表示离<ref>最近的标签，numCommits表示这个ref和tag之间相差有多少个提交记录，hash表示你所指
# 定的ref所表示的提交记录哈希值的前几位。当ref提交记录上有某个标签时，只输出标签名称。

多分支全都rebase到master上

多个父节点时

使用git checkout HEAD^1中的^符号可以指定第几个父节点。而且^和~操作符支持链式操作：

git checkout HEAD~1^2~3

远程仓库操作

克隆远程仓库

# 克隆远程仓库
git clone

获取远程仓库更新

当远程仓库（虚线）更新了C2和C3两次提交时，本地仓库可以通过git fetch将C2和C3更新下载到本地仓库，同时本地的o/master分支也会更新。
需要注意的是，此时本地的master分支并不会更新。也就是git fetch并不会更新本地的master分支，只会更新本地的o/master指针。

更新前：

更新后：

git pull

相当于先git fetch获取远程仓库o/master更新后merge到本地的master分支上。

注意当本地分支和远程分支有分歧时也可以使用。

git push

将更新传递到远程仓库，远程仓库更新master分支
本地的远程分支o/master也会更新

偏离的工作

举个例子，当你完成自己的功能开发后，你的同事写了一堆提交并且改变了许多你功能中使用的API，这些改变使得你新开发的功能不可用，但是他已经将代码推送到远程仓库上了。此时如果git是不会允许你执行git push的，你只能先合并远程最新的代码，然后才能提交你的工作。

git fetch
git rebase o/master
git push

另外，我们也可以使用merge。

注意，使用rebase相比于pull可以使得提交历史更简洁。

使用前本地master和远程master有分歧：

使用pull时：

本地master同步远程master的更新
本地的o/master更新和远程master一致

使用fetch和rebase时：

首先fetch更新o/master远程分支

其次rebase会将C3的改变加在o/master上

git pull --rebase是fetch和rebase的缩写。

良好的开发规范

工作完成后快速地更新本地master分支并推送到远程仓库：

# 拉取远程分支更新并将更新推送到本地master
git pull --rebase
# 推送本地更新到远程
git push

一个小例子：

本地开发了多个功能，全部开发完成

更新o/master分支

git fetch

将不同功能rebase到o/master分支上

git rebase o/master side1
git rebase side1 side2
git rebase side2 side3

更新本地master分支并上传到远程仓库

git rebase side3 master
git push

相同的工作用merge完成：

注意，使用rebase可以让你让你的提交历史更加干净，但是缺点是你会丢失你的部分提交历史，虽然我个人感觉是意义不大的提交历史（在快速迭代开发中）。仁者见仁，智者见智。

git checkout master # 回到本地master分支
git pull # 更新本地master分支
git merge side1
git merge side2
git merge side3
git push

跟踪远程分支

master和o/master分支是相互跟踪的，是在我们克隆远程仓库时指定的。

# 法1：
git checkout -b totallyNotMaster o/master
# 法2：
git branch -u o/master totallyNotMaster

git push的参数

# 切换到本地的master分支，获取所有的commit，再到远程仓库origin中找到master分支，将远程
# 仓库中没有的提交记录都添加上去
git push origin master
# 将本地的某个分支推送到远程中的另一个分支
git push origin <source>:<destination>
# 注意这里的destination也可以是一个新建的分支

git fetch的参数

# 一方面git fetch只会下载远程的提交记录从而更新`o/master`，但不会更新本地的非远程分支。
# 另一方面我们可以通过<source>:<destination>来设置fetch的传输来源和目的地。其中source指的
# 是远程仓库的位置，而destination指的是本地仓库的位置。
# 如果git fetch没有任何参数，那么它会下载所有的提交记录到各个远程分支中，即更新所有的远程分支

git push和git fetch的空参数

# 删除远程的foo分支
git push origin :foo# 在本地创建新分支bar
git fetch origin :bar

git pull参数

git pull不带任何参数就是fetch和merge的组合，首先更新本地的远程分支，然后再merge你抓取到的提交记录。

即git pull origin foo相当于：

git fetch origin foo
git merge o/foo

git pull origin bar~1:bugFix相当于：

git fetch origin bar~1:bugFix
git merge bugFix

需要注意的是，git pull更新的是我们的检出位置，而不是一定更新本地master分支。

比如在pull之前，我们的HEAD在本地分支bar上：

当我们使用git pull之后：

git pull origin master