代码合并：Merge、Rebase 的选择

最新推荐文章于 2024-09-10 16:54:43 发布

转载最新推荐文章于 2024-09-10 16:54:43 发布 · 248 阅读

0 ·

CC 4.0 BY-SA版权

原文链接：http://www.cnblogs.com/zhangjianbin/p/7775022.html

文章标签：

#git

本文详细介绍了Git的基本命令及用法，包括如何利用git add、git commit等命令管理文件变更，以及如何通过git merge和git rebase进行代码合并，还讲解了交互式rebase的应用场景和注意事项。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

图解 Git 命令

基本用法

687474703a2f2f6d61726b6c6f6461746f2e6769746875622e696f2f76697375616c2d6769742d67756964652f62617369632d75736167652e737667
上面的四条命令在工作目录、stage 缓存(也叫做索引)和 commit 历史之间复制文件。

git add files 把工作目录中的文件加入 stage 缓存
git commit 把 stage 缓存生成一次 commit，并加入 commit 历史
git reset -- files 撤销最后一次 git add files，你也可以用 git reset 撤销所有 stage 缓存文件
git checkout -- files 把文件从 stage 缓存复制到工作目录，用来丢弃本地修改

687474703a2f2f6d61726b6c6f6461746f2e6769746875622e696f2f76697375616c2d6769742d67756964652f62617369632d75736167652d322e737667

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

68747470733a2f2f7777772e61746c61737369616e2e636f6d2f6769742f696d616765732f7475746f7269616c732f616476616e6365642f6d657267696e672d76732d7265626173696e672f30322e737667

Rebase

#将 feature 分支并入 master 分支
git checkout feature
git rebase master

它会把整个 feature 分支移动到 master 分支的后面,有效地把所有 master 分支上新的提交并入过来。但是，rebase 为原分支上每一个提交创建一个新的提交，重写了项目历史，并且不会带来合并提交。
68747470733a2f2f7777772e61746c61737369616e2e636f6d2f6769742f696d616765732f7475746f7269616c732f616476616e6365642f6d657267696e672d76732d7265626173696e672f30332e737667
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，项目历史看上去会是这样
68747470733a2f2f7777772e61746c61737369616e2e636f6d2f6769742f696d616765732f7475746f7269616c732f616476616e6365642f6d657267696e672d76732d7265626173696e672f30342e737667

忽略不重要的提交会让你的 feature 分支的历史更清晰易读。这是 git merge 做不到的。

Rebase 的黄金法则

最重要的就是什么时候不能用 rebase。git rebase 的黄金法则便是，绝不要在公共的分支上使用它。
比如说，如果你把 master 分支 rebase 到你的 feature 分支上会发生什么：
68747470733a2f2f7777772e61746c61737369616e2e636f6d2f6769742f696d616765732f7475746f7269616c732f616476616e6365642f6d657267696e672d76732d7265626173696e672f30352e737667

这次 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 这个选择。

转载于:https://www.cnblogs.com/zhangjianbin/p/7775022.html