zoukankan      html  css  js  c++  java
  • Git处理 行结束符

    Dealing with line endings (Windows)

    如果你正在使用Git在GitHub上和别人协作的话,确保Git处理行结束符的配置已经正确配置了。

    每次在键盘上按下return键时,实际上你正在插入一个称之为行结束符(line ending)的不可见字符。由于历史的原因,不同的操作系统处理行结束符的方式的不一样的。

    当你查看一个文件的变更时,Git会以它自己的方式处理行结束符。因为你在项目中使用Git和GitHub进行协作,Git可能产生预料外的结果。比如你在Windows系统上工作,而你的协作者是在OS X上做的变更。

    针对行结束符的全局设定

    git config core.autocrlf命令被用来改变Git处理行结束符的方式。它接受一个单一的参数。

    在Windows中,简单地传递true给这个配置。比如:

    $ git config --global core.autocrlf true
    # Configure Git on Windows to properly handle line endings

    每个库的设定

    你可以选择通过配置一个特殊的.gitattributes文件在每个库的基础上配置Git管理行结束符的方式。这个文件被提交给库并且覆盖一个各自的core.autocrlf设置,确保所有用户行为的一致性,而不管他们的Git设置。.gitattributes文件的优势是你的配置和你的库相关。你不需要担心你的协作者是否和你有相同的配置。

    .gitattributes文件必须在库的根目录创建并像其他文件一下提交。

    .gitattributes文件就像包含两列的表:

    左边是给Git去匹配的文件名。

    右边是Git将会用于文件的行结束符配置。

     .gitattributes 文件例子,使用它作为你的库的模板:

    # Set the default behavior, in case people don't have core.autocrlf set.
    * text=auto
    
    # Explicitly declare text files you want to always be normalized and converted
    # to native line endings on checkout.
    *.c text
    *.h text
    
    # Declare files that will always have CRLF line endings on checkout.
    *.sln text eol=crlf
    
    # Denote all files that are truly binary and should not be modified.
    *.png binary
    *.jpg binary

    你注意到文件被 *c,*.sln,*.png匹配,一个空格分割,然后是设置,text,text eof=crlf,binary。

    下面是一些可能的设置:

    text=auto Git以它认为最好的方式处理文件。这是个好的默认选项。

    text eof=crlf 在checkout时,Git总是将文件结束符转换为CRLF。对于必须保留CRLF结尾的文件,即便是在Linux或OS X中,你也应该使用它。

    text eof=lf 在checkout时,Git总是将文件结束符转换为LF。对于必须保留LF结尾的文件,即便是在Windows中,你也应该使用它。

    binary Git会理解指定的文件不是文本,它就不会尝试去改变它们。这个设定是-text -diff 的别名。

    在变更行结束符设置后刷新库

    在你设定core.autocrlf配置,提交.gitattributes文件之后,你可能发现Git想去提交你未变更的文件。此时,Git是想为你改变每个文件的行结束符。

    自动配置你的库的行结束符的最好方法是首先用Git备份你的文件,删除你的库(除了.git目录),然后立即恢复所有文件。

    1.在Git中保存当前的文件,那么你的工作就不会丢失。

    $ git add . -u
    $ git commit -m "Saving files before refreshing line endings"

    2.删除index,强制Git再扫描工作目录。

    $ rm .git/index

    3.重写Git的index,获取新的行结束符。

    $ git reset

    4.显示重写后的规范化文件 。

    $ git status

    5.将你变更的文件复原,准备提交。可以用这个机会检查哪些文件没有被改变。

    $ git add -u
    # It is perfectly safe to see a lot of messages here that read
    # "warning: CRLF will be replaced by LF in file."

    6.重写.gitattributes 文件。

    $ git add .gitattributes

    7.将你的改变提交到库中。

    $ git commit -m "Normalize all the line endings"

     测试

    1.在Windows中创建一个文本文件file1.txt,提交,push

    2.在Linux中git clone,看到文件行结束符是CRLF

    3.添加.gitattributes文件,设置Git以它认为适当的方式处理行结束符。直接commit,push

    4.在Linux中git clone,看到文件行结束符依然是CRLF

    5.按照【在变更行结束符设置后刷新库】设置后,在Linux中git clone,看到文件行结束符变为LF

     6.强制.txt设置为LF

    7.按照【在变更行结束符设置后刷新库】设置后 以及 在Windows中创建一个文本文件file2.txt,提交,push

    8.工作目录中的file1.txt,file2.txt还是CRLF,但是在Windows另一个文件夹中git clone,它们的行结束符变为LF。

     似乎在checkout时,文件的行结束符可以保证和配置中一致,但是原来的工作目录中似乎并没有改变。

  • 相关阅读:
    Linux下常用软件安装(tar bz gz等压缩包的压缩和解压)
    《那些年啊,那些事——一个程序员的奋斗史》五
    IT人士 不能一辈子靠技术生存
    十八年开发经历小结
    《那些年啊,那些事——一个程序员的奋斗史》一
    软件工程及软件项目开发流程
    《那些年啊,那些事——一个程序员的奋斗史》三
    AJAX技术解读
    全程追踪入侵JSP网站服务器
    《C语言程序设计》教学的几点体会
  • 原文地址:https://www.cnblogs.com/niaomingjian/p/8445314.html
Copyright © 2011-2022 走看看