Git สำหรับ SysAdmin คู่มือจัดการไฟล์คอนฟิกบน Linux
Posted inSysAdmin Ubuntu Linux

Git สำหรับ SysAdmin คู่มือจัดการไฟล์คอนฟิกบน Linux

เมื่อไฟล์คอนฟิกถูกแก้จนระบบล่ม เราจะย้อนกลับอย่างไร

สถานการณ์ที่ผู้ดูแลระบบพบเป็นประจำคือมีการแก้ไฟล์คอนฟิกเพียงไม่กี่บรรทัด แต่หลังจาก Restart Service แล้วระบบกลับทำงานผิดปกติ ปัญหาจะยิ่งซับซ้อนเมื่อมีผู้ดูแลหลายคน เพราะเราอาจไม่ทราบว่าใครแก้อะไร แก้เมื่อใด และไฟล์เดิมมีหน้าตาอย่างไร

การสำรองไฟล์ด้วยชื่ออย่าง nginx.conf.bak หรือ nginx.conf.old ช่วยได้ในระดับหนึ่ง แต่เมื่อไฟล์สำรองเพิ่มขึ้นเรื่อย ๆ วิธีนี้จะเริ่มจัดการยาก Git ช่วยเก็บประวัติการเปลี่ยนแปลง เปรียบเทียบไฟล์ สร้างจุดย้อนกลับ และแยกงานทดลองออกจากเวอร์ชันที่ใช้งานจริงได้อย่างเป็นระบบ

บทความนี้สอน Git ในมุมของ SysAdmin โดยเน้นงานที่ใช้จริง เช่น การดูแลไฟล์คอนฟิก Shell Script เอกสาร Runbook และ Repository กลางภายในเครื่อง ทดสอบบน Ubuntu Server 26.04 LTS ซึ่งมีแพ็กเกจ Git 2.53.0 ในคลังมาตรฐาน ณ เวลาที่จัดทำบทความ

Git ช่วยงาน SysAdmin อย่างไร

Git เป็น Distributed Version Control System แต่สำหรับผู้ดูแลระบบ ความสามารถที่สำคัญที่สุดคือการตอบคำถามต่อไปนี้ให้ได้อย่างรวดเร็ว

  • ไฟล์ใดถูกแก้ไข

  • บรรทัดใดเพิ่มหรือลบ

  • ใครเป็นผู้บันทึกการเปลี่ยนแปลง

  • การเปลี่ยนแปลงเกิดขึ้นเมื่อใด

  • จะย้อนกลับไปยังเวอร์ชันที่ทำงานได้อย่างไร

  • จะทดลองคอนฟิกใหม่โดยไม่กระทบสายงานหลักอย่างไร

Git ไม่ได้แทนที่ระบบ Backup เพราะ Git เหมาะกับไฟล์ข้อความและประวัติการแก้ไข ส่วน Backup ใช้กู้คืนข้อมูลทั้งระบบ ฐานข้อมูล ไฟล์ไบนารี และข้อมูลจากเหตุการณ์ร้ายแรง แนวทางที่ดีคือใช้ Git ควบคู่กับ Backup

Prerequisites

ก่อนเริ่มควรมีองค์ประกอบต่อไปนี้

  • Ubuntu Server 26.04 LTS

  • บัญชีผู้ใช้ที่ใช้ sudo ได้

  • ความรู้พื้นฐาน Linux Command Line

  • พื้นที่ทดลองใน Home Directory

  • โปรแกรมแก้ไขข้อความ เช่น nano หรือ vim

⚠️ คำสั่งที่เกี่ยวข้องกับไฟล์ใน /etc อาจกระทบ Service จริง ควรทดสอบใน Virtual Machine หรือ Lab ก่อนนำไปใช้บน Production Server

ติดตั้ง Git บน Ubuntu Server 26.04

อัปเดตรายการแพ็กเกจก่อนติดตั้ง

# อัปเดตรายการแพ็กเกจจาก Repository
sudo apt update

# ติดตั้ง Git จากคลังมาตรฐานของ Ubuntu
sudo apt install git -y

ตรวจสอบเวอร์ชัน

# แสดงเวอร์ชัน Git ที่ติดตั้ง
git --version

Ubuntu Server 26.04 LTS มีแพ็กเกจ Git 2.53.0 ในคลังมาตรฐาน แต่อาจมีเลข Revision ของ Ubuntu ต่อท้ายแตกต่างกันตามรอบอัปเดต

จับภาพหน้าจอผลลัพธ์ของคำสั่ง git –version และหน้าจอหลังติดตั้งสำเร็จ

ตั้งค่าผู้ใช้งาน Git ครั้งแรก

ทุก Commit ต้องมีชื่อและอีเมลผู้บันทึก ค่านี้เป็น Metadata ของประวัติ Git ไม่จำเป็นต้องเป็นบัญชี Linux

# กำหนดชื่อผู้บันทึก
git config --global user.name "SysAdmin Team"

# กำหนดอีเมลผู้บันทึก
git config --global user.email "admin@example.com"

# กำหนดชื่อ Branch เริ่มต้นเป็น main
git config --global init.defaultBranch main

# ใช้ nano เป็น Text Editor
git config --global core.editor nano

# ป้องกัน git pull จากการสร้าง Merge Commit โดยไม่ตั้งใจ
git config --global pull.ff only

ตรวจสอบค่าที่ตั้งไว้

# แสดงค่าคอนฟิก Git ระดับผู้ใช้
git config --global --list

Git รองรับการกำหนดชื่อ Branch เริ่มต้นผ่านตัวแปร init.defaultBranch ตามเอกสารทางการ

เข้าใจพื้นที่ทำงานสามส่วนของ Git

ก่อนใช้คำสั่งควรเข้าใจพื้นที่หลักสามส่วน

Working Tree

ไฟล์ที่กำลังแก้ไขอยู่ใน Directory ของโครงการ

Staging Area

พื้นที่เตรียมรายการเปลี่ยนแปลงก่อนสร้าง Commit ผู้ดูแลระบบสามารถเลือกได้ว่าจะบันทึกไฟล์ใดในรอบนั้น

Repository

ฐานข้อมูลประวัติที่เก็บ Commit ทั้งหมดไว้ใน Directory ชื่อ .git

Workflow พื้นฐานจึงเป็น แก้ไฟล์ ตรวจสอบ เลือกไฟล์ และ Commit

สร้าง Repository สำหรับไฟล์คอนฟิก

สร้างพื้นที่ทดลองใน Home Directory เพื่อไม่ให้กระทบไฟล์ระบบโดยตรง

# สร้าง Directory สำหรับ Lab
mkdir -p ~/git-lab/nginx-config

# เข้าไปยัง Directory
cd ~/git-lab/nginx-config

# เริ่มต้น Repository ใหม่
git init

คำสั่ง git init ใช้สร้าง Repository เปล่าหรือเริ่มต้น Repository ใน Directory ที่มีอยู่แล้ว

สร้างโครงสร้างสำหรับเก็บคอนฟิก สคริปต์ และเอกสาร

# สร้าง Directory แยกตามประเภทไฟล์
mkdir -p nginx scripts docs

# คัดลอกไฟล์ Nginx มาเป็นตัวอย่าง
cp /etc/nginx/nginx.conf nginx/nginx.conf

# สร้างเอกสารอธิบายโครงการ
printf '%s\n' "Nginx configuration managed with Git" > README.md

ตรวจสอบสถานะ

# ดูไฟล์ที่ยังไม่ถูกติดตาม
git status

ภาพแนะนำ 2

จับภาพผลลัพธ์ git status ซึ่งแสดง README.md และ Directory ที่เพิ่งสร้าง

สร้าง Commit แรก

เพิ่มไฟล์เข้าสู่ Staging Area

# เพิ่มไฟล์ทั้งหมดใน Directory ปัจจุบัน
git add .

# ตรวจสอบรายการที่เตรียม Commit
git status

# ตรวจสอบเนื้อหาที่กำลังจะถูก Commit
git diff --cached

เมื่อยืนยันว่ารายการถูกต้องแล้วจึงสร้าง Commit

# บันทึกสถานะเริ่มต้นของโครงการ
git commit -m "Add initial Nginx configuration"

ดูประวัติแบบย่อ

# แสดงประวัติ Commit แบบหนึ่งบรรทัด
git log --oneline

แนวคิดสำคัญคือ Commit ควรมีขนาดเล็กและมีวัตถุประสงค์เดียว เช่น ปรับ Timeout เพิ่ม Virtual Host หรือแก้ Backup Script ไม่ควรรวมการเปลี่ยนแปลงหลายเรื่องไว้ใน Commit เดียว

ตรวจสอบความแตกต่างก่อน Commit

ทดลองเพิ่ม Comment ในไฟล์คอนฟิก

# เพิ่ม Comment ต่อท้ายไฟล์ตัวอย่าง
printf '%s\n' "# Managed by Git" >> nginx/nginx.conf

# ดูไฟล์ที่เปลี่ยนแปลง
git status --short

# เปรียบเทียบ Working Tree กับ Commit ล่าสุด
git diff


เมื่อเห็นความแตกต่างและยืนยันว่าถูกต้องแล้วจึงบันทึก

# เพิ่มเฉพาะไฟล์ที่ต้องการ
git add nginx/nginx.conf

# ตรวจสอบสิ่งที่อยู่ใน Staging Area
git diff --cached

# สร้าง Commit
git commit -m "Document Git management in Nginx config"

สำหรับ SysAdmin คำสั่ง git diff และ git diff –cached สำคัญมาก เพราะช่วยลดโอกาสบันทึก Password Token Private Key หรือค่าที่ไม่ควรเผยแพร่เข้า Repository

ใช้ .gitignore ป้องกันไฟล์ที่ไม่ควรถูกติดตาม

สร้างไฟล์ .gitignore

# สร้างรายการไฟล์ที่ Git ต้องละเว้น
cat > .gitignore <<'EOF'
*.log
*.tmp
*.swp
.env
secrets/
backup/
EOF

เพิ่มและ Commit

# เพิ่มไฟล์กฎการละเว้น
git add .gitignore

# บันทึกกฎ
git commit -m "Add ignore rules for temporary and secret files"

⚠️ .gitignore ป้องกันเฉพาะไฟล์ที่ยังไม่ถูกติดตาม หาก Secret เคยถูก Commit แล้ว การเพิ่มชื่อไฟล์ภายหลังจะไม่ลบข้อมูลออกจากประวัติ Git ต้องเปลี่ยน Credential ทันทีและทำความสะอาดประวัติด้วยกระบวนการที่เหมาะสม

สร้าง Branch สำหรับทดลองแก้คอนฟิก

Branch ช่วยแยกงานทดลองออกจาก main ทำให้เราพัฒนาและตรวจสอบก่อนรวมเข้าสายงานหลัก

# สร้าง Branch ใหม่และสลับไปใช้งาน
git switch -c tune-worker

# ตรวจสอบ Branch ปัจจุบัน
git branch --show-current

แก้ไฟล์ตัวอย่าง

# เปิดไฟล์ด้วย nano
nano nginx/nginx.conf

หลังแก้ไขให้ตรวจสอบและ Commit

# ตรวจสอบความแตกต่าง
git diff

# เพิ่มไฟล์และบันทึก
git add nginx/nginx.conf
git commit -m "Tune Nginx worker settings"

กลับไปที่ main และรวม Branch

# กลับสู่ Branch หลัก
git switch main

# รวมการเปลี่ยนแปลงจาก Branch ทดลอง
git merge tune-worker

# ลบ Branch ที่รวมงานเรียบร้อยแล้ว
git branch -d tune-worker

เอกสารอ้างอิงทางการของ Git แยกคำสั่ง branch merge log stash และ rebase ไว้เป็นกลุ่มคำสั่งหลักสำหรับจัดการประวัติและสายงาน

ภาพแนะนำ 3

จับภาพกราฟประวัติจากคำสั่งต่อไปนี้

# แสดงกราฟ Branch และ Commit
git log --oneline --graph --decorate --all

ยกเลิกการแก้ไขอย่างปลอดภัย

Git มีหลายวิธีย้อนกลับ ต้องเลือกให้ตรงกับสถานะของไฟล์

ยกเลิกไฟล์ที่ยังไม่ได้ git add

# คืนไฟล์ให้เหมือน Commit ล่าสุด
git restore nginx/nginx.conf

⚠️ การใช้ git restore กับไฟล์ที่ยังไม่ได้บันทึกจะทำให้การแก้ไขใน Working Tree หายไป ควรตรวจสอบ git diff ก่อนเสมอ

นำไฟล์ออกจาก Staging Area

# ยกเลิกการเตรียม Commit แต่เก็บเนื้อหาที่แก้ไว้
git restore --staged nginx/nginx.conf

ย้อนกลับ Commit ที่แชร์ให้ทีมแล้ว

# ดู Commit ID
git log --oneline

# สร้าง Commit ใหม่เพื่อย้อนผลของ Commit เดิม
git revert COMMIT_ID

git revert เหมาะกับ Repository ที่ใช้งานร่วมกัน เพราะไม่เขียนประวัติเดิมทับ แต่เพิ่ม Commit ใหม่ที่ทำหน้าที่ย้อนการเปลี่ยนแปลง

พักงานชั่วคราวด้วย git stash

บางครั้งกำลังแก้ไฟล์อยู่ แต่ต้องสลับไปแก้เหตุขัดข้องเร่งด่วน หากยังไม่พร้อม Commit สามารถพักการเปลี่ยนแปลงได้

# พักการแก้ไขที่ยังไม่พร้อม Commit
git stash push -m "Work in progress"

# ดูรายการงานที่พักไว้
git stash list

# นำงานล่าสุดกลับมาและลบออกจากรายการ Stash
git stash pop

คู่มือผู้ใช้ Git ระบุว่า stash ใช้เก็บการเปลี่ยนแปลงไว้ชั่วคราวก่อนทำงานอื่นหรือก่อน Merge แล้วจึงนำกลับมาใช้ภายหลัง

สร้าง Repository กลางภายใน Server

สำหรับ Lab เราสามารถสร้าง Bare Repository เพื่อจำลองศูนย์กลางรับ Push จากผู้ดูแลระบบหลายคน

# สร้าง Directory สำหรับ Repository กลาง
sudo mkdir -p /srv/git

# สร้าง Bare Repository
sudo git init --bare /srv/git/nginx-config.git

# เปลี่ยนเจ้าของให้ผู้ใช้ปัจจุบันสำหรับ Lab
sudo chown -R "$USER" /srv/git/nginx-config.git

เชื่อม Repository ที่กำลังทำงานเข้ากับ Repository กลาง

# กลับไปยังโครงการ
cd ~/git-lab/nginx-config

# เพิ่ม Repository กลางชื่อ origin
git remote add origin /srv/git/nginx-config.git

# ส่ง Branch main ไปยัง origin
git push -u origin main

ทดสอบ Clone ไปยัง Directory ใหม่

# Clone Repository กลางเพื่อทดสอบ
git clone /srv/git/nginx-config.git ~/git-lab/nginx-config-copy

# ตรวจสอบประวัติจาก Repository ที่ Clone
cd ~/git-lab/nginx-config-copy
git log --oneline

Bare Repository ไม่มี Working Tree และเหมาะสำหรับเป็นจุดกลางรับ Push แต่ตัวอย่างนี้เป็น Lab แบบผู้ใช้เดียว หากใช้งานจริงหลายคนควรออกแบบสิทธิ์ด้วย Linux Group SSH Key หรือระบบอย่าง GitLab Gitea และ Gitolite โดย Ubuntu Server documentation ยก Gitolite เป็นทางเลือกสำหรับ Git Server ที่รองรับผู้ใช้หลายคนและการควบคุมสิทธิ์

Workflow ที่แนะนำสำหรับงานจริง

แนวทางทำงานที่ลดความผิดพลาดมีลำดับดังนี้

  1. ใช้ git pull ก่อนเริ่มงานเมื่อทำงานร่วมกับทีม

  2. สร้าง Branch แยกตามงานหรือ Ticket

  3. แก้ไขไฟล์ใน Working Tree

  4. ใช้ git diff ตรวจทุกบรรทัด

  5. ทดสอบ Syntax และ Service ใน Lab

  6. ใช้ git add เฉพาะไฟล์ที่เกี่ยวข้อง

  7. ใช้ git diff –cached ตรวจอีกครั้ง

  8. Commit ด้วยข้อความที่อธิบายเหตุผล

  9. Merge หลังผ่านการ Review

  10. ติด Tag ก่อน Release สำคัญ

ตัวอย่างสร้าง Tag

# สร้าง Tag สำหรับเวอร์ชันที่ผ่านการทดสอบ
git tag -a v1.0 -m "Stable Nginx configuration"

# แสดงรายการ Tag
git tag

การทดสอบและ Verify

หลังทำ Lab ให้ตรวจสอบองค์ประกอบต่อไปนี้

# ต้องอยู่บน Branch main
git branch --show-current

# Working Tree ควรไม่มีไฟล์ค้าง
git status

# ต้องเห็นประวัติ Commit ที่สร้างไว้
git log --oneline --graph --decorate --all

# ต้องเห็น Repository กลางชื่อ origin
git remote -v

# ตรวจสอบว่าไฟล์ Secret ถูกละเว้น
touch .env
git status --short

หาก .env ไม่ปรากฏในผลลัพธ์ แสดงว่ากฎ .gitignore ทำงาน หาก git status รายงาน Working Tree clean แสดงว่าไม่มีการเปลี่ยนแปลงที่ยังไม่ได้ Commit

ภาพแนะนำ 4

จับภาพผลลัพธ์ git log แบบกราฟ git remote -v และ git status ที่แสดง Working Tree clean

ข้อผิดพลาดที่ SysAdmin ควรหลีกเลี่ยง

  • Commit ไฟล์ .env Password Token Private Key หรือ Certificate Private Key

  • ใช้ git add . โดยไม่ตรวจ git status และ git diff –cached

  • แก้ไฟล์ Production โดยไม่มี Branch หรือจุดย้อนกลับ

  • ใช้ git reset แบบรุนแรงใน Repository ที่แชร์กับทีม

  • Commit ไฟล์ Backup ขนาดใหญ่ Log และ Database Dump

  • ใช้ Git แทนระบบ Backup ทั้งหมด

  • เขียน Commit Message กว้างเกินไป เช่น update หรือ fix

  • Reload Service โดยไม่ตรวจ Syntax ก่อน

สำหรับ Nginx ควรใช้ sudo nginx -t ก่อน Reload ส่วน Apache ควรใช้ sudo apachectl configtest และสำหรับ systemd service ควรตรวจ sudo systemctl status ชื่อบริการ หลัง Deploy

สรุป

Git เป็นเครื่องมือพื้นฐานที่ SysAdmin ควรใช้ ไม่ใช่เฉพาะนักพัฒนา เพราะช่วยสร้างประวัติของไฟล์คอนฟิก สคริปต์ Automation เอกสาร Runbook และ Infrastructure as Code ได้อย่างตรวจสอบย้อนกลับได้

หัวใจสำคัญไม่ใช่การจำคำสั่งจำนวนมาก แต่คือการสร้างนิสัยทำงานแบบ ตรวจสอบความแตกต่างก่อน Commit แยกงานด้วย Branch ไม่เก็บ Secret และทดสอบก่อน Deploy เมื่อทำ Workflow นี้จนเป็นปกติ การแก้ปัญหาและการย้อนกลับระบบจะรวดเร็วและปลอดภัยกว่าการเก็บไฟล์ .bak หลายชุดอย่างชัดเจน

—
Write by Dr.Arnut Ruttanatirakul
(c) SysAdmin Knowledge
https://www.sysadmin.in.th
August  6, 2026

Tags: