Gitattributes Generator: สร้างไฟล์ .gitattributes จัดการ line ending, LFS และ language statistics ในคลิกเดียว
สร้างไฟล์ .gitattributes สำหรับ line-ending normalization, Git LFS tracking, language statistics overrides และ diff settings ได้ฟรี รวดเร็ว และทำงานฝั่ง client 100%
Table of Contents
Gitattributes Generator: สร้างไฟล์ .gitattributes จัดการ line ending, LFS และ language statistics ในคลิกเดียว
นักพัฒนาทุกคนเคยเจอสถานการณ์เดียวกัน: เปิด pull request แล้วเห็นไฟล์เปลี่ยนหลายร้อยบรรทัด ทั้งที่ความจริงแล้วไม่มีอะไรเปลี่ยนเลย สาเหตุมักมาจากใครสักคนในทีมเปิดไฟล์ด้วย editor ที่เขียน line ending ทับ ทำให้ Git คิดว่าโค้ดทั้งโปรเจกต์ถูกแก้ใหม่หมด ต้นตอเกือบทั้งหมดคือ line ending และทางแก้ถาวรอยู่ในไฟล์เล็ก ๆ ที่ทีมส่วนใหญ่ไม่เคยสร้างกันเลย นั่นคือ .gitattributes
ความจริงที่ไม่สบายใจก็คือ ปัญหา diff ระเบิดทั้งทีมจากการเปลี่ยนแค่ whitespace นั้น ซ่อนอยู่ในไฟล์เล็ก ๆ หนึ่งไฟล์ที่ไม่มีใครลงมือเขียน ทุกคนคิดว่ามีคนอื่นจะเพิ่มให้ และ setting core.autocrlf ในเครื่องของแต่ละคนก็ต่างกัน วนลูปแบบนี้ไม่มีวันจบ Gitattributes Generator ตัวฟรีช่วยปิดจบเรื่องนี้ โดยสร้างไฟล์ .gitattributes ที่สมบูรณ์พร้อมคอมเมนต์จากเทมเพลตที่คัดมาแล้ว ทั้ง line-ending normalization, Git LFS tracking patterns, linguist language-statistics overrides และ diff settings ก๊อปปี้หรือดาวน์โหลดได้ในไม่กี่วินาที ทำงานทั้งหมดในเบราว์เซอร์ของคุณ
และ line ending แค่จุดเริ่มต้น ไฟล์เดียวกันนี้ยังควบคุมวิธีที่ GitHub นับสัดส่วนภาษาใน repo, ไฟล์ใดปรากฏในไฟล์ดาวน์โหลดซอร์สโค้ด และวิดีโอขนาด 200 MB จะไม่ทำให้การ clone ของทีมช้าเหมือนกาแฟไม่ได้ชง ไฟล์เล็ก ๆ หนึ่งไฟล์ที่ commit ไว้ที่ root ของ repository แก้ทุกอย่างนี้ได้พร้อมกัน
ทำไมต้องใช้ Gitattributes Generator?
- หยุดปัญหา diff ข้ามแพลตฟอร์ม กฎอย่าง * text=auto ร่วมกับ eol=lf และ eol=crlf ทำให้เครื่อง Windows, macOS และ Linux checkout ไฟล์ที่มี line ending ตรงกัน ปัญหา diff ทั้งไฟล์แบบผีหลอกจึงหายไปตลอดกาล
- กันไฟล์ใหญ่ออกจาก Git history pattern filter=lfs ที่สร้างให้จัดการไฟล์ PSD, วิดีโอ และไฟล์ model ไปที่ Git LFS ทำให้ clone เร็วและขนาด push ไม่บวม
- แก้กราฟภาษาบน GitHub ให้ตรงความจริง กฎ linguist-generated และ linguist-vendored ช่วยกันไม่ให้ไฟล์ minified, lockfile และไลบรารีที่ vendor มากลืนโค้ดจริงที่คุณเขียน
- ได้ diff ที่อ่านง่ายขึ้น -diff ช่วยเงียบ lockfile ที่วุ่นวาย ส่วน diff=python หรือ diff=java ให้ Git ใช้ heuristic หา hunk ที่เหมาะกับแต่ละภาษา
- ไม่ต้องจำ syntax ไฟล์ attribute มีไวยากรณ์ที่เป็นมิตรน้อย ทั้ง pattern และ flag เครื่องมือนี้ประกอบกฎที่ถูกต้องพร้อมคอมเมนต์จาก checkbox ให้เอง
- ฟรี ไว และเป็นส่วนตัว เครื่องมือทำงานฝั่ง client 100% pattern และโครงสร้าง repository ของคุณไม่เคยออกจากเครื่อง
ฟีเจอร์หลัก
| ฟีเจอร์ | ทำอะไร |
|---|---|
| เทมเพลต line ending | สร้าง * text=auto บวก eol=lf สำหรับ shell script และ eol=crlf สำหรับสคริปต์ Windows อย่าง .bat, .cmd และ .ps1 |
| Git LFS tracking | สร้าง pattern filter=lfs diff=lfs merge=lfs -text สำหรับไฟล์ binary ขนาดใหญ่ เช่น รูปภาพ วิดีโอ และ archive |
| Language statistics | เพิ่ม linguist-generated=true และ linguist-vendored เพื่อให้กราฟภาษาของ GitHub สะท้อนซอร์สโค้ดจริง |
| Diff settings | ทำเครื่องหมาย lockfile เป็น -diff และผูก diff driver ของแต่ละภาษา เช่น diff=python, diff=go และ diff=rust |
| Binary handling | ระบุ wrapper JAR, ไฟล์ build และ asset เป็น binary เพื่อไม่ให้ Git พยายาม diff แบบ text |
| Custom rules | ช่องพิมพ์อิสระสำหรับเพิ่ม pattern และคอมเมนต์ของคุณเองต่อท้ายไฟล์ที่สร้าง |
รายละเอียดที่น่ารู้:
- พรีเซ็ตรายสายเทค เทมเพลตครอบคลุม JavaScript, Python, Go, Rust, Java, PHP, Ruby, C# และอื่น ๆ ปรับแต่งตาม lockfile และไฟล์ wrapper ของแต่ละ ecosystem
- Deduplicate ให้อัตโนมัติ ถ้าสองเทมเพลตสร้างกฎเดียวกัน หรือ custom pattern ของคุณซ้ำ เครื่องมือจะเก็บไว้ชุดเดียว
- Live preview หน้า preview อัปเดตทันทีที่ติ๊ก checkbox คุณจึงเห็นเนื้อหาไฟล์สุดท้ายเสมอ
วิธีใช้งาน
- เปิด Gitattributes Generator โหลดทันที ไม่ต้องติดตั้ง ไม่ต้องสมัครบัญชี
- เลือกเทมเพลตด้วย checkbox เริ่มจาก Line Endings แล้วเพิ่มเทมเพลตของสายเทคที่ตรงกับ repository ตามด้วย Git LFS, Language Stats หรือ Export Ignore ตามต้องการ ใช้ช่องค้นหากรองรายการให้เร็วขึ้น
- เพิ่ม custom pattern ในช่อง custom rules พิมพ์ pattern เพิ่มเติม เช่น *.onnx filter=lfs -text สำหรับไฟล์ model หรือบรรทัดคอมเมนต์ที่ขึ้นต้นด้วย #
- ตรวจ live preview หน้า preview แสดงเนื้อหา .gitattributes สุดท้ายพร้อมคอมเมนต์แบ่งหมวด และ deduplicate ให้แล้ว
- ก๊อปปี้หรือดาวน์โหลด กด Copy เพื่อคัดลอก หรือ Download เพื่อบันทึกไฟล์ชื่อ .gitattributes วางไว้ที่ root ของ repository, commit แล้วรัน git add --renormalize . หนึ่งครั้งเพื่อใช้กฎใหม่กับไฟล์เดิม
Line Endings, LFS และ Language Statistics
รูปแบบไฟล์ .gitattributes ดูเหมือนรหัสลับ แต่ทุกบรรทัดตอบคำถามเดียวเกี่ยวกับไฟล์กลุ่มหนึ่ง ตัวอย่างผลลัพธ์ที่เครื่องมือสร้างให้ พร้อมคำอธิบาย:
# Normalize all text files to LF in the repository * text=auto *.sh text eol=lf *.bat text eol=crlf # Store heavy binaries in Git LFS *.psd filter=lfs diff=lfs merge=lfs -text *.mp4 filter=lfs -text # Keep language statistics and diffs honest *.min.js linguist-generated docs/** linguist-vendored package-lock.json -diff
กลไกของ text=auto และ eol. * text=auto สั่งให้ Git normalize ทุกไฟล์ที่ตรวจพบว่าเป็น text ให้เป็น LF ใน repository ตอน commit ส่วน attribute eol ควบคุมว่าตอน checkout จะเขียนไฟล์ลง working tree แบบไหน: eol=lf สำหรับ shell script และไฟล์ config, eol=crlf สำหรับ batch script และ PowerShell ของ Windows ที่จำเป็นต้องใช้ CRLF จริง ๆ จุดต่างจาก core.autocrlf คือ setting นั้นอยู่ต่อเครื่องและแต่ละคนตั้งไม่เหมือนกัน แต่ attribute ถูก commit ไปกับ repository ทุก clone จึงทำงานเหมือนกันหมด นี่คือเหตุผลที่ไฟล์นี้ชนะ local configuration เสมอ
LFS tracking สำหรับไฟล์ binary. pattern อย่าง *.psd filter=lfs diff=lfs merge=lfs -text ส่งไฟล์ Photoshop ไปเก็บผ่าน Git LFS: filter ส่งเนื้อหาให้ LFS storage, flag -text กันการแทรกแซง line ending และ attribute diff กับ merge ไม่ให้ Git พยายามเทียบ binary blob สูตรเดียวกันใช้ได้กับวิดีโอ MP4, ไฟล์ ZIP และ model weight ของงาน machine learning
Language statistics overrides. แถบภาษาของ GitHub คำนวณโดย Linguist ซึ่งนับทุกอย่างที่เจอแบบตรงไปตรงมา การทำเครื่องหมาย *.min.js เป็น linguist-generated และ docs/** เป็น linguist-vendored ตัด noise ออกไป และ lockfile จะหายจากกราฟทันทีเมื่อถูก flag ว่า generated
Binary diff settings. attribute -diff (หรือ macro binary) บอก Git ไม่ให้สร้าง text diff ผลลัพธ์ใน code review จึงเป็น "Binary file changed" แทนบรรทัดอักขระงง ๆ หลายพันบรรทัด
กรณีใช้งานจริง
ทีมที่ใช้หลายแพลตฟอร์ม
ทีมที่แบ่งเป็นคนใช้ Windows notebook กับ Mac หรือ Linux คือเหยื่อตัวจริงของ line ending drift การ commit ไฟล์ที่สร้างจากเครื่องมือซึ่งมี * text=auto, eol=lf สำหรับ shell script และ eol=crlf สำหรับสคริปต์ Windows ทำให้ทุก checkout สอดคล้องกัน git status สะอาด และ review เจอแต่การเปลี่ยนแปลงจริง
Repository ที่มี asset ขนาดใหญ่
Design system พกไฟล์ PSD และ export จาก Figma ส่วนงาน game และ ML มี texture, recording และ model weight การสร้าง LFS tracking pattern จากเครื่องมือนี้เปลี่ยน path เหล่านั้นเป็น pointer file ทำให้ clone ใช้เวลาไม่กี่วินาทีแทนการรับประทานกาแฟ และ packfile ที่ Git ต้อง GC ก็เล็กลง
แก้สถิติภาษาบน GitHub ที่เพี้ยน
แทบไม่มีอะไรทำให้ใจหายไปกว่า repo ที่ถูกแสดงว่าเป็น CSS 90% เพราะ stylesheet ที่ bundle มา หรือ JSON 60% เพราะ lockfile เพียงไม่กี่บรรทัด linguist-generated และ linguist-vendored จากเครื่องมือช่วยคืนแถบภาษาให้สะท้อนโค้ดที่คุณดูแลจริง ซึ่งสำคัญกับ HR และผู้เยี่ยมชม open source ที่ตัดสิน repo จากการมองแวบเดียว
เก็บกวาด CRLF มรดกจาก Windows
สืบทอด repository ที่ครึ่งหนึ่งไฟล์เป็น CRLF อีกครึ่งเป็น LF? เพิ่มกฎ normalization ที่สร้างไว้ แล้วรัน git add --renormalize . ใน commit แยกต่างหาก Git จะเขียนไฟล์ที่ได้รับผลกระทบทั้งหมดเป็น LF ในรอบเดียว หลัง commit นั้น merge เสร็จ noise จะไม่กลับมาอีก
แนวปฏิบัติที่ดี
- Commit .gitattributes ก่อน renormalization ครั้งใหญ่ กฎต้องอยู่ใน repository ก่อนรัน git add --renormalize ไม่อย่างนั้นคำสั่งไม่มีอะไรให้บังคับใช้
- รัน git add --renormalize . ครั้งเดียว ใน commit ของตัวเอง การแยก renormalization ออกมาทำให้ diff ที่ใหญ่ตรวจสอบและ revert ได้ง่าย
- บอกทีมล่วงหน้าเรื่อง diff noise ครั้งเดียว เตือนเพื่อนร่วมทีม: pull request ที่เปิดอยู่ควร merge ก่อน และทุกคนควร rebase หลัง commit renormalization เข้า repo
- เชื่อ attribute มากกว่าตำนาน core.autocrlf local config ต่างกันทุกเครื่อง แต่กฎที่ commit ไว้ไม่ต่าง ให้เพื่อนร่วมทีมปล่อย core.autocrlf เป็นค่า default แล้วให้ไฟล์เป็นผู้ตัดสิน
- ใช้คู่กับ .editorconfig ไฟล์ attribute คุมสิ่งที่ Git เก็บ ส่วน Editorconfig Generator ช่วยให้ตัว editor เขียนไฟล์ให้สม่ำเสมอตั้งแต่ต้นทาง
- Review การเปลี่ยน attribute เหมือนโค้ด pattern เป็นของตะกละ กฎ * ที่ไม่ระวังอาจกระทบไฟล์เกินความจำเป็น จึงควรผ่าน pull request เสมอ
เริ่มสร้างไฟล์ .gitattributes ของคุณวันนี้
ค่าใช้จ่ายทั้งหมดคือไฟล์เล็ก ๆ หนึ่งไฟล์ และ commit renormalization หนึ่งครั้ง เข้าไปที่ Gitattributes Generator ตัวฟรี ติ๊กเทมเพลตให้ตรงกับสายเทคของคุณ เพิ่ม custom pattern แล้วก๊อปปี้ผลลัพธ์ใส่ repository ได้เลย diff ในอนาคตของคุณ รวมถึงเพื่อนร่วมทีมบนทุกระบบปฏิบัติการ จะเป็นพระคุณให้คุณเอง
เครื่องมืออื่นที่น่าสนใจ:
- Editorconfig Generator — รักษากฎการจัด format ของ editor ให้สม่ำเสมอควบคู่กับ Git attributes ของคุณ
- Git Branch Name Generator — สร้างชื่อ branch ที่สะอาดและเป็นไปตาม convention สำหรับทุก ticket
- Markdown Link Checker — ตรวจลิงก์ทุกอันใน README และเอกสารก่อนที่ผู้ใช้จะเจอลิงก์เสีย
ขอให้สนุกกับการ commit
คำถามที่พบบ่อย
ถ: .gitattributes มีผลกับตัว GitHub เองหรือเฉพาะ local clone?
ตอบ: ทั้งสองอย่าง attribute เรื่อง line ending และ diff มีผลกับทุก clone ส่วน linguist attribute เปลี่ยนวิธีที่ GitHub แสดงแถบภาษา และ export-ignore ควบคุมไฟล์ที่ปรากฏใน archive ดาวน์โหลดจากหน้าเว็บ
ถ: หลัง commit .gitattributes แล้วยังต้องตั้งค่า core.autocrlf อยู่ไหม?
ตอบ: ไม่จำเป็น attribute มีลำดับความสำคัญสูงกว่า core.autocrlf และเพราะถูก commit ไปกับ repository ทุกคนในทีมจึงได้พฤติกรรมเหมือนกัน แนะนำให้ปล่อย core.autocrlf เป็นค่า default แล้วให้ไฟล์เป็นตัวกำหนด
ถ: จะใช้กฎใหม่กับไฟล์ที่ commit ไปแล้วอย่างไร?
ตอบ: commit ไฟล์ .gitattributes ก่อน จากนั้นรัน git add --renormalize . หนึ่งครั้งแล้ว commit ผลลัพธ์ Git จะปรับใช้กฎ line ending ใหม่กับไฟล์ที่ track ทั้งหมดในการเปลี่ยนแปลงครั้งเดียวที่ review ได้
ถ: เครื่องมือนี้ปลอดภัยกับ repository ส่วนตัวหรือโค้ดลิขสิทธิ์หรือไม่?
ตอบ: ปลอดภัย เครื่องมือทำงานฝั่ง client 100% ในเบราว์เซอร์ pattern ที่คุณเลือกและพิมพ์ไม่เคยถูกอัปโหลดขึ้นเซิร์ฟเวอร์ใด ๆ ข้อมูลโครงสร้าง repository ของคุณจึงไม่หลุดออกจากเครื่อง
ถ: ควรวางไฟล์ .gitattributes ไว้ตำแหน่งไหน?
ตอบ: ที่ root ของ working tree เคียงข้าง .gitignore แม้จะวางใน subdirectory เพื่อจำกัดขอบเขตได้ แต่ไฟล์เดียวที่ root คือแบบที่ง่ายและพบมากที่สุด