Prawie cztery lata po zadaniu tego pytania w końcu znalazłem odpowiedź, która całkowicie mnie satysfakcjonuje !
Zobacz szczegóły w github: przewodnik
pomocy Jak radzić sobie z zakończeniami linii .
Git pozwala ustawić właściwości zakończenia linii dla repo bezpośrednio za pomocą atrybutu text w
.gitattributes
pliku. Ten plik jest przypisany do repozytorium i zastępuje core.autocrlf
ustawienie, umożliwiając zapewnienie spójnego zachowania wszystkim użytkownikom, niezależnie od ich ustawień git.
A zatem
Zaletą tego jest to, że konfiguracja na końcu linii przemieszcza się teraz z repozytorium i nie musisz się martwić, czy współpracownicy mają odpowiednie ustawienia globalne.
Oto przykład .gitattributes
pliku
# Auto detect text files and perform LF normalization
* text=auto
*.cs text diff=csharp
*.java text diff=java
*.html text diff=html
*.css text
*.js text
*.sql text
*.csproj text merge=union
*.sln text merge=union eol=crlf
*.docx diff=astextplain
*.DOCX diff=astextplain
# absolute paths are ok, as are globs
/**/postinst* text eol=lf
# paths that don't start with / are treated relative to the .gitattributes folder
relative/path/*.txt text eol=lf
Istnieje wygodny zbiór gotowych do użycia plików .gitattributes dla najpopularniejszych języków programowania. Dobrze jest zacząć.
Po utworzeniu lub dostosowaniu .gitattributes
należy wykonać ponowną normalizację zakończeń linii raz na zawsze .
Pamiętaj, że aplikacja GitHub Desktop może zasugerować i utworzyć .gitattributes
plik po otwarciu repozytorium Git projektu w aplikacji. Aby spróbować, kliknij ikonę koła zębatego (w prawym górnym rogu)> Ustawienia repozytorium ...> Zakończenia linii i atrybuty. Zostaniesz poproszony o dodanie zalecanego, .gitattributes
a jeśli się zgodzisz, aplikacja wykona również normalizację wszystkich plików w repozytorium.
Wreszcie artykuł Mind the End of Your Line zawiera więcej informacji i wyjaśnia, w jaki sposób Git ewoluował w omawianych sprawach. Uważam to za konieczne czytanie .
Prawdopodobnie masz w swoim zespole użytkowników, którzy używają EGit lub JGit (narzędzia takie jak Eclipse i TeamCity używają ich) do zatwierdzania swoich zmian. Nie masz szczęścia, jak wyjaśnił @gatinueta w komentarzach do tej odpowiedzi:
To ustawienie nie zadowoli Cię całkowicie, jeśli masz w zespole osoby pracujące z Egit lub JGit, ponieważ narzędzia te po prostu zignorują atrybuty .git i z przyjemnością sprawdzą pliki CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372
Jedną sztuczką może być zmuszenie ich do wprowadzenia zmian w innym kliencie, powiedzmy SourceTree . Nasz zespół wolał wtedy to narzędzie od EGit Eclipse w wielu przypadkach użycia.
Kto powiedział, że oprogramowanie jest łatwe? : - /
.gitattributes
?.gitattributes
GitHub dla Windows sugeruje dla twojego projektu? Zainstalowałem GitHub dla Windows, uruchomiłem wersję GUI i nie mogłem znaleźć żadnej opcji związanej z.gitattributes
sugestiami.core.autocrlf = false
- wolę LF wszędzie, ale niektóre narzędzia Windows, takie jak Visual Studio, nalegają na zakończenie CRLF w niektórych plikach (a nawet mieszają je w kilku ...); nie mungowanie zakończeń linii jest najbezpieczniejszą opcją. Jeśli wiesz, co robisz, prawdopodobniecore.autocrlf = input
użyłbym wyjątków dla projektów w systemie Windows, o których wiesz, że są wrażliwe na zakończenia linii. Jak podkreślają inni, każdy porządny edytor tekstu obsługuje teraz zakończenia LF. Myślę, żecore.autocrlf = true
prawdopodobnie może powodować więcej problemów, niż to zapobiega.Nie przekształcaj zakończeń linii. Interpretacja danych nie jest zadaniem VCS - wystarczy je zapisać i zaktualizować. Każdy nowoczesny edytor tekstu może odczytać oba rodzaje zakończeń linii.
źródło
Prawie zawsze chcesz,
autocrlf=input
chyba że naprawdę wiesz, co robisz.Dodatkowy kontekst poniżej:
Powyższy akapit został pierwotnie pobrany z wątku na gmane.org, ale od tamtej pory został usunięty.
źródło
core.autocrlf=input
jest kanoniczną odpowiedzią. W większości przypadków użycia,core.autocrlf=true
acore.autocrlf=false
są zbyt gorliwi (... w przeciwną ale równie strasznych sposobów, oczywiście), a więc z natury destrukcyjne. „Git dla Windows” powinien być naprawdę dostarczany z „Checkout as-is, commit end-line-style end-line end” (tj.core.autocrlf=input
) Jako domyślną strategią nowej linii. Nie udało się. Więc tutaj jesteśmy - w cholernym 2015 roku - wciąż bez końca debatujemy nad tym.Dwie alternatywne strategie pozwalające uzyskać spójność zakończeń linii w środowiskach mieszanych (Microsoft + Linux + Mac):
A. Konfiguracja globalna dla wszystkich repozytoriów
1) Konwertuj wszystko na jeden format
2) Zestaw
core.autocrlf
doinput
na Linux / Unix lubtrue
na MS Windows (repozytorium lub globalne)3) [Opcjonalnie] ustaw
core.safecrlf
natrue
(aby zatrzymać) lubwarn
(aby śpiewać :), aby dodać dodatkową ochronę, porównując, czy odwrócona transformacja nowego wiersza da ten sam plikB. Lub według konfiguracji repozytorium
1) Konwertuj wszystko na jeden format
2) dodaj
.gitattributes
plik do swojego repozytoriumNie martw się o swoje pliki binarne - Git powinien być wystarczająco inteligentny.
Więcej informacji o zmiennych safecrlf / autocrlf
źródło
dos2unix
to narzędzie wiersza polecenia, które w zależności od systemu może wymagać dodatkowej instalacjidos2unix
- istnieje ryzyko uszkodzenia.git/index
i nie musimy stosować go do każdego pliku. Lepiej jest użyć czegoś takiegofind ./ -name "*.html"
i określić, do których plików chcesz go zastosować.find
linii należy pamiętać:dos2unix
dostarczane z Git dla Windows ma specyficzne (idiotyczne i niebezpieczne) IMO, bez argumentów: zamiast przejścia na UNIX, przełącza format nowej linii (DOS <-> UNIX )Spróbuj ustawić
core.autocrlf
opcję konfiguracji natrue
. Zobacz takżecore.safecrlf
opcję.Właściwie to wygląda na to, że
core.safecrlf
może być już ustawione w twoim repozytorium, ponieważ (moje wyróżnienie):W takim przypadku możesz sprawdzić, czy edytor tekstu jest skonfigurowany do spójnego używania zakończeń linii. Prawdopodobnie wystąpią problemy, jeśli plik tekstowy zawiera mieszaninę zakończeń linii LF i CRLF.
Wreszcie, uważam, że zalecenie, aby po prostu „użyć tego, co otrzymałeś” i użyć linii zakończonych LF w systemie Windows spowoduje więcej problemów niż rozwiązuje. Git ma powyższe opcje, aby rozsądnie traktować zakończenia linii, więc warto z nich korzystać.
źródło
Użycie
core.autocrlf=false
zatrzymało oznaczanie wszystkich plików jako zaktualizowane, gdy tylko je sprawdziłem w projekcie Visual Studio 2010 . Pozostali dwaj członkowie zespołu programistycznego również używają systemów Windows, więc mieszane środowisko nie wchodziło w grę, ale ustawienia domyślne dostarczone z repozytorium zawsze oznaczały wszystkie pliki jako zaktualizowane natychmiast po klonowaniu.Wydaje mi się, że najważniejsze jest ustalenie, jakie ustawienie CRLF działa w twoim środowisku. Zwłaszcza, że w wielu innych repozytoriach w naszym systemie Linux ustawienie pudełek
autocrlf = true
daje lepsze wyniki.Ponad 20 lat później nadal mamy do czynienia z różnicami w końcowych liniach między systemami operacyjnymi ... smutne.
źródło
Są to dwie opcje dla użytkowników Windows i Visual Studio, którzy współużytkują kod z użytkownikami komputerów Mac lub Linux . Aby uzyskać szczegółowe wyjaśnienie, przeczytaj instrukcję gitattributes .
* tekst = auto
W
.gitattributes
pliku repozytorium dodaj:Spowoduje to normalizację wszystkich plików z
LF
zakończeniami linii w repozytorium.W zależności od systemu operacyjnego (
core.eol
ustawienia) pliki w drzewie roboczym zostaną znormalizowane doLF
systemów opartych na Uniksie lubCRLF
systemów Windows.Jest to konfiguracja używana przez repozytorium Microsoft .NET .
Przykład:
Będzie znormalizowany w repozytorium zawsze jako:
Podczas realizacji transakcji działające drzewo w systemie Windows zostanie przekonwertowane na:
Przy kasie działające drzewo w Macu pozostanie jako:
core.autocrlf = true
Jeśli nie
text
jest określony w.gitattributes
pliku, Git używacore.autocrlf
zmiennej konfiguracyjnej do ustalenia, czy plik powinien zostać przekonwertowany.Dla użytkowników systemu Windows
git config --global core.autocrlf true
jest świetną opcją, ponieważ:LF
zakończeń linii tylko po dodaniu do repozytorium. Jeśli w repozytorium znajdują się pliki, które nie są znormalizowane, to ustawienie ich nie dotknie.CRLF
zakończenia linii w katalogu roboczym.Problem z tym podejściem polega na tym, że:
autocrlf = input
, zobaczysz kilka plików zLF
zakończeniami linii. Nie stanowi to zagrożenia dla reszty zespołu, ponieważ twoje zobowiązania nadal będą znormalizowane zLF
zakończeniami linii.core.autocrlf = false
, zobaczysz kilka plików zLF
zakończeniami linii i możesz wprowadzić pliki zCRLF
zakończeniami linii do repozytorium.autocrlf = input
i może pobierać pliki zCRLF
końcówkami, prawdopodobnie od użytkowników systemu Windows zcore.autocrlf = false
.źródło
git config --global core.autocrl true
. Masz na myśligit config --global core.autocrlf true
.--- UPDATE 3 --- (nie koliduje z UPDATE 2)
Biorąc pod uwagę przypadek, w którym użytkownicy systemu Windows wolą pracować,
CRLF
a użytkownicy systemu Linux / Mac wolą pracować nadLF
plikami tekstowymi. Udzielenie odpowiedzi z perspektywy opiekuna repozytorium :Dla mnie najlepszą strategią (mniej problemów do rozwiązania) jest: zachowaj wszystkie pliki tekstowe z
LF
wewnętrznym repozytorium git, nawet jeśli pracujesz nad projektem tylko dla systemu Windows. Następnie daj klientom swobodę pracy nad stylem końca preferencji , pod warunkiem, że wybiorącore.autocrlf
wartość właściwości, która będzie szanować twoją strategię (LF przy repo) podczas przemieszczania plików do zatwierdzenia.Inscenizacja jest tym, co wiele osób myli, próbując zrozumieć, jak działają strategie nowej linii . Przed wybraniem właściwej wartości
core.autocrlf
właściwości należy koniecznie zrozumieć następujące punkty :.git/
podkatalogu z przekonwertowane line-zakończeń (w zależności odcore.autocrlf
wartości na swojej konfiguracji klienta). Wszystko to odbywa się lokalnie.core.autocrlf
jest jak udzielenie odpowiedzi na pytanie (dokładnie to samo pytanie na wszystkich systemach operacyjnych):false:
„ nie rób nic z powyższych ”,input:
„ Nie tylko b ”true
: „ zrób aib ”na szczęście
core.autocrlf: true
:, linux / mac:)core.autocrlf: false
będą zgodne ze strategią repo tylko LF .Znaczenie : klienci Windows domyślnie przekonwertują na CRLF podczas sprawdzania repozytorium i konwertują na LF podczas dodawania do zatwierdzenia. Klienci Linuksa domyślnie nie wykonują żadnych konwersji. Teoretycznie zachowuje to tylko twoje repozytorium.
Niestety:
core.autocrlf
wartości gitcore.autocrlf=false
i dodają plik z CRLF do zatwierdzenia.Aby wykryć ASAP inne niż tekstowe pliki tekstowe zatwierdzone przez powyższych klientów , możesz postępować zgodnie z opisem w --- aktualizacja 2 ---: (
git grep -I --files-with-matches --perl-regexp '\r' HEAD
, na kliencie skompilowanym przy użyciu:--with-libpcre
flag)I tu jest haczyk: . Jako opiekun repo przechowuję plik,
git.autocrlf=input
dzięki czemu mogę naprawić wszelkie nieprawidłowo popełnione pliki, dodając je ponownie w celu zatwierdzenia. I dostarczam tekst zatwierdzenia: „Naprawianie nieprawidłowo zatwierdzonych plików”.O ile
.gitattributes
jest to uzasadnione. Nie liczę na to, ponieważ jest więcej klientów interfejsu użytkownika, którzy tego nie rozumieją. Używam go tylko do udzielania wskazówek dla plików tekstowych i binarnych, a może oznaczam wyjątkowe pliki, które powinny wszędzie mieć te same zakończenia linii:Pytanie: Ale dlaczego w ogóle interesuje nas strategia obsługi nowego wiersza?
Odpowiedź: Aby uniknąć zatwierdzenia zmiany jednej litery, wyświetlaj się jako zmiana 5000-wierszowa , tylko dlatego, że klient, który dokonał zmiany, automatycznie przekonwertował pełny plik z crlf na lf (lub odwrotnie) przed dodaniem go do zatwierdzenia. Może to być dość bolesne, gdy w grę wchodzi rozwiązanie konfliktu . Lub może w niektórych przypadkach być przyczyną nierozsądnych konfliktów.
--- AKTUALIZACJA 2 ---
Awarie klienta git będą działać w większości przypadków. Nawet jeśli masz tylko klientów Windows, tylko Linux lub oba. To są:
core.autocrlf=true
oznacza konwersję linii do CRLF przy kasie i konwersję linii do LF podczas dodawania plików.core.autocrlf=input
oznacza, że nie należy konwertować linii przy kasie (nie ma takiej potrzeby, ponieważ oczekuje się, że pliki zostaną zatwierdzone w LF) i konwertuj linie do LF (jeśli to konieczne) podczas dodawania plików. ( - update3 - : Wydaje się, że jest tofalse
domyślnie, ale znowu jest w porządku)Właściwość można ustawić w różnych zakresach. Sugerowałbym wyraźne ustawienie
--global
zakresu, aby uniknąć niektórych problemów IDE opisanych na końcu.Również zdecydowanie odradzałbym używanie w systemie Windows
git config --global core.autocrlf false
(jeśli masz tylko klientów Windows) w przeciwieństwie do tego, co proponuje się w dokumentacji git . Ustawienie wartości false spowoduje zatwierdzenie plików z CRLF w repozytorium. Ale tak naprawdę nie ma powodu. Nigdy nie wiadomo, czy będziesz musiał udostępnić projekt użytkownikom Linuksa. Dodatkowo jest to jeden dodatkowy krok dla każdego klienta, który dołącza do projektu zamiast korzystać z ustawień domyślnych.Teraz w przypadku niektórych specjalnych przypadków plików (np.
*.bat
*.sh
), Które chcesz, aby zostały wyewidencjonowane za pomocą LF lub CRLF, możesz użyć.gitattributes
Podsumowując, dla mnie najlepszą praktyką jest:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
( Uwaga: w systemach Windows klienci działają tylko przez,git-bash
a na klientach z systemem Linux tylko, jeśli są skompilowani przy użyciu--with-libpcre
in./configure
).core.autocrlf=input
( --- aktualizacja 3 - ).gitattributes
core.autocrlf
wyżej opisane wartości domyślne..gitattributes
. git-klienci IDE mogą je ignorować lub traktować inaczej.Jak już wspomniano, niektóre atrybuty git można dodać:
Myślę, że istnieją inne bezpieczne opcje
.gitattributes
zamiast używania automatycznego wykrywania plików binarnych:-text
(np. dla plików*.zip
lub*.jpg
: nie będzie traktowany jak tekst. W związku z tym nie będą podejmowane próby konwersji na końcu linii. Różnice mogą być możliwe w programach do konwersji)text !eol
(np*.java
,*.html
:.. Traktowana jako tekst, ale preferencji styl EOL nie jest tak ustawiony ustawienie klient jest używany)-text -diff -merge
(np. dla*.hugefile
: Nie jest traktowany jako tekst. Brak możliwości porównania / scalenia)--- POPRZEDNIA AKTUALIZACJA ---
Jeden bolesny przykład klienta, który nieprawidłowo zatwierdza pliki:
netbeans 8.2 (w systemie Windows), nieprawidłowo zatwierdza wszystkie pliki tekstowe z CRLF-ami, chyba że jawnie ustawisz
core.autocrlf
jako globalny . Jest to sprzeczne ze standardowym zachowaniem klienta git i powoduje wiele problemów później, podczas aktualizacji / scalania. To sprawia, że niektóre pliki wyglądają inaczej (chociaż nie są) nawet po przywróceniu .To samo zachowanie w netbeansie dzieje się, nawet jeśli poprawnie dodałeś
.gitattributes
projekt.Użycie następującego polecenia po zatwierdzeniu pomoże przynajmniej wcześnie wykryć, czy w repozytorium git występują problemy z zakończeniem linii:
git grep -I --files-with-matches --perl-regexp '\r' HEAD
Spędziłem godziny, aby wymyślić jak najlepsze wykorzystanie.gitattributes
, aby w końcu uświadomić sobie, że nie mogę na to liczyć.Niestety, dopóki istnieją edytory oparte na JGit (które nie mogą
.gitattributes
poprawnie obsługiwać ), bezpiecznym rozwiązaniem jest wymuszanie LF wszędzie, nawet na poziomie edytora.Użyj następujących
anti-CRLF
środków dezynfekujących.klienci Windows / Linux:
core.autocrlf=input
popełnił
.gitattributes
:* text=auto eol=lf
commit
.editorconfig
( http://editorconfig.org/ ), który jest rodzajem znormalizowanego formatu, w połączeniu z wtyczkami edytora:https://github.com/welovecoding/editorconfig-netbeans/źródło
.gitattributes
linię, ma ona niezamierzone konsekwencje w Git <2.10, patrz stackoverflow.com/a/29508751/2261442git config --global core.autocrlf false
i zalecam zajmowanie się eolem.gitattributes
tylko w dyrektywach.To tylko rozwiązanie obejścia :
W normalnych przypadkach użyj rozwiązań dostarczonych z git. Te działają świetnie w większości przypadków. Skorzystaj z LF, jeśli udostępniasz programowanie w systemach Windows i Unix, ustawiając .gitattributes .
W moim przypadku było> 10 programistów rozwijających projekt w systemie Windows. Ten projekt został zaewidencjonowany za pomocą CRLF i nie było opcji wymuszania na LF.
Niektóre ustawienia zostały zapisane wewnętrznie na moim komputerze bez żadnego wpływu na format LF; dlatego niektóre pliki zostały globalnie zmienione na LF przy każdej małej zmianie pliku.
Moje rozwiązanie:
Komputery z systemem Windows: pozwól, by wszystko było takie, jakie jest. Nie przejmuj się niczym, ponieważ jesteś domyślnym programistą Windows „samotnego wilka” i musisz sobie z tym poradzić w następujący sposób: „Nie ma innego systemu na całym świecie, prawda?”
Maszyny uniksowe
Dodaj następujące wiersze do
[alias]
sekcji konfiguracji . To polecenie wyświetla listę wszystkich zmienionych (tj. Zmodyfikowanych / nowych) plików:Konwertuj wszystkie zmienione pliki do formatu dos:
Opcjonalnie ...
Utwórz git hook dla tej akcji, aby zautomatyzować ten proces
Użyj params i dołącz go i zmodyfikuj
grep
funkcję, aby dopasować tylko określone nazwy plików, np .:Zachęcamy do uczynienia go jeszcze wygodniejszym za pomocą dodatkowego skrótu:
... i odpal przekonwertowane rzeczy, pisząc
źródło