我需要帮助理解这种情况下的git rebase。我检查了10天前创建的分支机构。我用
检查了一下git checkout -b <some name> origin/branchname
（我只是用不同的名字来识别它）
结帐后，如果我通过这个签出的分支进行变基，
git rebase origin/master
它显示了一些错误 1）尾随空白 - 我读到了这个但是即使在尝试了我在网上找到的这个命令之后，我仍然会看到警告。
git config core.whitespace nowarn
2）自动合并 CONFLICT（添加/添加）：合并冲突... 这些文件在master分支中，但在checkout分支中稍微修改了内容。那我该怎么办呢？如果这是修复它的方法，我无权直接更改master中的任何内容。这些文件应该包含来自此checkout分支的内容，以便测试工作正常，因为它与...相关...请澄清我..
问候
答案 0 :(得分：2)
伙计们已经回答了关于空白的问题，但没有触及问题的基础部分。以下是你改变时发生的事情：
首先检查一些分支，然后你说：
git rebase master
这意味着您想将当前的HEAD（您的主题分支）重新绑定到master上。
Git将在您的主题分支的历史记录和主分支的历史记录中找回并发现一个提交，它是两者的第一个共同祖先。此提交将是您的主题分支的旧基础。然后它将从那时起在你的分支中进行所有提交，并按照当前主服务器顶部的出现顺序“重新应用”它们。有时可能会发生冲突，然后rebase进程停止并等待您的解决。因此，您必须通过编辑文件手动解决它们，然后通过git add conflicted_file将其标记为已解决
完成后，您将不得不说git rebase --continue
现在你不是通过这样做来更改master分支中的文件 - 更改发生在主题分支中，冲突解决方案会记录在主题分支中。
希望有所帮助。答案 1 :(得分：1)
如果你提到的问题是“git svn windows linux whitespace problems”，那么命令就是：
git config core.whitespace nowarn
git config core.autocrlf true
（将这些设置区域设置保留到当前仓库）
这将强制所有文件采用一个eol样式，防止origin / master上的文件具有相同的行，而不同的eol使您自己的副本变为rebase（这将解释CONFLICTS (add/add)错误消息）。
但我仍然对autocrlf true持怀疑态度，而更喜欢managing eol style through .gitattributes files。
答案 2 :(得分：0)
cd进入您的回购邮件的.git文件夹。如果您使用的文件资源管理器未显示隐藏文件或前面带有.或_的文件，则可能看不到此文件夹。在.git文件夹中，您将拥有一个名为config的文件。在文本编辑器中打开它，您应该能够看到名为[core]的部分。在那里添加whitespace = nowarn。如果您使用的是Linux机器，则可以在.gitconfig目录下找到home的另一个位置。如果它在Windows上，它取决于你如何安装git（通过cygwin或msysgit）。
如果msysgit在.gitconfig文件的位置看到此问题（Where does git config --global get written to?）。如果是cygwin，那么你可以通过cat ~/.gitconfig看到它的内容。