Все наши разработчики работают на машинах Windows, а сборка выполняется на Linux.

Чтобы соответствоватьверный путь мы решили нормализовать окончания строк и следовать сценариюописано на GitHub.

Позже выяснилось, что время от времени при переключении с одной ветви на другую некоторые файлы помечаются как измененные, а изменения содержимого не обнаруживаются.

Потом я столкнулся сGitBook документация на концах строки и ее нормализации.

Так мне интересноВ чем разница между этими двумя подходами?:

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