如何让Git忽略空格和制表符?

如何让Git忽略空格和制表符?,git,diff,indentation,Git,Diff,Indentation,我有一个小的脚本项目,在一个名为“Droid XX-XX-XX”的目录中包含五个不同的源文件。每次创建源目录的新备份副本时,我都将日期放在X中。因此,在不同的日期有大约15个不同的版本。我想从最早的时候开始,将它们添加到我的新Git存储库中 然而,我遇到了几个问题 一个问题是,一些文件使用制表符进行缩进,而另一些文件使用空格——但Git将整行视为不同的,即使唯一的区别是制表符与空格的问题。如何使Git忽略缩进格式 另一个问题是,一些文件名没有空格,而另一些文件名在单词之间有空格——但Git将它们

我有一个小的脚本项目,在一个名为“Droid XX-XX-XX”的目录中包含五个不同的源文件。每次创建源目录的新备份副本时,我都将日期放在X中。因此,在不同的日期有大约15个不同的版本。我想从最早的时候开始,将它们添加到我的新Git存储库中

然而,我遇到了几个问题

  • 一个问题是,一些文件使用制表符进行缩进,而另一些文件使用空格——但Git将整行视为不同的,即使唯一的区别是制表符与空格的问题。如何使Git忽略缩进格式

  • 另一个问题是,一些文件名没有空格,而另一些文件名在单词之间有空格——但Git将它们视为不同的文件。更糟糕的是,有时文件名被更改为其他文件(例如“PatrolPlan”更改为“Patrol”),而没有真正的原因。当我添加一组新文件时,我如何告诉Git,即使文件名不同,它实际上只是某个旧文件的新版本?或者更好的是,我可以将其设置为在发生这种情况时自动检测吗

  • 最后一个问题是,在开发过程中的某些时候,我们将两个源文件合并为一个,或者将一个源文件拆分为两个——但Git不会自动检测相似性并推断发生了什么。我怎么能告诉Git发生了什么?或者更好的是,如何将其设置为自动检测两个源文件的组合时间或一个源文件的拆分时间

  • 我意识到问题(2)和(3)是高度相关的。谢谢你的帮助

  • 您将无法使git忽略制表符/空格,因为git会为每个文件创建一个散列,如果散列不同,则认为文件不同

  • Git将树(目录)视为文件;如果它们的内容发生变化,则它们是不同的树

  • 然而,我不认为这些变化有什么值得担心的;它们发生在任何开发过程中。我认为最好的方法是使用git重放您的开发。换句话说,从您的初始版本开始,然后进行必要的更改(就像您最初做的那样),git将记住您正在做的事情


    可选:如果您想将更改的日期/时间大致记录为原始更改的日期/时间,那么可以使用
    --date
    命令行选项
    git commit
    告诉git这些更改是何时进行的。

    听起来您需要对开发过程进行更多的控制和标准化。提交更改的人应该是修改文件的人。或者至少提交者应该确切地知道发生了什么变化

    仔细检查
    git diff
    的输出,并使用
    -w
    标志忽略空格。还有一些选项可以显示一行中的差异。请参见下面一行中的差异

    请注意,在提交时,您不能告诉git跳过空间更改。我建议使用GitX(我更喜欢“brotherbard”fork),它允许您在提交之前以交互方式丢弃大块

    提交时使用描述性消息。例如,如果一个文件被拆分,请这样说。把你的承诺变小。如果您发现自己正在编写较长的提交消息,请将提交分解为较小的部分。这样,当您在很长一段时间后检查日志时,您将更清楚更改了什么

    线内的差异

    Git能够在一行中显示“单词”的差异。最简单的方法是只使用
    git diff--color words

    但是,我喜欢使用
    diff.wordRegex
    config自定义“单词”的含义。我还喜欢
    plain
    word diff格式,因为它更清楚地显示了差异所在(除了使用颜色外,在更改周围插入括号)

    命令:

    git diff --word-diff=plain
    
    在我的配置中还包括:

    [diff]
            wordRegex = [[:alnum:]_]+|[^[:alnum:]_[:space:]]+
    
    此正则表达式将这些视为“单词”:

    • 字母数字和下划线的连续字符串
    • 非字母数字、非下划线和非空格的连续字符串(用于检测运算符)
    您必须拥有最新版本的
    git
    才能使用
    wordRegex
    。查看
    git config
    手册页,查看是否列出了该选项

    更新

    如果使用
    git mv
    重命名文件(这比使用其他工具或操作系统重命名更可取),则可以看到git检测到重命名。我强烈建议独立于对文件内容的任何编辑提交重命名。这是因为git实际上并没有存储您重命名的事实——它使用一种基于文件更改程度的启发式方法来猜测它是否是同一个文件。在重命名提交期间更改的越少越好


    如果确实稍微更改了文件内容,可以使用
    -C
    param to
    git diff
    git log
    更努力地检测副本和重命名。添加一个百分比(例如,
    -C75%
    ),使git对差异更加宽容。百分比表示内容的相似程度才能被视为匹配。

    现在我对Git有了更多的了解,我可以回答自己的问题了

  • 最好使用regex进行全局搜索替换,以标准化项目不同版本中所有文件之间的空白,这样当它们按顺序提交时,空白更改就不需要提交。话虽如此,Atlassian SourceTree的diff工具允许您隐藏空白更改,所以至少您不会看到这些更改

  • 处理文件名更改的关键是在只有文件名更改的情况下进行提交(不要进行任何其他更改)。然后在其内容发生更改时进行提交。通过这种方式,普通的diff工具不需要进行大量的启发式和深度挖掘,就可以理解h