2014-04-01 83 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並再次開心。那是什麼解決了我們的問題。