我们是两个开发人员，在同一个分支中从事同一个项目。开发人员'A'正在做少量重构工作，这将影响150个文件，而开发人员'B'正在处理大约30个文件的子集。 开发人员'B'已检入更改（30个文件），开发人员'A'从远程存储库中提取了最新更改，其中包括开发人员'B'的更改，但出现以下错误消息
错误：您对以下文件的本地更改将被覆盖 通过合并：File1 file2 ........... File 50
现在的问题是，由于合并相关的错误消息（包括对50个文件的影响），导致Pull未成功发生。 开发人员'A可以做什么以将其更改推送到远程位置而又不影响开发人员'B'的更改？
答案 0 :(得分：1)
TL; DR
Dev B应该使用Git的帮助来解决冲突，将其工作保存在私有分支中，获取Dev A的更改，然后将其全部合并。
问题
尽管开发人员A的方法将为他人创造工作，但开发人员B需要更改他们获取A的工作以保护自己的方式。在这种情况下，您将达到git pull提供的自动化极限。
git pull结合了几种操作：
git fetch-从远程获取更改git merge-将origin/branch合并到本地branch 前两个操作是安全的，因为如果您不喜欢结果，合并是完全可逆的。
但是第三项操作必须涉及您的本地更改，并且在某些情况下可能会损坏您的工作目录，这就是Git检测到并警告开发人员B的原因。关于本地更改的任何合并冲突都应导致该消息。
最简单的解决方案：本地提交
Dev B可以将更改提交到其本地branch并重新建立基础或与远程的合并。我个人更喜欢私有分支给我的附加控件（请参见下文），但是此选项花费的步骤更少，因此您可能更喜欢它：
git commit -a -m'description'
git fetch
检查branch和origin/branch之间的差异，然后选择git rebase origin/branch或git merge origin/branch并使用git mergetool解决所有冲突。
更多控制权：创建私人分支
Dev B还可以选择将其工作提交到私有dev分支中，之后可以将其重新建立到branch上，
git checkout -b dev.protecting-my-work
git commit -a -m'work in progress'
然后返回共享的branch并对其进行更新
git checkout branch
git fetch
# inspect what been fetched before merging:
git log --decorate --graph --format=oneline branch origin/branch
git merge # or maybe git rebase, that's what I prefer
# use git mergetool to resolve conflicts, if any
这时，开发人员B将在单独的分支中对A及其所做的更改进行保存，所有工作均被保存和保护。您从一开始就知道合并它们会导致冲突，但是现在Git将帮助您处理它们：
git checkout dev.protecting-my-work
git rebase `branch` # see possibly lots of conflicts
loop until rebase is complete:
git mergetool # resolve conflicts manually
git rebase --continue
然后开发人员B可以在私有分支上完成工作，使用git rebase -i清理历史记录，与branch合并，并在完成后推送并清理。
有关变基的说明
您会注意到，我建议在以上几种情况下进行基础调整，但是它们都有一个共同点：它们都涉及对尚未推送的本地提交进行基础调整。这就是我认为安全的基础。不要根据您之前推送的内容进行修改。
PS
Git可以为您节省这种绑定的方式，但是我想说，像Dev A这样的重构在理想情况下应该包括要求同事推迟对同一存储库的其他更改。并行工作的每个其他人都在处理“肮脏”的代码，无论您做什么，都会引起冲突。
答案 1 :(得分：0)
必须开发：