【发布时间】：2016-07-01 00:02:35
【问题描述】：
我是使用 git (bitbucket) 的新手
昨天我做了 git commit 和 push，今天我在我的所有文件上发现了奇怪的字符，比如“>>>>>>> 3eabb8c0e5effecfac857956bb8e941616669bc5”，整个项目都不起作用。我该如何解决这个问题？
【问题讨论】：
【发布时间】：2016-07-01 00:02:35
【问题描述】：
这是一个合并冲突，检查git status，它应该告诉您合并正在进行中以及哪些文件存在冲突。
您需要做的是，决定要保留哪个版本，然后删除另一个，包括顶部的<<<...、底部的>>>... 和中间的====。编辑完所有冲突的文件后，像往常一样使用git add 添加它们并提交。
【讨论】：
看起来您遇到了某种合并冲突。 git 会告诉你它和什么文件。 运行 git conflict 来启动和修复它们。
始终 git rebase -i origin..... 并将本地提交压缩为单个提交。这会将您的提交重播到作为单个提交出现的最新 HEAD 上。然后，您将不得不通过 git 冲突处理任何冲突。然后最后 git rebase --continue 和 git push .还记得在你变基之前 git fetch origin！
编辑 感谢我们博学的朋友，我现在意识到这些时髦的角色在远程。所以我上面的回答现在只是提醒人们如何在正常实践中工作。请务必阅读以下内容。
https://www.atlassian.com/git/tutorials/comparing-workflows/centralized-workflow
【讨论】：
-
这很少是国际海事组织的正确答案。我看到很多人在整理的狂热中疯狂地使用 rebase，最终导致在调查错误、挑选补丁或恢复更改时几乎毫无价值的巨大提交。另外，根据你的 rebase 的进展情况，重写你的历史记录非常容易，这样强制推送会导致团队其他成员难以保持同步。
-
你这么疯狂是为了什么？您只需在最新代码之上进行更改；在查看您会看到单个提交的历史记录时，保持您的更改干净整洁。在我工作的地方，我经常向我的本地分支 rebase 提交，将我的提交压缩成一个提交，然后推送。没有强制力。我想你错过了理解我的答案。
-
如果你因为人们正在做大量的大型工作而失去历史，然后挤压提交。这很容易被具有一些基本内务管理技能的开发人员绕过，为每个工作项创建分支并通过拉取请求将它们变为 master。
-
首先，我同意你的观点，rebase 是一个很棒的（可能是最好的也是我最喜欢的）策略，它可以让功能分支保持最新，以便轻松快速合并回 master。但是，从 OP 中不清楚该上下文是否在起作用。它表示这些未解决的冲突消息实际上已提交到源代码并推送到远程。没有指定分支，所以如果这是主分支，那么 rebase 修复将需要重写历史记录和强制推送，因此会破坏每个人的 FF 拉取。
-
啊，我明白了。 100%同意你。我没有意识到 OP 实际上已经成功推动。就像您建议的那样，最好的行动原因可能是确实解决这个问题并推动新的提交而不是强制推动。与其他人一起在主分支上强行推动可能会变得很重。特别是如果其他贡献者不知道发生了什么欺诈行为或经验不足。