Git工作流--将主节点合并到工作分支以进行最终合并

一位同事使用了一种我不熟悉的git合并策略，这似乎有点不同寻常，我正在努力确保我了解合并是如何工作的。我的理解是，正常的流程是：

• 从

  master

• 在那个分支上工作一会儿
• 完成后，签出工作分支，然后运行

  git merge

我还了解到，如果您的工作分支已经运行了一段时间，您可以定期将

master

合并到该分支中，以使其与其他更改保持同步

我的同事所做的是最终合并为

git checkout master；git合并

。这将产生如下所示的网络。在图中，黑色分支通常是主分支，实际上是同事在其工作分支上所做的工作，而蓝色分支是主分支上所做的工作

所以问题是：这种流动有什么负面影响吗？团队的其他成员执行更传统的“合并到

master

”或重定基址。我的想法是，如果团队中的其他人在

master

分支上的更改位置与同事在其分支中编辑的位置相同，那么同事的工作可能会被覆盖。还有什么我可能遗漏的吗？

而不是

git checkout master; 
git merge <work-branch-name>

git签出主机；
git合并

做

git重基主机
git签出主机；
git合并

重新基化会产生清晰的提交历史记录

也

`我还了解到，如果您的工作分支已经运行了一段时间，您可以定期将master重新设置到该分支中，以使其与其他更改保持同步。”

你可以在这篇文章中找到详细的解释

我的想法是，如果团队中的其他人在其分支中编辑的相同位置对主分支进行更改，那么同事的工作可能会被覆盖。还有什么我可能遗漏的吗？

---

我支持你，解决合并冲突有时会导致更改丢失，工作被覆盖。我们正在使用的实践是，在推送到master之前，我们从master获取并重新设置基础，在本地解决冲突（如果有），运行所有单元测试。如果单元测试覆盖了更改，则将检测到任何合并错误。还有一个CI服务器，每次将更改推送到主服务器时都会运行集成测试。

您应该阅读此处的完整答案：

---

摘要

不要合并分支，而是使用git pull--rebase
它将把您的所有提交放在分支的顶部

由于git

2.7

，您还可以为pull设置autostash开/关

git rebase --no-autostash

---

所以我开始在reddit.com/r/git上回复这篇文章，但如果我也在这里发布我的回复，这可能是一个更好的资源

所以

工作
节省工作量

git commit -a -m "message"

“现在‘师父’已经从原来的地方走了”

这是因为有人合并了更改并将其推送到master。[OP在reddit post中回答了我的问题]

git checkout master
git pull
git checkout workbranch
git merge master

因此，将master合并到您的工作分支的目的是提取其他人可能推动的任何更改。当您的工作分支需要保持代码的最新状态时，通常使用此选项，这些代码可能具有您希望在工作分支中进行的相关更改

执行这些步骤的更好方法是不签出master。如果有人在您完成合并之前将更改推送到master，该怎么办？相反，请执行以下操作

git checkout workbranch
git fetch origin
git merge origin/master

通过运行git merge origin/master，您告诉它只需将master的远程分支合并到当前分支中即可。
注意：这与您通过运行

git checkout master 
git pull

因此，在我看来，到目前为止，一切都是有意义的，做事情还有很长的路要走，但这并不是“错的”

这是真正令人担忧的部分

git checkout master
git reset --hard workbranch
git push

快速浏览一下git reset的文档，可以得出以下结论：

git重置[][]
此表单将当前分支头重置为，并可能根据需要更新索引（将其重置为的树）和工作树。如果省略，则默认为“-mixed”

--硬的
重置索引和工作树。对工作树中跟踪文件的任何更改都将被丢弃。
资料来源：

因此，听起来它重置为工作分支的提交，并删除所有其他更改。然后推送将更改发送到存储库

---

通常，存储库应该拒绝或创建合并冲突，因为提交id没有对齐。这可能意味着git push-f正在发生，如果您不知道自己在做什么，而其他人正在使用该存储库，这可能会导致一些麻烦

我知道，对某些人来说，重定基址是一种首选做法，我个人也这么做，但这个回答实际上并没有回答这个问题。更新了我的答案，希望这次更相关。所以，只是为了分享，重定基址并不完全“清除提交历史记录”。它用于获取父提交ID并将其重设为要重设的分支的提交。所以，如果您使用git rebase master，那么您将获取您的工作分支提交，删除它们，并从master中提取所有更新的提交。然后将它们合并到当前分支中。最后，它接受您已有的提交，创建具有相同内容和消息的新提交，并在上面应用它们。这并不能完全解决工作流中的问题，因为它似乎存在于重置中--hard。这是一个有趣的链接，但它实际上没有回答问题。如果我能够成功回答您的问题，您认为您可以选择我的作为解决方案吗？

git checkout master 
git pull

git checkout master
git reset --hard workbranch
git push