在此simple guide to git中，合并始终在分支上执行：
git merge <branch>
然而，在我的新工作环境中，我遇到了一种实践，在这种实践中，开发人员从master（即不到他们自己的分支）中拉出来，但是当他们推动他们的更改（他们在自己的master上执行）时，他们将其推送到另一个“master”（实际上是一个“个人分支”）。然后，ci系统尝试将该“个人分支”与主（远程存储库）合并。
我知道这很管用，因为团队已经这样工作了很多年了。但是，从
git本身的角度来看，这样的事情是如何工作的呢？它是否符合预期的git概念？还是违反了一些基本原则？
最佳答案
我知道这很管用，因为团队已经这样工作了很多年了。但是，从git本身的角度来看，这样的事情是如何工作的呢？
…
然后，ci系统试图将该“个人分支”与master合并
（远程存储库）。
如果不指定分支git，请使用当前分支作为合并的“第二个”分支名称，在git中，可以为合并编写任意数量的分支。
git merge A B C ... N
git将根据分支的数量选择适当的合并策略。
然而，在我的新工作环境中，我遇到了这样一种实践：开发人员从master（即不到他们自己的分支）开始
pull，但当他们push他们的更改（他们在自己的master上执行）时，他们将其推送到另一个“master”（实际上是“个人分支”）。然后，ci系统尝试将该“个人分支”与主（远程存储库）合并。
这样没什么不对。吉特就像一头未经训练的野兽。你可以用任何你喜欢的方式“训练”，只要你擅长。
因此，如果这种方式适合您的it/devops团队，那么就没有问题了。