CRLF bitiş satırları ile dosyaları yürütmeyi denedim, ancak başarısız oldu.

Windows bilgisayarımda bütün bir iş gününü farklı stratejiler denedim ve Git'i kullanmayı bırakıp Mercurial'ı denemek için neredeyse çizildim .

Lütfen cevap başına yalnızca bir en iyi uygulamayı paylaşın.

Bu soruyu sorduktan yaklaşık dört yıl sonra, sonunda beni tamamen tatmin eden bir cevap buldum !

Github'daki ayrıntılara bakın : satır sonlarıyla başa çıkmak için yardım kılavuzu .

Git , dosyadaki metin niteliğini kullanarak doğrudan bir repo için satır sonu özelliklerini ayarlamanıza olanak tanır .gitattributes. Bu dosya repo core.autocrlfişlemine tabi tutulur ve ayarı geçersiz kılar, git ayarlarından bağımsız olarak tüm kullanıcılar için tutarlı davranışlar sağlamanıza olanak tanır.

Ve böylece

Bunun avantajı, hat sonu yapılandırmanızın artık deponuzla birlikte seyahat etmesi ve ortak çalışanların uygun küresel ayarlara sahip olup olmadığı konusunda endişelenmenize gerek olmamasıdır.

İşte bir .gitattributesdosya örneği

# 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

En popüler programlama dilleri için kullanıma hazır .gitattributes dosyaları için uygun bir koleksiyon vardır . Başlamanıza yardımcı olur.

Oluşturduktan veya ayarladıktan sonra .gitattributes, bir kez ve hepsi için satır sonlarını yeniden normalleştirmeniz gerekir .

O Not GitHub Masaüstü uygulaması önermek ve bir oluşturabilir .gitattributes, uygulamada projenizin Git repo açtıktan sonra dosyayı. Bunu denemek için dişli çark simgesini (sağ üst köşede)> Depo ayarları ...> Satır sonları ve nitelikleri'ni tıklayın. Sizden önerilenleri eklemeniz istenir .gitattributesve kabul ederseniz uygulama, deponuzdaki tüm dosyaların normalleştirilmesini de gerçekleştirir.

Son olarak, Hattınızın Sonuna Dikkat Edin makalesi daha fazla arka plan sağlar ve Git'in eldeki konularda nasıl geliştiğini açıklar. Bunun zorunlu bir okuma olduğunu düşünüyorum .

Muhtemelen ekibinizde değişikliklerini yapmak için EGit veya JGit (Eclipse ve TeamCity gibi araçlar) kullanan kullanıcılar var. @Gatinueta'nın bu cevabın yorumlarında açıkladığı gibi şansın kalmadı:

Ekibinizde Egit veya JGit ile çalışan kişiler varsa, bu ayar sizi tatmin etmeyecektir, çünkü bu araçlar .gitattributes'ı görmezden gelecek ve CRLF dosyalarını mutlu bir şekilde kontrol edecektir https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

Bir numara, SourceTree'ye göre değişikliklerini başka bir istemcide işlemek olabilir . Ekibimiz daha sonra bu aracı Eclipse'nin EGit'e birçok kullanım durumu için tercih etti.

Kim demiş yazılım kolay? : - /

Satır sonlarını dönüştürmeyin. Verileri yorumlamak VCS'nin işi değildir - sadece saklayın ve versiyonlayın. Her modern metin editörü zaten her iki satır sonunu da okuyabilir.

Ne autocrlf=inputyaptığını gerçekten bilmiyorsan neredeyse her zaman istiyorsun .

Aşağıda bazı ek bağlamlar:

Ya olmalı core.autocrlf=true sen DOS biten gibi eğer yacore.autocrlf=input sen Unix satırsonlarını tercih ediyorsanız. Her iki durumda da Git deponuzda yalnızca Sağ Şey olan LF bulunur. Tek argüman core.autocrlf=false, otomatik sezgisel taramanın bazı ikili metinleri yanlış olarak algılayabileceği ve ardından döşemenizin bozulacağıydı. Bu nedenle, core.safecrlfgeri döndürülemez bir değişiklik olursa kullanıcıyı uyarmak için seçenek tanıtıldı. Aslında, geri döndürülemez değişikliklerin iki olasılığı vardır - bu normalleştirmede metin dosyasında karışık satır sonu istenir, bu nedenle bu uyarı göz ardı edilebilir veya Git'in ikili dosyanızı metin olarak yanlış algılaması (çok olası değildir). Sonra Git'e bu dosyanın ikili olduğunu bildirmek için öznitelikleri kullanmanız gerekir.

Yukarıdaki paragraf başlangıçta gmane.org'daki bir başlıktan alınmıştır, ancak o zamandan beri azalmıştır.

Karışık ortamlardaki satır sonları hakkında tutarlı olmak için iki alternatif strateji (Microsoft + Linux + Mac):

A.Tüm Havuzlara Göre Global Kurulum

1) Hepsini bir formata dönüştürün

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) Ayar core.autocrlfiçin inputLinux / UNIX ya true) MS Windows üzerinde (depo veya genel

git config --global core.autocrlf input

3) [İsteğe bağlı] , ters satırsonu dönüşümünün aynı dosyayla sonuçlanıp sonuçlanmadığını karşılaştırarak ekstra koruma eklemek core.safecrlfiçin true(durdurmak için) veya warn(şarkı söylemek için :) olarak ayarlayın

git config --global core.safecrlf true

B. Veya Depo Kurulumu başına

1) Hepsini bir formata dönüştürün

find . -type f -not -path "./.git/*" -exec dos2unix {} \;
git commit -a -m 'dos2unix conversion'

2) .gitattributesdeponuza dosya ekleyin

echo "* text=auto" > .gitattributes
git add .gitattributes
git commit -m 'adding .gitattributes for unified line-ending'

İkili dosyalarınız için endişelenmeyin - Git onlar için yeterince akıllı olmalıdır.

Safecrlf / autocrlf değişkenleri hakkında daha fazla bilgi

core.autocrlfYapılandırma seçeneğini olarak ayarlamayı deneyin true. Ayrıca core.safecrlfseçeneğe bir göz atın .

Aslında core.safecrlfdeponuzda zaten ayarlanmış gibi görünüyor , çünkü (benimkini vurgulayın):

Geçerli core.autocrlf ayarı için durum böyle değilse, git dosyayı reddeder .

Bu durumda, metin düzenleyicinizin satır sonlarını tutarlı şekilde kullanacak şekilde yapılandırıldığını kontrol etmek isteyebilirsiniz. Bir metin dosyası LF ve CRLF satır sonlarının bir karışımını içeriyorsa büyük olasılıkla sorun yaşarsınız.

Son olarak, Windows'ta basitçe "verdiğinizi kullanma" ve LF sonlandırılmış satırları kullanma önerisinin çözdüğünden daha fazla soruna neden olacağını hissediyorum. Git, satır sonlarını mantıklı bir şekilde ele almak için yukarıdaki seçeneklere sahiptir, bu nedenle bunları kullanmak mantıklıdır.

Kullanılması core.autocrlf=false, Visual Studio 2010'da teslim aldığımda tüm dosyaların güncellenmiş olarak işaretlenmesini durdurdu projemde . Geliştirme ekibinin diğer iki üyesi de Windows sistemlerini kullanıyor, bu nedenle karışık bir ortam devreye girmedi, ancak havuzla birlikte gelen varsayılan ayarlar, klonlamadan hemen sonra tüm dosyaları her zaman güncel olarak işaretledi.

Sonuçta ortamınız için hangi CRLF ayarının çalıştığını bulmaktır. Özellikle Linux kutularımızdaki diğer birçok depoda ayar autocrlf = truedaha iyi sonuçlar verdiğinden.

20+ yıl sonra ve hala işletim sistemleri arasındaki çizgi sonu eşitsizlikleriyle uğraşıyoruz ... üzgün.

Bunlar, Mac veya Linux kullanıcılarıyla kod paylaşan Windows ve Visual Studio kullanıcıları için iki seçenektir . Daha fazla açıklama için gitattributes kılavuzunu okuyun .

* metin = otomatik

Repo'nuzun .gitattributesdosyasına ekleyin:

*   text=auto

Bu, repodaki LFsatır sonları olan tüm dosyaları normalleştirir .

İşletim sisteminize ( core.eolayarınıza) bağlı olarak , çalışma ağacındaki dosyalar LFUnix tabanlı sistemler veya CRLFWindows sistemleri için normalleştirilir .

Bu, Microsoft .NET depolarının kullandığı yapılandırmadır .

Misal:

Hello\r\nWorld

Repoda her zaman şu şekilde normalleştirilecek:

Hello\nWorld

Ödeme sırasında Windows'daki çalışma ağacı şu biçime dönüştürülecek:

Hello\r\nWorld

Ödeme sırasında Mac'teki çalışma ağacı şu şekilde bırakılacaktır:

Hello\nWorld

Not: Reponunuz zaten normalleştirilmemiş dosyalar içeriyorsa git status, bir dahaki sefere değişiklik yaptığınızda bu dosyaları tamamen değiştirilmiş olarak gösterir ve diğer kullanıcıların değişikliklerini daha sonra birleştirmesi acı verici olabilir. Daha fazla bilgi için satır sonlarını değiştirdikten sonra veri havuzunu yenileme konusuna bakın .

core.autocrlf = doğru

Eğer textiçinde belirtilmemiş olan .gitattributesdosyanın, Git kullanırcore.autocrlf dosya dönüştürülmesi gerekir olmadığını belirlemek için yapılandırma değişkeni.

Windows kullanıcıları git config --global core.autocrlf trueiçin harika bir seçenektir çünkü:

• Dosyalar yalnızca eklendiğindeLF satır sonlarına normalleştirilir repoya . Depoda normalleştirilmemiş dosyalar varsa, bu ayar bunlara dokunmaz.
• Tüm metin dosyaları CRLFçalışma dizinindeki satır sonlarına dönüştürülür .

Bu yaklaşımla ilgili sorun şudur:

• Windows kullanıcısıysanız autocrlf = input, LFsatır sonu olan bir grup dosya göreceksiniz . Ekibin geri kalanı için bir tehlike değil, çünkü taahhütleriniz LFhat sonlarıyla normalleştirilecektir .
• Windows kullanıcısıysanız core.autocrlf = false, LFsatır sonları olan bir grup dosya göreceksiniz CRLFve repoya satır sonları olan dosyalar tanıtabilirsiniz .
• Çoğu Mac kullanıcısı , muhtemelen Windows kullanıcılarından dosya sonlu autocrlf = inputdosyalar kullanabilir ve alabilir .CRLFcore.autocrlf = false

--- GÜNCELLEME 3 --- (GÜNCELLEME 2 ile çakışmaz)

Windows kullanıcılarının üzerinde çalışmayı tercih ettikleri CRLFve linux / mac kullanıcılarının LFmetin dosyaları üzerinde çalışmayı tercih ettikleri dikkate alındığında . Yanıtın bir depo bakımcısı bakış açısından sağlanması :

Benim için en iyi strateji (çözmek için daha az sorun): sadece Windows projesinde çalışıyor olsanız bile tüm metin dosyalarını LFgit repo ile saklayın . Daha sonra , dosyaları taahhüt için hazırlarken stratejinize (repoda LF) saygı duyacak bir özellik değeri seçmeleri koşuluyla , müşterilere tercihlerinin satır sonu stili üzerinde çalışma özgürlüğü verin .core.autocrlf

Evreleme , yeni hat stratejilerinin nasıl çalıştığını anlamaya çalışırken birçok kişinin kafasını karıştırır . Mülkiyet için doğru değeri seçmeden önce aşağıdaki noktaları anlamak önemlidir :core.autocrlf

• Taahhüt için bir metin dosyası eklemek ( hazırlama ) dosyayı dönüştürülmüş satır sonlarıyla.git/ alt dizin içindeki başka bir yere kopyalamak gibidir ( istemci yapılandırmanızdaki değere bağlı olarak ). Bütün bunlar yerel olarak yapılır .core.autocrlf
• ayar soruyacore.autocrlf bir cevap vermek gibidir (tüm işletim sistemlerinde aynı soru):
  • "Git istemcisi olmalı a. Repo değişikliklerini uzaktan kontrol ederken (çekerek) LF-CRLF'ye dönüştürmeli mi, b. Kesinleştirme için bir dosya eklerken CRLF-LF'yi dönüştürmeli mi? " Ve olası cevaplar (değerler) şunlardır:
  • false:" yukarıdakilerin hiçbirini yapma ",
  • input:" Do yalnızca b "
  • true: " Do a ve b ve "
  • HAYIR olduğunu unutmayın " sadece bir "

neyse ki

• git istemci varsayılanları (windows:, core.autocrlf: truelinux / mac :) salt LF repo stratejisi core.autocrlf: falseile uyumlu olacaktır .
  Anlamı : Windows istemcileri, depoyu teslim alırken varsayılan olarak CRLF'ye ve kesinleştirme için eklerken LF'ye dönüştürür. Ve linux istemcileri varsayılan olarak herhangi bir dönüşüm yapmaz. Bu teorik olarak sadece repo'nuzu korur.

Ne yazık ki:

• Git'e uymayan GUI istemcileri olabilir core.autocrlf değerine
• Lf-repo stratejinize saygı göstermek için değer kullanmayan insanlar olabilir. Örneğin kullanıyorlarcore.autocrlf=false , taahhüt için CRLF ile bir dosya ve eklerler.

Yukarıdaki istemciler tarafından taahhüt edilen ASAP lf olmayan metin dosyalarını tespit etmek için --- update 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, kullanılarak derlenen bir istemcide açıklananları takip edebilirsiniz :--with-libpcre flag

Ve burada tutmak: . Bir repo bakımcısı olarakgit.autocrlf=input ben sadece taahhüt için tekrar ekleyerek yanlış taahhüt dosyaları düzeltmek bir . Ve bir taahhüt metni sağlıyorum: "Yanlış taahhüt edilen dosyaları düzeltme".

Bildiğim kadarıyla .gitattributes. Buna güvenmiyorum, çünkü anlamayan daha fazla kullanıcı arayüzü var. Ben sadece metin ve ikili dosyalar için ipuçları sağlamak için kullanabilirsiniz ve belki de her yerde aynı satır sonlarını tutmak gerekir bazı istisnai dosyaları bayrak:

*.java          text !eol # Don't do auto-detection. Treat as text (don't set any eol rule. use client's)
*.jpg           -text     # Don't do auto-detection. Treat as binary
*.sh            text eol=lf # Don't do auto-detection. Treat as text. Checkout and add with eol=lf
*.bat           text eol=crlf # Treat as text. Checkout and add with eol=crlf

Soru: Peki neden newline taşıma stratejisiyle ilgileniyoruz?

Yanıt: Tek harfli bir değişiklik taahhüdünden kaçınmak için, 5000 satırlık bir değişiklik olarak görünün, çünkü değişikliği gerçekleştiren istemcinin taahhüt için eklemeden önce tam dosyayı crlf'den lf'ye (veya tersine) otomatik olarak dönüştürmesi. Bu , bir uyuşmazlık çözümü söz konusu olduğunda oldukça acı verici olabilir . Veya bazı durumlarda mantıksız çatışmaların nedeni olabilir.

--- GÜNCELLEME 2 ---

Git istemcisinin kusurları çoğu durumda çalışacaktır. Yalnızca pencereleriniz olsa bile, yalnızca linux istemcileri veya her ikisi de. Bunlar:

• windows: core.autocrlf=true satırları çıkışta CRLF'ye ve satırları dosya eklerken LF'ye dönüştürmek anlamına gelir.
• linux: core.autocrlf=input satırları ödeme sırasında dönüştürmemeniz (dosyaların LF ile işlenmesi beklendiğinden gerek yoktur) ve dosya eklerken satırları LF'ye (gerekirse) dönüştürmek anlamına gelir. ( - update3 - : Bunun falsevarsayılan olarak olduğu görülüyor , ancak yine de iyi)

Tesis farklı kapsamlarda ayarlanabilir. --globalSonunda açıklanan bazı IDE sorunlarından kaçınmak için açıkça kapsamda ayarlanmasını öneririm .

git config core.autocrlf
git config --global core.autocrlf
git config --system core.autocrlf
git config --local core.autocrlf
git config --show-origin core.autocrlf

Ayrıca şiddetle ediyorum vazgeçirmek kullanarak pencerelerde git config --global core.autocrlf false (eğer pencereler sadece istemcilerin var) önerilmiştir neyi aksine git belgeler . False değerine ayarlamak, depoda CRLF bulunan dosyaları yürütür. Ama gerçekten bir sebep yok. Projeyi linux kullanıcılarıyla paylaşmanız gerekip gerekmediğini asla bilemezsiniz. Ayrıca, varsayılanları kullanmak yerine projeye katılan her müşteri için ek bir adımdır.

Şimdi *.bat *.sh, LF veya CRLF ile teslim alınmasını istediğiniz bazı özel durumlarda (örn. ) Kullanabilirsiniz..gitattributes

Özetlemek gerekirse en iyi uygulama :

• Her ikili olmayan dosyanın git repo'da LF ile işlendiğinden emin olun (varsayılan davranış).
• CRLF ile hiçbir dosyanın işlenmediğinden emin olmak için bu komutu kullanın: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Not: Windows istemcilerinde yalnızca git-bashlinux istemcileri aracılığıyla ve üzerinde çalışır --with-libpcre../configure ).
• Yukarıdaki komutu uygulayarak bu tür dosyaları bulursanız, bunları düzeltin. Bu aşağıdakileri içerir (en azından linux'da):
  • set core.autocrlf=input( --- güncelleme 3 - )
  • dosyayı değiştir
  • değişikliği geri al (dosya hala değişmiş olarak gösterilir)
  • taahhüt et
• Yalnızca minimum değeri kullanın .gitattributes
• Kullanıcılara core.autocrlfyukarıda açıklananları varsayılan değerlerine ayarlamalarını söyleyin.
• Varlığında% 100 saymayın .gitattributes. IDE'lerin git-istemcileri onları görmezden gelebilir veya onlara farklı davranabilir.

Söylendiği gibi git özelliklerine bazı şeyler eklenebilir:

# Always checkout with LF
*.sh            text eol=lf
# Always checkout with CRLF
*.bat           text eol=crlf

.gitattributesİkili dosyalar için otomatik algılama kullanmak yerine diğer bazı güvenli seçenekleri düşünüyorum :

• -text(örneğin *.zipveya *.jpgdosyalar için: Metin olarak ele alınmaz. Dolayısıyla satır sonu dönüşüm denenmez. Dönüşüm programları aracılığıyla fark olabilir)
• text !eol(örn için *.java, *.html:.. metin olarak tedavi ancak eol tarzı tercihi ayarlanmamış istemci ayarı kullanılır Yani)
• -text -diff -merge(örneğin *.hugefile: Metin olarak değerlendirilmez. Fark / birleştirme mümkün değildir)

--- ÖNCEKİ GÜNCELLEME ---

Bir acı örnek dosyaları yanlış taahhüt edecektir bir müşterinin:

netbeans 8.2 (pencerelerde), yanlış ile tüm metin dosyaları taahhüt edecektir sürece, CRLFlerin sen gelmiş açıkça belirlenen core.autocrlfküresel olarak . Bu, standart git istemci davranışıyla çelişir ve daha sonra güncelleme / birleştirme sırasında birçok soruna neden olur. Geri döndüğünüzde bile bazı dosyaların farklı görünmesine (olmamasına rağmen) budur . Netbeans'de aynı davranış , projenize doğru bir şekilde eklemiş olsanız bile gerçekleşir .
.gitattributes

Bir taahhütten sonra aşağıdaki komutu kullanmak, en azından git repo'nuzda satır sonu sorunları olup olmadığını erken tespit etmenize yardımcı olacaktır: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Ona .gitattributesgüvenemeyeceğimin mümkün olan en iyi şekilde kullanılması , sonunda fark edilmesi için saatler geçirdim .
Ne yazık ki, JGit tabanlı editörler ( .gitattributesdoğru şekilde işleyemeyen ) var olduğu sürece , güvenli çözüm, LF'yi editör düzeyinde bile her yerde zorlamaktır.

Aşağıdaki anti-CRLFdezenfektanları kullanın .

• windows / linux istemcileri: core.autocrlf=input

• taahhüt .gitattributes: * text=auto eol=lf

• editör eklentileriyle birleştirilmiş standart bir format olan taahhütlü .editorconfig( http://editorconfig.org/ ):

  • https://github.com/editorconfig/
  • https://github.com/welovecoding/editorconfig-netbeans/

Bu sadece geçici bir çözümdür:

Normal durumlarda git ile birlikte gelen çözümleri kullanın. Bunlar çoğu durumda harika çalışır. .Gitattributes ayarlayarak Windows ve Unix tabanlı sistemlerde geliştirmeyi paylaşıyorsanız LF'ye zorlayın .

Benim durumumda Windows'ta bir proje geliştiren> 10'dan fazla programcı vardı. Bu proje CRLF ile kontrol edildi ve LF'ye zorlama seçeneği yoktu.

Bazı ayarlar LF formatını etkilemeden makineme dahili olarak yazılmıştır; böylece her küçük dosya değişikliğinde bazı dosyalar global olarak LF olarak değiştirildi.

Çözümüm:

Windows-Machines: Her şeyi olduğu gibi bırakın. Hiçbir şey umurumda değil, çünkü varsayılan bir pencere 'yalnız kurt' geliştiricisi ve şu şekilde işlemek zorundasınız: "Geniş dünyada başka bir sistem yok, değil mi?"

Unix makineler

1. Bir yapılandırmanın [alias]bölümüne aşağıdaki satırları ekleyin . Bu komut tüm değiştirilmiş (değiştirilmiş / yeni) dosyaları listeler:

   lc = "!f() { git status --porcelain \
                | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                | cut -c 4- ; }; f "

2. Değiştirilen tüm dosyaları dos biçimine dönüştürün:

   unix2dos $(git lc)

3. İsteğe bağlı olarak ...

   1. Bu işlemi otomatikleştirmek üzere bu eylem için bir git kancası oluşturun

   2. Parametreleri kullanın ve ekleyin ve grepişlevi yalnızca belirli dosya adlarıyla eşleşecek şekilde değiştirin , örn:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...

   3. Ek bir kısayol kullanarak bunu daha rahat hale getirmekten çekinmeyin:

      c2dos = "!f() { unix2dos $(git lc) ; }; f "

      ... ve dönüştürülen şeyleri

      git c2dos