合并大师的策略

Question

因此，如果我在分支机构工作，请将其称为feature-foo，最初是基于master。而且我不断添加许多提交。

• 同时，我的同事正在研究feature-baz，决定将他的分支合并为主人。

• 然后我们发现feature-foo取决于目前掌握的某些变化。我会将master合并到我的feature-foo分支中并继续构建feature-foo

• 在某些时候我准备将它合并回主人，但后来我的同事已将其他一些更改合并到主人，现在我有冲突，并且不能轻易合并我的{{ 1}}回来。

• 似乎更容易解决冲突，而不是将master合并到feature-foo我会从master开始一个新的分支，然后将feature-foo合并到该分支中。所以，我会创建feature-foo（基于当前主数据），然后将feature-foo-2合并到feature-foo，并修复冲突。

• 现在，我的feature-foo-2分支无冲突，可以合并为主。

所以我的问题是：也许我做错了什么？有没有更简单的方法来处理这一切？ 处理变更主人的最佳方法是什么？ 在将任何其他分支合并到我的分支之前，我是否应该总是尝试重新设定和压缩提交？因为在你从其他分支机构合并之后，显然不建议压缩提交。

我们不使用git-flow。据我了解 - 我不能将它用于自己的利益，整个团队必须同意使用它，对吧？ 你有什么想法？

upd：当然我忘了提到我无法推入orgin / master（这就是我们的github repo如何配置）。任何与master的合并都应该通过pull请求。 所以你看，即使我在我的本地分支中做了一些小东西，为了接受PR，我也必须将master合并/ rebase。但那个时代的主人已经可以拥有更多的东西了，实际上它使得我的分支变成/合并到主人（而不是其他方式）变得更加简单。但由于我无法将master推向原点，因此我必须创建一个临时分支（基于master），然后将我的更改合并/重新绑定到该源上，并根据该临时分支创建PR。

Answer 1

如果功能足够小，我会选择改装并与＆＃34; no fast-forward＆＃34;合并。 （--no-ff）选项，当它的时间来检查。这是一个偏好的问题 - 我更喜欢通过确保没有重叠的分支来保持主干净。

仅供参考，可视化您的树和所有分支：

git log --oneline --graph --all --decorate=short