代码合并：Merge、Rebase的选择
图解 Git 命令
基本⽤法
上⾯的四条命令在⼯作⽬录、stage 缓存(也叫做索引)和 commit 历史之间复制⽂件。
git add files 把⼯作⽬录中的⽂件加⼊ stage 缓存
git commit 把 stage 缓存⽣成⼀次 commit，并加⼊ commit 历史
git reset -- files 撤销最后⼀次 git add files，你也可以⽤ git reset 撤销所有 stage 缓存⽂件
git checkout -- files 把⽂件从 stage 缓存复制到⼯作⽬录，⽤来丢弃本地修改
git commit -a 相当于运⾏ git add 把所有当前⽬录下的⽂件加⼊ stage 缓存再运⾏ git commit。
git commit files 进⾏⼀次包含最后⼀次提交加上⼯作⽬录中⽂件快照的提交，并且⽂件被添加到 stage 缓存。
git checkout HEAD -- files 回滚到复制最后⼀次提交
代码合并：Merge、Rebase 的选择
概述
git rebase和git merge做的事其实是⼀样的。它们都被设计来将⼀个分⽀的更改并⼊另⼀个分⽀，只不过⽅式有些不同
Merge
#将 master 分⽀合并到 feature 分⽀最简单的办法就是⽤下⾯这些命令
git checkout feature
git merge master
#或者，你也可以把它们压缩在⼀⾏⾥。
git merge master feature
Rebase
#将 feature 分⽀并⼊ master 分⽀
git checkout feature
git rebase master
它会把整个 feature 分⽀移动到 master 分⽀的后⾯，有效地把所有 master 分⽀上新的提交并⼊过来。但是，rebase 为原分⽀上每⼀个提交创建⼀个新的提交，重写了项⽬历史，
并且不会带来合并提交。
rebase最⼤的好处是你的项⽬历史会⾮常整洁。⾸先，它不像 git merge 那样引⼊不必要的合并提交.
这种简单的提交历史会带来两个后果：安全性和可跟踪性。如果你违反了 rebase 黄⾦法则，重写项⽬历史可能会给你的协作⼯作流带来灾难性的影响。此外，rebase 不会有合
并提交中附带的信息——你看不到 feature 分⽀中并⼊了上游的哪些更改.
交互式的 rebase
git checkout feature
git rebase -i master
#它会打开⼀个⽂本编辑器，显⽰所有将被移动的提交：
pick 33d5b7a Message for commit #1
pick 9480b3d Message for commit #2提交更改是什么
pick 5c67e61 Message for commit #3
#这个列表定义了 rebase 将被执⾏后分⽀会是什么样的。更改 pick 命令或者重新排序，这个分⽀的历史就能如你所愿了。⽐如说，如果第⼆个提交修复了第⼀个提交中的⼩问题，你可以⽤ fixup 命令把它们合到⼀个提交中：pick 33d5b7a Message for commit #1
fixup 9480b3d Message for commit #2
pick 5c67e61 Message for commit #3
保存后关闭⽂件，Git 会根据你的指令来执⾏ rebase，项⽬历史看上去会是这样
忽略不重要的提交会让你的 feature 分⽀的历史更清晰易读。这是 git merge 做不到的。
Rebase 的黄⾦法则
最重要的就是什么时候不能⽤ rebase。git rebase 的黄⾦法则便是，绝不要在公共的分⽀上使⽤它。
⽐如说，如果你把 master 分⽀ rebase 到你的 feature 分⽀上会发⽣什么：
这次 rebase 将 master 分⽀上的所有提交都移到了 feature 分⽀后⾯。问题是它只发⽣在你的代码仓库中，其他所有的开发者还在原来的 master 上⼯作。因为 rebase 引起了新
的提交，Git 会认为你的 master 分⽀和其他⼈的 master 已经分叉了
所以，在你运⾏ git rebase 之前，⼀定要问问你⾃⼰「有没有别⼈正在这个分⽀上⼯作？」。如果答案是肯定的，那么把你的⽖⼦放回去，重新到⼀个⽆害的⽅式（如git
revert）来提交你的更改。不然的话，你可以随⼼所欲地重写历史。
#撤销提交
git revert 提交id
将上游分⽀上的更改并⼊feature分⽀
merge 是保留你完整历史的安全选择，
rebase 将你的 feature 分⽀移动到 master 分⽀后⾯，创建⼀个线性的历史。
默认情况下，git pull 命令会执⾏⼀次merge，但你可以传⼊--rebase 来强制它通过rebase来整合远程分⽀。
⽤ Pull Request 进⾏审查
如果你将 Pull Request 作为你代码审查过程中的⼀环，你需要避免在创建 Pull Request 之后使⽤ git rebase。只要你发起了 Pull Request，其他开发者能看到你的代码，也就是
说这个分⽀变成了公共分⽀。重写历史会造成 Git 和你的同事难以到这个分⽀接下来的任何提交
来⾃其他开发者的任何更改都应该⽤ git merge ⽽不是 git rebase 来并⼊。
因此，在提交 Pull Request前⽤交互式的 rebase 进⾏代码清理通常是⼀个好的做法。
可以在⼀个临时分⽀中执⾏ rebase。这样的话，如果你意外地弄乱了你 feature 分⽀的历史，你还可以查看原来的分⽀然后重试
git checkout feature
git checkout -b temporary-branch
git rebase -i master
# [清理⽬录]
git checkout master
git merge temporary-branch
总结
如果你想要⼀个⼲净的、线性的提交历史，没有不必要的合并提交，你应该使⽤ git rebase ⽽不是 git merge 来并⼊其他分⽀上的更改。
另⼀⽅⾯，如果你想要保存项⽬完整的历史，并且避免重写公共分⽀上的 commit，你可以使⽤ git merge。两种选项都很好⽤，但⾄少你现在多了 git rebase 这个选择。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。