Najlepsze praktyki dla wieloplatformowego Git config?

Kontekst

Wiele plików konfiguracyjnych mojej aplikacji jest przechowywanych w repozytorium git, co ułatwia udostępnianie na wielu komputerach i platformach. Wśród tych plików konfiguracyjnych znajduje się .gitconfig, który zawiera następujące ustawienia obsługi znaków linii powrotnej karetki 

[core]
    autocrlf = true
    safecrlf = false

Problem

Te ustawienia są również stosowane na platformie GNU / Linux, co powoduje niejasne błędy.

Pytanie

Jakie są najlepsze praktyki Obsługa tych specyficznych dla platformy różnic w plikach konfiguracyjnych?

Proponowane rozwiązanie

Zdaję sobie sprawę, że ten problem może zostać rozwiązany przez posiadanie gałęzi dla każdej platformy i utrzymywanie wspólnych rzeczy w master i łączenie się z gałęzią platformy, gdy master porusza się do przodu. Zastanawiam się, czy są jakieś łatwiejsze rozwiązania tego problemu?

Author: Bas Bossink, 2010-02-25
Source

3 answers

Przejrzałem dokładnie tego typu konfigurację (crlf) w pytaniu:
Dystrybucja konfiguracji git z kodem.

Wniosek był następujący: 

*.java +crlf
*.txt +crlf
...
  • unikaj wszelkiego rodzaju konwersji plików, które tego nie potrzebują, ze względu na różne efekt uboczny takiej konwersji na merges, git status, Shell environment I svn import (Zobacz" Dystrybucja konfiguracji git z kodem " dla linków i odniesień).
  • unikaj konwersji, jeśli możesz.

Teraz, jeśli chodzi o konkretny problem per-platform settings , branch nie zawsze jest właściwym narzędziem, szczególnie dla danych niezwiązanych z programem (tj. historia rozwoju)

Jak wspomniano w pytaniu Git: jak utrzymać dwie gałęzie projektu i scalić tylko wspólne dane?:

Twoje życie będzie znacznie prostsze, jeśli umieścisz kod zależny od systemu w różnych katalogach i poradzisz sobie z wieloplatformowymi zależnościami w systemie budowania (pliki Makefile lub cokolwiek, czego używasz).

W tym przypadku, podczas gdy gałęzie mogą być używane do kodu zależnego od systemu, polecam directory dla wsparcia Narzędzia Ustawienia zależne od systemu, ze skryptem zdolnym zbudować odpowiedni plik .gitattributes, Aby zastosować odpowiednie ustawienie w zależności od platformy wdrażania repo.

 29
Author: VonC,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2017-05-23 12:02:00

Nigdy nie włączaj autocrlf, to powoduje tylko bóle głowy i smutki.

Nie ma wymówki do używania \r\n w systemie windows, każdy porządny edytor (z definicji) może sobie poradzić \n.

 43
Author: hasen,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-03-02 06:36:27

Myślę, że powinieneś mieć .gitconfig zależy od systemu operacyjnego, z którego korzysta użytkownik. Użytkownicy systemu Windows w ogóle nie potrzebują autocrlf, podczas gdy użytkownicy Linuksa. Np. Zapisz pliki tekstowe za pomocą crlf i poproś Git o automatyczną konwersję plików tam i z powrotem dla użytkowników Linuksa.

Możesz też sprawdzić .gitattributes, który pozwala określić, które pliki są konwertowane, a które nie. Jeśli masz pliki konfiguracyjne w jednym miejscu, możesz zdefiniować, że konwersja odbywa się tylko w tym katalogu, aby być po bezpiecznej stronie.

 -3
Author: Makis,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2010-02-25 08:00:01