Apa strategi penanganan CRLF (carriage return, line feed) terbaik dengan Git?

598

Saya mencoba melakukan file dengan baris CRLF-ending, tetapi gagal.

Saya menghabiskan seluruh hari kerja di komputer Windows saya mencoba berbagai strategi dan hampir tertarik untuk berhenti mencoba menggunakan Git dan bukannya mencoba Mercurial .

Harap bagikan hanya satu praktik terbaik per jawaban.

Daniel Jomphe
sumber

Jawaban:

753

Hampir empat tahun setelah mengajukan pertanyaan ini, saya akhirnya menemukan jawaban yang benar-benar memuaskan saya !

Lihat detail di github: panduan bantuan untuk Berurusan dengan akhiran baris .

Git memungkinkan Anda untuk mengatur properti akhiran baris untuk repo secara langsung menggunakan atribut teks dalam .gitattributesfile. File ini dikomit ke dalam repo dan mengesampingkan core.autocrlfpengaturan, memungkinkan Anda untuk memastikan perilaku yang konsisten untuk semua pengguna terlepas dari pengaturan git mereka.

Dan dengan demikian

Keuntungan dari hal ini adalah bahwa konfigurasi end of line Anda sekarang bepergian dengan repositori Anda dan Anda tidak perlu khawatir tentang apakah kolaborator memiliki pengaturan global yang tepat atau tidak.

Ini contoh .gitattributesfile

# 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

Ada koleksi nyaman .gitattributes file siap pakai untuk bahasa pemrograman paling populer. Ini berguna untuk membantu Anda memulai.

Setelah membuat atau menyesuaikan .gitattributes, Anda harus melakukan normalisasi ulang akhiran garis sekali dan untuk semua .

Perhatikan bahwa aplikasi GitHub Desktop dapat menyarankan dan membuat .gitattributesfile setelah Anda membuka repo Git proyek Anda di aplikasi. Untuk mencobanya, klik ikon roda gigi (di sudut kanan atas)> Pengaturan repositori ...> Akhiran garis dan atribut. Anda akan diminta untuk menambahkan yang direkomendasikan .gitattributesdan jika Anda setuju, aplikasi juga akan melakukan normalisasi semua file di repositori Anda.

Akhirnya, artikel Mind the End of Your Line memberikan lebih banyak latar belakang dan menjelaskan bagaimana Git telah berevolusi dalam masalah yang dihadapi. Saya menganggap ini bacaan wajib .

Anda mungkin memiliki pengguna di tim Anda yang menggunakan EGit atau JGit (alat seperti Eclipse dan TeamCity menggunakannya) untuk melakukan perubahan. Maka Anda kurang beruntung, seperti yang dijelaskan @gatinueta dalam komentar jawaban ini:

Pengaturan ini tidak akan memuaskan Anda sepenuhnya jika Anda memiliki orang yang bekerja dengan Egit atau JGit di tim Anda, karena alat tersebut hanya akan mengabaikan .gitattributes dan dengan senang hati memeriksa file CRLF https://bugs.eclipse.org/bugs/show_bug.cgi? id = 342372

Salah satu trik mungkin untuk meminta mereka melakukan perubahan pada klien lain, katakan SourceTree . Tim kami saat itu lebih suka alat itu daripada Eclipse's EGit untuk banyak kasus penggunaan.

Siapa bilang perangkat lunak itu mudah? : - /

Daniel Jomphe
sumber
7
Mau berbagi Windows .gitattributes?
Kolonel Panic
Bagaimana Anda bisa melihat apa yang .gitattributesdisarankan GitHub untuk Windows untuk proyek Anda? Saya menginstal GitHub untuk Windows, memulai versi GUI dan tidak dapat menemukan opsi yang terkait dengan .gitattributessaran.
JLDiaz
4
Pengaturan ini tidak akan memuaskan Anda sepenuhnya jika Anda memiliki orang-orang yang bekerja dengan Egit di tim Anda, karena egit akan mengabaikan .gitattributes dan dengan senang hati memeriksa file CRLF bugs.eclipse.org/bugs/show_bug.cgi?id=342372
gatinueta
19
Untuk Windows, saya biasanya cenderung untuk mengatur global core.autocrlf = false- saya lebih suka LF di mana-mana, tetapi beberapa alat Windows seperti Visual Studio bersikeras akhir CRLF dalam file tertentu (dan bahkan mencampurnya dalam beberapa ..); bukan akhiran garis hijau adalah pilihan paling aman. Jika Anda tahu apa yang Anda lakukan, saya mungkin akan menggunakan core.autocrlf = inputdan membuat pengecualian untuk proyek-proyek di Windows yang Anda tahu sensitif terhadap akhir baris. Seperti yang ditunjukkan orang lain, setiap editor teks yang layak mendukung akhiran LF sekarang. Saya benar-benar berpikir core.autocrlf = truemungkin dapat menyebabkan lebih banyak masalah daripada mencegahnya.
Adrian
1
@ gatinueta Untuk lebih spesifik, ini masalah JGit. Berarti TeamCity, yang juga menggunakan JGit, langsung mengabaikan .gitattributes.
sdds
122

Jangan mengonversi ujung baris. Bukan tugas VCS untuk menginterpretasikan data - simpan saja dan beri versi. Setiap editor teks modern dapat membaca kedua jenis akhiran baris itu.

John Millikin
sumber
25
Diperbantukan. Jika Anda memiliki masalah dengan akhir baris yang tidak konsisten, solusi terbaik adalah berteriak pada siapa pun yang menggunakan pengaturan editor yang salah sampai mereka memperbaikinya.
136
Tidak setuju. Feed line asli pada semua platform adalah kenyamanan.
Jonas Byström
25
Visual Studio adalah PITA dalam hal apa pun selain CRLF.
Brett Ryan
32
Git memiliki opsi untuk tidak mengonversi akhir baris, itu autocrlf = false dan kecuali Anda melakukan pengembangan lintas-platform, seperti katakanlah Mono sebaiknya dibiarkan salah ketika dijalankan di Windows dan disetel ke true jika Anda akan mengembangkan open-source untuk Mono.
Chris Nicola
24
Masalah dengan akhir baris adalah menghitung diff yang benar. Jadi jawabannya salah dan menyesatkan.
cos
84

Anda hampir selalu ingin autocrlf=inputkecuali Anda benar-benar tahu apa yang Anda lakukan.

Beberapa konteks tambahan di bawah ini:

Itu harus baik core.autocrlf=truejika Anda suka akhiran DOS atau core.autocrlf=inputjika Anda lebih suka unix-newlines. Dalam kedua kasus, repositori Git Anda hanya akan memiliki LF, yang merupakan Hal yang Benar. Satu-satunya argumen core.autocrlf=falseadalah bahwa heuristik otomatis dapat mendeteksi beberapa biner sebagai teks dan ubin Anda akan rusak. Jadi, core.safecrlfopsi diperkenalkan untuk memperingatkan pengguna jika terjadi perubahan permanen. Faktanya, ada dua kemungkinan perubahan yang tidak dapat diubah - campuran akhir baris dalam file teks, dalam normalisasi ini diinginkan, sehingga peringatan ini dapat diabaikan, atau (sangat tidak mungkin) bahwa Git salah mendeteksi file biner Anda sebagai teks. Maka Anda perlu menggunakan atribut untuk memberi tahu Git bahwa file ini biner.

Paragraf di atas pada awalnya ditarik dari utas di gmane.org, tetapi sejak saat itu sudah turun.

Cory
sumber
31
Mengapa itu "Hal yang Benar"?
Artem Tikhomirov
35
core.autocrlf = true adalah ide yang mengerikan. Saya tidak punya masalah dengan opsi itu, ditambah Anda harus ingat untuk mengaturnya kapan pun Anda mengkloning repositori.
Luís Oliveira
28
JANGAN gunakan autocrlf = true kecuali Anda tahu apa yang Anda lakukan. Jika Anda mengembangkan di DOS / Win maka autocrlf = false akan menjaga akhiran yang sama antara repo jarak jauh dan lokal dan merupakan pilihan terbaik di hampir setiap situasi.
Chris Nicola
13
@ Chris - Bagaimana jika pengembang Anda memiliki windows dan proyek multi-platform di mana beberapa pengembang multi-platform bekerja di OSX atau Linux? Bukankah seharusnya pilihan terbaik adalah autocrlf = true?
Brett Ryan
20
Terpilih, dengan pemesanan. Paragraf pengantar tidak membantu. core.autocrlf=inputadalah jawaban kanonik. Untuk sebagian besar kasus penggunaan, core.autocrlf=truedan core.autocrlf=falseterlalu bersemangat (... dalam cara yang berlawanan tetapi sama-sama mengerikan, tentu saja) dan karenanya secara intrinsik merusak. "Git for Windows" seharusnya benar - benar dikirimkan dengan "Checkout apa adanya, komit akhiran garis gaya Unix" (yaitu, core.autocrlf=input) sebagai strategi default baris baru. Tidak. Jadi di sini kita di sini - di awal 2015 - masih berdebat tanpa henti.
Cecil Curry
58

Dua strategi alternatif untuk menjadi konsisten tentang garis akhir di lingkungan campuran (Microsoft + Linux + Mac):

A. Global per Semua Pengaturan Repositori

1) Konversi semua menjadi satu format

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

2) Set core.autocrlfke inputLinux / UNIX atau trueMS Windows (repositori atau global)

git config --global core.autocrlf input

3) [Opsional] disetel core.safecrlfke true(untuk berhenti) atau warn(untuk menyanyi :) untuk menambahkan penjaga ekstra membandingkan jika transformasi baris baru yang dibalik akan menghasilkan file yang sama

git config --global core.safecrlf true


B. Atau per Pengaturan Repositori

1) Konversi semua menjadi satu format

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

2) tambahkan .gitattributesfile ke repositori Anda

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

Jangan khawatir tentang file biner Anda - Git harus cukup pintar tentang mereka.


Lebih lanjut tentang variabel safecrlf / autocrlf

lukmdo
sumber
5
pendekatan global == atur dan lupakan untuk semua repo vs. per repo == tidak mengharuskan orang lain untuk mengubah konfigurasi global mereka.
lukmdo
4
dos2unixadalah alat baris perintah yang bergantung pada sistem yang mungkin harus Anda instal tambahan
lukmdo
2
Mereka tidak eksklusif, Anda dapat menggunakan kedua pendekatan pada saat yang bersamaan. Juga, berhati-hatilah saat menggunakan dos2unix- ada risiko rusak.git/index dan kita tidak perlu menerapkannya pada setiap file. Lebih baik menggunakan sesuatu seperti find ./ -name "*.html"dan menentukan file yang ingin Anda terapkan.
cregox
6
PERINGATAN: sebelum menjalankannya find, berhati-hatilah: dos2unixyang dikirimkan bersama dengan Git untuk Windows memiliki perilaku aneh (IMO idiot dan berbahaya), tanpa argumen: alih-alih mengubah ke UNIX, ia mengubah format baris baru (DOS <-> UNIX )
leonbloy
2
Dan peringatan lain: jangan DOS2UNIX folder .git Anda. Hanya mengatakan.
hakre
10

Coba core.autocrlfatur opsi konfigurasi ke true. Lihat juga core.safecrlfopsi.

Sebenarnya sepertinya core.safecrlfsudah diatur dalam repositori Anda, karena (penekanan milikku):

Jika ini bukan kasus untuk pengaturan core.autocrlf saat ini, git akan menolak file tersebut .

Jika ini masalahnya, maka Anda mungkin ingin memeriksa apakah editor teks Anda dikonfigurasi untuk menggunakan akhiran baris secara konsisten. Anda mungkin akan mengalami masalah jika file teks berisi campuran ujung LF dan CRLF.

Akhirnya, saya merasa bahwa rekomendasi untuk hanya "menggunakan apa yang Anda diberikan" dan menggunakan jalur yang diakhiri LF pada Windows akan menyebabkan lebih banyak masalah daripada yang dipecahkan. Git memiliki opsi di atas untuk mencoba menangani ujung garis dengan cara yang masuk akal, jadi masuk akal untuk menggunakannya.

Greg Hewgill
sumber
1
Bukankah lebih baik menggunakan pengaturan lebar repositori melalui file .gitattributes? Apakah hanya bertanya-tanya: itu tidak nyaman untuk memaksa setiap pengguna untuk mengurus pengaturan akhir baris di mesinnya ... Atau ada kelemahan lain?
trainoasis
10

Menggunakan core.autocrlf=falsemenghentikan semua file yang ditandai diperbarui segera setelah saya memeriksanya di Visual Studio 2010 saya proyek . Dua anggota tim pengembangan lainnya juga menggunakan sistem Windows sehingga lingkungan campuran tidak ikut bermain, namun pengaturan default yang disertakan dengan repositori selalu menandai semua file yang diperbarui segera setelah kloning.

Saya kira intinya adalah menemukan apa yang berfungsi pengaturan CRLF untuk lingkungan Anda. Terutama karena di banyak repositori lain di pengaturan kotak Linux kamiautocrlf = true menghasilkan hasil yang lebih baik.

20+ tahun kemudian dan kami masih berurusan dengan perbedaan garis akhir antara OS ... sedih.

Lance Cleveland
sumber
31
@ orange80, perbedaannya sangat disayangkan, tetapi tidak ada alasan untuk menyebutnya kesalahan Windows. LF-only masuk akal dari sudut pandang minimalis, mungkin; tetapi CRLF lebih masuk akal berdasarkan apa yang dimaksud dengan CR dan LF. "Pengembalian gerbong" berarti kembali ke awal baris; "umpan garis" berarti bergerak lurus ke bawah ke baris berikutnya, daripada ke awal baris berikutnya. Dari sudut pandang semantik, Windows lebih benar dalam memiliki keduanya: kembali ke awal (CR) dan kemudian turun satu baris (LF).
Ryan Lundy
40
@ Kyralessa "lebih tepat" masih berpura-pura bahwa komputer adalah mesin tik, yang bukan, btw. Mempertahankan analogi mesin tik tidak masuk akal mengingat ini bukan sesuatu yang akan dihadapi pengguna akhir, dan bahwa dua karakter bukannya satu tidak ada gunanya.
jpswain
1
Terlambat ke pesta ini beberapa tahun, tetapi Anda mengabaikan fakta bahwa CR dan LF adalah alat penentuan posisi kursor. "CR" mungkin juga "Pengembalian Kursor" pada titik ini dalam sejarah. Jika saya ingin kursor kembali ke awal baris, saya akan memberitahu aplikasi untuk melakukan itu. Kalau tidak, harus tetap di tempat saya meletakkannya.
EKW
2
Juga, jika CRLF "lebih benar" karena baris teks baru benar-benar merupakan "pindahkan satu baris ke bawah" dan "pindah ke awal baris", itu akan mengikuti bahwa hanya CR yang akan menyebabkan editor teks menimpa baris dengan mengikuti garis. Saya tahu tidak ada editor yang benar-benar mendukung ini, yang berarti bahwa kebutuhan untuk mengekspresikan CRLF dan CR sebagai hal yang berbeda, tidak benar-benar ada.
avl_sweden
@avl_sweden Itu adalah perilaku yang sangat umum sebelum DOS, dan karena Microsoft menganggap kompatibilitas itu penting, sejak saat itu ia tetap tenang. Itu juga cara standar di AS (sesuai ASA) - ISO memungkinkan CR + LF dan LF (jadi sekali lagi, DOS adalah standar yang sesuai); dalam kedua kasus, sejak tahun enam puluhan. Multics (Unix precursor) mendukung CR untuk bold / strike. Banyak aplikasi saat ini (termasuk fitur .NET "split by lines") mencari salah satu dari tiga (lone CR, lone LF, CRLF), dan memperlakukan masing-masing sebagai end-line. Namun, banyak aplikasi yang masih bingung dengan campuran garis akhir dalam sebuah file.
Luaan
7

Ini adalah dua opsi untuk pengguna Windows dan Visual Studio yang berbagi kode dengan pengguna Mac atau Linux . Untuk penjelasan lebih lanjut, baca manual gitattributes .

* text = auto

Dalam .gitattributesfile repo Anda, tambahkan:

*   text=auto

Ini akan menormalkan semua file dengan LF akhiran baris dalam repo.

Dan tergantung pada sistem operasi Anda ( core.eolpengaturan), file di pohon kerja akan dinormalisasi ke LFuntuk sistem berbasis Unix atauCRLF untuk sistem Windows.

Ini adalah konfigurasi yang Microsoft .NET menggunakan repo .

Contoh:

Hello\r\nWorld

Akan dinormalisasi dalam repo selalu seperti:

Hello\nWorld

Saat checkout, pohon yang berfungsi di Windows akan dikonversi menjadi:

Hello\r\nWorld

Saat checkout, pohon yang berfungsi di Mac akan dibiarkan sebagai:

Hello\nWorld

Catatan: Jika repo Anda sudah berisi file yang tidak dinormalisasi, git statusakan menampilkan file-file ini sebagai benar-benar dimodifikasi saat Anda membuat perubahan di lain waktu, dan itu bisa menyusahkan bagi pengguna lain untuk menggabungkan perubahan mereka nanti. Lihat menyegarkan repositori setelah mengubah akhir baris untuk informasi lebih lanjut.

core.autocrlf = benar

Jika texttidak ditentukan dalam .gitattributesfile, Git menggunakancore.autocrlf variabel konfigurasi untuk menentukan apakah file tersebut harus dikonversi.

Untuk pengguna Windows, git config --global core.autocrlf trueadalah pilihan yang bagus karena:

  • File dinormalisasi ke LFakhir baris hanya bila ditambahkan ke repo. Jika ada file yang tidak dinormalisasi dalam repo, pengaturan ini tidak akan menyentuhnya.
  • Semua file teks dikonversi ke CRLFakhir baris di direktori kerja.

Masalah dengan pendekatan ini adalah:

  • Jika Anda adalah pengguna Windows autocrlf = input, Anda akan melihat banyak file dengan LFakhiran baris. Bukan bahaya bagi anggota tim lainnya, karena komit Anda masih akan dinormalisasi dengan LFakhiran garis.
  • Jika Anda adalah pengguna Windows core.autocrlf = false, Anda akan melihat banyak file dengan LFakhiran baris dan Anda dapat memperkenalkan file denganCRLF ujung baris ke dalam repo.
  • Sebagian besar pengguna Mac menggunakan autocrlf = inputdan mungkin mendapatkan file dengan CRLFujung file, mungkin dari pengguna Windows dengan core.autocrlf = false.
kiewik
sumber
1
Kata perintah Anda untuk pengguna windows git config --global core.autocrl true. Maksudmu git config --global core.autocrlf true.
JellicleCat
6

--- UPDATE 3 --- (tidak bertentangan dengan UPDATE 2)

Mempertimbangkan kasus bahwa pengguna windows lebih suka bekerja CRLFdan pengguna linux / mac lebih suka bekerja pada LFfile teks. Memberikan jawaban dari perspektif pengelola repositori :

Bagi saya strategi terbaik (lebih sedikit masalah untuk dipecahkan) adalah: simpan semua file teks dengan LFgit repo dalam walaupun Anda sedang mengerjakan proyek windows-only. Kemudian berikan kebebasan kepada klien untuk mengerjakan gaya penutup akhir dari preferensi mereka , asalkan mereka memilih core.autocrlfnilai properti yang akan menghormati strategi Anda (LF on repo) sambil mengatur file untuk komit.

Pementasan adalah yang membingungkan banyak orang ketika mencoba memahami bagaimana strategi garis baru bekerja. Sangat penting untuk menghilangkan poin-poin berikut sebelum memilih nilai yang benar untuk core.autocrlfproperti:

  • Menambahkan file teks untuk komit ( staging ) adalah seperti menyalin file ke tempat lain di dalam .git/sub-direktori dengan akhir baris dikonversi (tergantung pada core.autocrlfnilai pada konfigurasi klien Anda). Semua ini dilakukan secara lokal.
  • pengaturan core.autocrlfseperti memberikan jawaban untuk pertanyaan (pertanyaan yang sama persis pada semua OS):
    • "Haruskah git-client a. Mengkonversi LF-ke-CRLF saat check-out (menarik) repo berubah dari jarak jauh atau b. Mengkonversi CRLF-ke-LF ketika menambahkan file untuk komit? " Dan kemungkinan jawaban (nilai) adalah:
    • false:" Jangan lakukan yang di atas ",
    • input:" lakukan saja b "
    • true: " lakukan a dan dan b "
    • perhatikan bahwa TIDAK ada " lakukan saja "

Untung

  • git client default (windows core.autocrlf: true:, linux / mac:) core.autocrlf: falseakan kompatibel dengan strategi LF-only-repo .
    Artinya : klien windows secara default akan mengkonversi ke CRLF ketika memeriksa-keluar repositori dan mengkonversi ke LF ketika menambahkan untuk komit. Dan klien linux secara default tidak akan melakukan konversi. Secara teoritis ini hanya menyimpan repo Anda.

Sayangnya:

  • Mungkin ada GUI klien yang tidak menghormati git core.autocrlfnilai
  • Mungkin ada orang yang tidak menggunakan nilai untuk menghargai strategi lf-repo Anda. Misalnya mereka gunakancore.autocrlf=false dan menambahkan file dengan CRLF untuk komit.

Untuk mendeteksi file teks non-Jika ASAP dilakukan oleh klien di atas, Anda dapat mengikuti apa yang dijelaskan pada --- pembaruan 2 ---: ( git grep -I --files-with-matches --perl-regexp '\r' HEAD, pada klien yang dikompilasi menggunakan:--with-libpcre flag)

Dan di sini adalah menangkap: . Saya sebagai pengelola repo menyimpangit.autocrlf=input sehingga saya dapat memperbaiki file yang salah komitmen hanya dengan menambahkannya lagi untuk komit. Dan saya memberikan teks komit: "Memperbaiki file yang salah berkomitmen".

Sejauh .gitattributesini dinodai. Saya tidak mengandalkan itu, karena ada lebih banyak klien yang tidak memahaminya. Saya hanya menggunakannya untuk memberikan petunjuk untuk file teks dan file biner, dan mungkin menandai beberapa file luar biasa yang di mana-mana harus menyimpan akhiran baris yang sama:

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

Pertanyaan: Tapi mengapa kita tertarik sama sekali dalam strategi penanganan baris baru?

Jawaban: Untuk menghindari komit perubahan huruf tunggal, muncul sebagai perubahan 5.000 baris , hanya karena klien yang melakukan perubahan secara otomatis mengonversi file lengkap dari crlf ke lf (atau sebaliknya) sebelum menambahkannya untuk komit. Ini bisa agak menyakitkan ketika ada resolusi konflik yang terlibat. Atau bisa dalam beberapa kasus menjadi penyebab konflik yang tidak masuk akal.


--- PEMBARUAN 2 ---

Kerusakan klien git akan berfungsi dalam banyak kasus. Bahkan jika Anda hanya memiliki klien windows only, linux hanya klien atau keduanya. Ini adalah:

  • windows: core.autocrlf=true berarti mengonversi baris ke CRLF saat checkout dan mengonversi baris ke LF saat menambahkan file.
  • linux: core.autocrlf=input berarti tidak mengkonversi baris pada checkout (tidak perlu karena file diharapkan dilakukan dengan LF) dan mengkonversi baris ke LF (jika perlu) saat menambahkan file. ( - update3 - : Tampaknya ini adalah falsedefault, tapi sekali lagi tidak masalah)

Properti dapat diatur dalam cakupan yang berbeda. Saya akan menyarankan pengaturan secara eksplisit dalam --globalruang lingkup, untuk menghindari beberapa masalah IDE yang dijelaskan di bagian akhir.

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

Juga saya akan sangat menyarankan menggunakan pada windows git config --global core.autocrlf false (jika Anda memiliki klien windows saja) berbeda dengan apa yang diusulkan untuk dokumentasi git . Pengaturan ke false akan melakukan file dengan CRLF di repo. Tetapi sebenarnya tidak ada alasan. Anda tidak pernah tahu apakah Anda perlu berbagi proyek dengan pengguna linux. Plus itu satu langkah ekstra untuk setiap klien yang bergabung dengan proyek daripada menggunakan default.

Sekarang untuk beberapa kasus khusus file (mis. *.bat *.sh) Yang Anda ingin mereka periksa dengan LF atau dengan CRLF Anda dapat menggunakan.gitattributes

Singkatnya bagi saya praktik terbaik adalah:

  • Pastikan bahwa setiap file non-biner dikomit dengan LF on git repo (perilaku default).
  • Gunakan perintah ini untuk memastikan bahwa tidak ada file yang dikomit dengan CRLF: git grep -I --files-with-matches --perl-regexp '\r' HEAD( Catatan: pada klien windows hanya bekerja melalui git-bashdan pada klien linux hanya jika dikompilasi menggunakan --with-libpcredi./configure ).
  • Jika Anda menemukan file seperti itu dengan menjalankan perintah di atas, perbaiki. Ini melibatkan (setidaknya di linux):
    • set core.autocrlf=input( --- perbarui 3 - )
    • ubah file
    • Kembalikan perubahan (file masih ditampilkan sebagai diubah)
    • lakukan itu
  • Gunakan hanya minimum .gitattributes
  • Instruksikan pengguna untuk mengatur yang core.autocrlfdijelaskan di atas ke nilai standarnya.
  • Jangan hitung 100% jika ada .gitattributes. git-klien IDE mungkin mengabaikannya atau memperlakukannya secara berbeda.

Seperti yang dikatakan beberapa hal dapat ditambahkan dalam atribut git:

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

Saya pikir beberapa opsi aman lainnya .gitattributesdaripada menggunakan deteksi otomatis untuk file biner:

  • -text(mis. untuk *.zipatau *.jpgfile: Tidak akan diperlakukan sebagai teks. Dengan demikian tidak ada konversi akhir baris akan dicoba. Diff mungkin dilakukan melalui program konversi)
  • text !eol(misalnya untuk *.java, *.html:.. Diperlakukan sebagai teks, tapi preferensi gaya eol tidak diatur Jadi pengaturan klien digunakan)
  • -text -diff -merge(mis. untuk *.hugefile: Tidak diperlakukan sebagai teks. Tidak ada perbedaan / penggabungan)

--- PEMBARUAN SEBELUMNYA ---

Salah satu contoh menyakitkan klien yang akan melakukan file salah:

netbeans 8.2 (di windows), akan salah melakukan semua file teks dengan CRLF, kecuali Anda telah secara eksplisit ditetapkan core.autocrlfsebagai global . Ini bertentangan dengan perilaku klien standar git, dan menyebabkan banyak masalah kemudian, saat memperbarui / menggabungkan. Inilah yang membuat beberapa file tampak berbeda (meskipun tidak) bahkan ketika Anda kembali .
Perilaku yang sama di netbeans terjadi bahkan jika Anda telah menambahkan yang benar.gitattributes untuk proyek Anda.

Menggunakan perintah berikut setelah komit, setidaknya akan membantu Anda mendeteksi lebih awal apakah repo git Anda memiliki masalah akhir baris: git grep -I --files-with-matches --perl-regexp '\r' HEAD

Saya telah menghabiskan waktu berjam-jam untuk menggunakan sebaik mungkin .gitattributes, untuk akhirnya menyadari, bahwa saya tidak dapat mengandalkannya.
Sayangnya, selama editor berbasis JGit ada (yang tidak dapat menangani .gitattributesdengan benar), solusi yang aman adalah dengan memaksa LF di mana-mana bahkan pada tingkat editor.

Gunakan anti-CRLFdesinfektan berikut .

Marinos An
sumber
Saya setuju dengan Anda bahwa ini adalah pendekatan terbaik, tidak ada yang harus menggunakan editor tanpa dukungan LF. Tapi hati-hati dengan .gitattributesbaris Anda , ia memiliki conseque yang tidak disengaja di Git <2.10, lihat stackoverflow.com/a/29508751/2261442
phk
Sialan ... Saya punya banyak jawaban untuk advokasi saya git config --global core.autocrlf false, dan merekomendasikan untuk berurusan dengan eol dalam .gitattributesarahan saja.
VonC
5

Ini hanyalah solusi penyelesaian masalah:

Dalam kasus normal, gunakan solusi yang dikirimkan bersama git. Ini bekerja dengan baik dalam banyak kasus. Paksakan LF jika Anda berbagi pengembangan pada sistem berbasis Windows dan Unix dengan menetapkan .gitattributes .

Dalam kasus saya ada> 10 programmer yang mengembangkan proyek di Windows. Proyek ini diperiksa dengan CRLF dan tidak ada opsi untuk memaksa ke LF.

Beberapa pengaturan ditulis secara internal di mesin saya tanpa pengaruh pada format LF; sehingga beberapa file diubah secara global menjadi LF pada setiap perubahan file kecil.

Solusi saya:

Windows-Machines: Biarkan semuanya apa adanya. Tidak peduli dengan apa pun, karena Anda adalah pengembang default windows 'lone wolf' dan Anda harus menangani seperti ini: "Tidak ada sistem lain di dunia yang luas, bukan?"

Mesin Unix

  1. Tambahkan baris berikut ke bagian konfigurasi [alias]. Perintah ini mencantumkan semua file yang diubah (yaitu dimodifikasi / baru):

    lc = "!f() { git status --porcelain \
                 | egrep -r \"^(\?| ).\*\\(.[a-zA-Z])*\" \
                 | cut -c 4- ; }; f "
  2. Ubah semua file yang diubah ke dalam format dos:

    unix2dos $(git lc)
  3. Opsional ...

    1. Buat git hook untuk tindakan ini untuk mengotomatiskan proses ini

    2. Gunakan params dan sertakan dan modifikasi grepfungsi untuk mencocokkan hanya nama file tertentu, misalnya:

      ... | egrep -r "^(\?| ).*\.(txt|conf)" | ...
    3. Jangan ragu untuk membuatnya lebih nyaman dengan menggunakan pintasan tambahan:

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

      ... dan jalankan barang yang dikonversi dengan mengetik

      git c2dos
John Rumpel
sumber