git rebase 壁球提交

Question

我在 dev 有自己的 master 分店，还有另一个 dev2 分店由另一个人拥有，仍在 开发。 我需要在 dev2 上使用更改，因此我在 git merge dev2 分支上使用 dev。

第二天，在 dev2 上开发的那个人写了一些新代码，并使用“git rebase-liked”cmd 将他的提交压缩成一个新的，然后 push -f 到 { {1}} ，所以我再次使用 origin 来获取最新的更改，但是，发生了冲突。

我什至还没有对我的 git merge dev2 进行任何更改，但这只是冲突。自己改的话很容易想象，肯定会有更多的冲突。

是否有一些最佳做法可以避免在这种情况下发生冲突？

Answer 1

1. 不要让人们强行推动。它应该是例外。
2. 如果你总是需要另一个分支上的工作，你可能想直接在这个分支上工作
3. 一个“仍在开发中”的人在工作完成并且提交被正确压缩/评论/等之前不会推动

Answer 2

通常我们有两种方法来进行协作。

git rebase 和 git merge 都用于从一个分支中获取并合并到当前分支，但它们采用不同的工作方式。以下工作场景说明了差异。

场景：

如图：你在一个特性分支开发新特性，同时在master分支有新的提交。

为了将 master 上的新提交合并到您的功能分支，您有两个选择：mrege 或 rebase

git 合并

执行以下命令：

git checkout feature
git merge master

或者执行更简单：

git merge master feature

然后git会自动生成一个新的提交（merge commit） 此时在功能上看起来像这样：

• Marge 功能：自动创建新提交。
  如果在合并过程中遇到冲突，只需修改并重新提交即可。
• 优点：记录真实的提交状态，包括每个分支的详细信息。
• 缺点：因为每次merge都会自动生成一个merge commit，所以在使用一些git GUI工具的时候，尤其是commit比较频繁的时候，发现分支很乱。

git rebase

本质是变基。
rebase 是找到共同的祖先。

执行以下命令：

git checkout feature
git rebase master

看起来像这样：

• Rebase features：将合并之前的提交历史。
• 优点：获得更简洁的项目历史，删除合并提交
• 缺点：如果合并中出现代码问题，不容易定位，因为历史是重写的

如果合并过程中出现冲突，请按照以下步骤解决

修改冲突部分 添加 git rebase --continue （如果第三步无效，可以执行git rebase --skip） git add后不要习惯性地执行git commit命令

变基变基的黄金法则

<块引用>

切勿在公共分支上使用它

例如以下场景：如图

现在我们看到在公共分支上使用 rebase 有什么问题吗？ 如果您将 master 变基到您的功能分支：

Rebase 将所有 master 的提交移动到您的功能顶部。问题是：其他人还在原来的master上开发。因为你用rebase移动了master，git会认为你的master分支的历史和别人的不一样，会发生冲突。

所以在执行 git rebase 之前问问自己，

其他人会看这个分支吗？ if YES 不要使用这个破坏性的 rebase 命令来修改提交历史 如果不行，你可以随心所欲地使用 rebase

总结

如果你想要一个没有合并提交的干净、线性的历史树，那么你应该选择 git rebase。 如果你想保留一个完整的历史，又想避免重写提交历史的风险，你应该选择使用 git merge

在您描述的情况下。

• 建议您在自己的分支上使用 git rebase。其他人也遵守同样的规则。
• 当有人进行壁球提交时。不要将 -f 推送到 master 分支。
• 在处理 master 分支时，使用 git merge 从某人自己的分支获取提交。

Answer 3

1.不要允许任何body直接合并到main/master，这根本不是一个好主意，先做个pr，然后再讨论，然后才能合并到master/main。

2. 最好解决冲突，如果您的代码在本地，您可以使用 rebase 对在同一项目上工作的任何其他开发人员没有问题，否则可能会损坏其他开发人员，请确保下次避免这些事情。
立>