Git分支和合并

Question

我有一个特定的分支和合并方案，如下所述::

可以说我在git仓库中有一个“Master”分支。还有一个功能分支说 “Feature1”取自主人约200人将工作。现在我想让另一个分支说“Team_Feature”，其中约20人将工作。同时我必须保持“Team_Feature”分支与“Feature1 Branch”同步。在“Feature1”分支完成之后，它将被合并为主，新分支“Feature 2”将被采用。在此期间，我的团队将继续在“Team_Feature”上工作，这将与“Feature 2分支”合并。现在

，我重订特征1支进Team_Feature，我将每周一次做。面对

问题:: 我第二次重订，我得到了很多合并冲突，属于以下

1. 许多冲突提到的不同病例类型（添加/加）
2. 许多人（重命名的/删除）
3. 许多人编辑冲突，与从未在Team_Feature分行变更的文件中的冲突。
4. 而一些冲突的是合法的。

所以，问题是，

1. 这是什么添加/添加，重命名/删除，重命名/重命名冲突？
2. 是什么原因导致这些冲突触发？
3. 如何避免呢？
4. 最重要的无疑是在上面所列内容号码3。

请帮助，感谢提前:)

Answer 1

目标：

1. 请特征1同步，可在主机在未来合并其掌握
2. 保持团队功能与Feature1同步并在未来合并到 功能2

解决方案：

1. 保持每天的基础上合并主到特征1
2. 保持合并特征1到团队特征
3. （上述点＃1）之后一旦特征2来在现有的基础上，不断将Feature2合并到Team Feature中。

所以，问题是，

这是什么添加/添加，重命名/删除，重命名/重命名冲突？

什么原因导致这些冲突？

- >有很多链接可以理解这一点（重命名/删除，重命名/重命名），基本上它是在树枝级别更改为合并中的两个分支中的文件，并且这两个更改都不相同。除了添加/添加 - >这是文件内容级别冲突，就像在同一行文件中添加同一行号的不同内容一样

如何避免它们？

• 避免这种复杂的支化的替代的工作可以是 使用切换，而不是特征支化。

• 如果在特性分支模型时，写邮件来完成 团队关于你正在使用的区域，并要求他们不要做树 水平的变化如删除该区域，重命名等，这是更容易 解决内容冲突，但痛苦解决树水平冲突。

• 最后，要避免在分支机构工作的大团队发生冲突并不容易。

我强烈建议在这种情况下使用切换来避免复杂的合并冲突。 - 切换是一个功能的运行时间条件（标志），可以根据切换标志以两种可能的方式运行该功能。所有功能仅在一个分支中切换。

例子： -

比方说，我们正在实施一个新的详细信息页面，

我们将首先建立一个切换，其值存储在一些文件中说new_details_page =真

现在代码我们有这样一些 的事情，如果（new_details_page ==真）{ 渲染 'NEWPAGE' }其他{ 渲染 'oldPage' }

如果新细节页面的工作尚未完成，并且您想用旧细节页面发布产品，那么只需将该标志构建为false并将其部署到发布环境即可。

最后，在这种情况下避免合并冲突的最佳解决方案是使用切换，您可以在互联网上阅读关于切换与功能分支的更多信息。