作者:Video++极链科技后端杨婕
前言
在前一篇文章,我们讨论了merge和rebase的区别。而这两者也有逻辑上的共性,它们都可以看做 比较差异 ➡ 提取/合并差异 ➡ 应用差异 的过程。除了这两个自动化的命令,我们也可以手动逐步实现这一过程。
Part 1
无论是merge还是rebase,都是在同一个工作目录中协调差异,处理变更历史。而git的另一些命令,允许开发者单独保存,或者通过文件或邮件的方式与别人分享这些差异。
这有助于更灵活的选择和使用某些较为独立的更改。这有点类似另一类版本控制系统的工作方式:存储差异而不是快照。
可以使用 git diff > patchfile 将差异输出到patch文件,保存或者分享给他人。使用 git diff 命令可以查看工作区修改的内容,git diff —cached 命令查看添加到暂存区但还未提交的内容。这两种命令会生成兼容unix系统的标准格式patch。类似这样:
git apply --stat patchfile
git apply --check patchfile
git apply patchfile
这三条命令分别是,检查patch文件格式,测试patch是否能应用到当前分支,应用此patch。
这种方式传递的修改将会丢失提交信息和作者信息,但可以兼容非git管理的代码。除此之外,git还提供另一个命令更便于git库之间的patch传递。
git format-patch commit-id
git format-patch -s commit-id
生成指定提交之后的所有提交的patch。把 -s 改为 -n,n为任意数字,则会生成每个提交之前的n个patch。每个patch是单独的文件,命名类似于:
0001-commit message.patch
format-patch生成的patch保存了更多提交信息。因此除了git apply之外,还可以用更智能的git am命令使用此patch。git am 命令会在应用patch失败时给出详细的错误信息,并允许手动解决冲突,是官方较为推荐的补丁应用方式。
Part 2
我们在使用版本控制工具时,总会花费很多时间来处理diff,比如检查正在进行的未提交的工作,查看单个提交中发生了什么变更,在执行