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???*