我一直在从旧分支签出到新分支，而不是签出到主分支。 目前，我已经创建了四个新功能：home_feature，admin_user-feature，customer_request和blog_feature。
在创建“ customer_request”分支之前，我忘记了结帐到主服务器，并通过移入博客功能来创建功能。 现在我面临很多冲突。我尝试使用'git rebase'，但是每个分支的提交最多可以进行80次提交，因此不切实际。 我该如何解决这些冲突？
cheng8889888 回答：我一直在从较旧的分支中创建新的Git分支，而无需向主节点签出
您可以进行合并并仅解决一次冲突，而不是像进行重新设置那样可能要解决多次。
或者您可以让Git在发生冲突时自动选择您的更改或主控的更改。
例如，如果您进行了变基，则可以将ours（或theirs）选项添加到递归合并策略中。
例如，以下命令会将您的分支重新置于master之上，并且对于任何冲突，它将选择您的更改而不是master的更改：
git rebase master -Xtheirs
在这种情况下，theirs和ours有点违反直觉。 -Xtheirs将选择您的更改，而-Xours将从母版中选择更改。
从评论看，这似乎是解决方案。您有三个分支：
- 硕士（男）
- 旧功能分支（O）
- 新功能分支（N）
N偶然是从O分支出来的，而不是M，这正是您想要的。这意味着从N的某个时间点开始有一系列提交，并且您希望使用这些提交重新创建分支，就像从M分支一样。
解决方案是创建一个新分支：
- 新功能分支（M中的N2）
然后从N确定一系列提交哈希，并将其应用于N2。您可以通过依次挑选每个人来手动完成操作。
存在这样的风险，因为与M相比M可能更改了某些文件，因此它们可能无法完全应用，因此在N中的工作将基于过时的文件/文件夹。文本更改合并是一种相当简单的算法，它无法像人类一样理解代码结构（换句话说，并不是所有东西都可以合并）。
但是，事实证明，樱桃小树枝干净利落。如果您无法执行此操作，则可能必须为每个失败的差异创建一个差异，并鉴于M的变化，了解如何将其手动应用于N2。在这种情况下，仍然值得尝试-选择以下提交，因为它们不一定都需要手动解决冲突。