我已经使用我们的git项目进入了一个泡菜。我们被迫（通过环境）将团队分成两个方面，一方面正在进行大规模的升级/大修任务，另一方面在我们上一个版本的基础上进行功能/错误修正（这是分支机构拆分的地方）关）
麻烦的是，那是六个月前。现在，功能团队已经完成，我面临着将这两个分支合并为一个单一的，有凝聚力的状态的难以置信的任务。
毋庸置疑，有很多冲突......差不多400具体。我能够通过变基最小化混乱而不是简单地合并，这已经帮助了很多，特别是在一个分支的修改文件被移动到另一个分支中的其他位置的情况下。其中有很多。
现在，虽然在大多数情况下冲突本身并不是特别难以解决，但我不能感到这种感觉不应该是任何一个单独的开发人员独自承担的工作。
Git似乎并不是这个领域通常有用的自我。因为理想的git工作流程可以保证冲突很小并且能够及时处理，所以似乎并不是分享与团队其他成员合作的方法。
那本来是理想的。能够提交文件而不用剥离他们的冲突状态。这样，其他开发人员可以检查正在进行的合并分支，并帮助清除他们各方的冲突，每个开发人员都会处理他们已经工作并且最了解的文件。
但这似乎不可能......不是我能找到的。
因此这个问题。有没有人知道是否有办法提交冲突的文件而不进行分段（从而将它们标记为技术上解决，以后很难找到）？
我希望能够检查出一个冲突的分支，查看那里的冲突，并在遇到麻烦时提供帮助，或者在这种情况下，寻求现在只是等待的开发人员团队的帮助让我尽我所能完成冲突解决，没有大量的上下文信息继续下去，所以他们可以稍后进入并依赖合并提交消息中的冲突记录，只是试图弄清楚他们的工作可能在哪里覆盖。
一如既往，非常感谢任何想法/想法/想法。任何事情都有帮助，如果至少要发泄必须解决400个文件冲突的挫败感。
干杯
嗯，至少是跟进，我能够在我自己的所有冲突中工作......花了几个小时，但它已经完成了。
然后，在我得到的（非常期待的）编译错误之后，我使用diff工具（与另一个检出到其中一个源分支的repo进行比较）检查项目中的所有代码文件，并更正rebase操作（以及随后的冲突解决马拉松）失败的任何问题。
在凌晨时分进行得很顺利，但我设法用一个编译的项目结束了这一天：）
今天，我正在修改项目资产文件及其在项目中的联系。这比较简单，游戏看起来像是正常的自我，所以绝望的程度会按比例下降。
尽管如此，如果有人知道一种分享大冲突操作的方法（一些提交方式而不会暂停冲突状态，或者可能是一种方法来检索技术上已解决但仍然存在冲突的文件），那将是非常受欢迎的信息，如果这种（颤抖）将来再次发生在任何人身上。
感谢您的回复！
干杯
答案 0 :(得分：1)
你绝对可以提交已被git标记为冲突的文件。我建议你创建一个新的分支，并将你当前的两个分支合并到那个分支中。这样，当您和您的队友在第三个merge分支上解决问题时，人们可以继续在当前分支上工作。
您应该注意到这对多个人来说是一个问题。如果它是一个足够大的项目，那么你经常会有团队参与改变代码的某些部分，因此那些人将负责解决代码中那些部分的合并冲突{{1分支。
一旦合并了所有内容，您只需将开发切换到merge分支或将其合并回merge分支。