2014-04-01 46 views
3

我们所有的开发人员都在windows机器上工作,并且在Linux上完成构建。再次在git-line结尾

为了符合的真实方法我们决定标准化行结束并按照情景described on GitHub

后来似乎不时地从一个分支切换到另一个分支时,有些文件被标记为已更改,而未检测到内容更改。

然后,我遇到了GitBook documentation行结束和其正常化。我想知道这两种方法有什么区别?

git rm --cached -r . 
# Remove everything from the index. 

git reset --hard 
# Write both the index and working directory from git's database. 

git add . 
# Prepare to make a commit by staging all the files that will get normalized. 
# This is your chance to inspect which files were never normalized. You should 
# get lots of messages like: "warning: CRLF will be replaced by LF in file." 

git commit -m "Normalize line endings" 
# Commit 

$ rm .git/index  # Remove the index to force git to 
$ git reset   # re-scan the working directory 
$ git status  # Show files that will be normalized 
$ git add -u 
$ git add .gitattributes 
$ git commit -m "Introduce end-of-line normalization" 

因为这两个给出不同git status组文件。

什么时候应该将标准化文件推送到远程?

UPD:这是一个情况下运行git命令和分支之间切换时,我有:

>git status 
on develop, no changes 

>git checkout -t origin/BRANCH-1 && git status 
Branch BRANCH-1 set up to track remote branch GPIII-96 from origin. 
Switched to a new branch 'BRANCH-1' 
modified: A.java 
modified: B.java 
modified: C.java 

>file A.java 
A.java: ASCII text, with CRLF line terminators 

>git rm --cached -r . && git reset --hard && git status 
# On branch BRANCH-1 
nothing to commit (working directory clean) 

*WTF??* 

>git checkout develop -f && git status 
modified: D.java 

*WTF???* 

>git checkout BRANCH-1 -f && git status 
modified: A.java 
modified: B.java 
modified: C.java 

*WTF???* 

回答

1

我也曾经有过同样的问题。我只能给你一个建议。

对我来说,它不是一个VCS的工作来管理我们的行结束。它是开发人员或IDE的工作。因此,在你的行尾标准化一次后,将windows机器IDE的行结尾切换到Unix-Line-Endings并再次开心。那是什么解决了我们的问题。