GitHub คืออะไร ต่างจาก Git อย่างไรสำหรับผู้ใช้ VPS

GitHub คืออะไร

GitHub คือบริการโฮสต์ที่จัดเก็บ Git repositories และสร้างเว็บไซต์ครอบไว้ Git เป็นโปรแกรมควบคุมเวอร์ชันที่ทำงานบนคอมพิวเตอร์หรือเซิร์ฟเวอร์ของคุณเอง GitHub เป็นผลิตภัณฑ์ของบริษัทหนึ่งที่สร้างขึ้นบนพื้นฐานของ Git ซึ่ง Microsoft เป็นเจ้าของตั้งแต่ปี 2018 คุณสามารถใช้งาน Git ได้ทุกวันโดยไม่จำเป็นต้องเปิด GitHub แต่คุณไม่สามารถใช้งาน GitHub ได้หากไม่มี Git

ความแตกต่างนี้มีความสำคัญทันทีที่คุณเป็นเจ้าของ VPS (virtual private server) Git คือสิ่งที่ใช้บันทึกประวัติของไฟล์ config และสคริปต์ deploy ของคุณ ส่วน GitHub คือที่ที่สำเนาของประวัตินั้นถูกเก็บไว้ในกรณีที่เซิร์ฟเวอร์ไม่มีสำเนา รวมถึงเป็นพื้นที่สำหรับรันการ build และการตรวจสอบโค้ด คู่มือนี้จะดำเนินตามตัวอย่างหนึ่งตั้งแต่โฟลเดอร์ว่างเปล่าไปจนถึงการ deploy บนเซิร์ฟเวอร์ และจะนิยามคำศัพท์ใหม่แต่ละคำเมื่อคุณพบเป็นครั้งแรก

สิ่งที่ Git ทำด้วยตัวเอง

Git คือระบบควบคุมเวอร์ชัน (version control system) ซึ่งทำหน้าที่บันทึกสถานะของไดเรกทอรีเมื่อเวลาผ่านไป เพื่อให้คุณตรวจสอบได้ว่ามีการเปลี่ยนแปลงอะไรบ้าง เมื่อใด และเพราะเหตุใด Git ถูกเขียนขึ้นในปี 2005 เพื่อใช้ในการพัฒนา Linux kernel โดยมีลักษณะเป็นแบบ distributed ซึ่งหมายความว่าทุกสำเนาของ repository จะเก็บประวัติทั้งหมดไว้ทั้งหมด ในการออกแบบจึงไม่มีเซิร์ฟเวอร์กลาง แล็ปท็อปของเพื่อนร่วมงานถือเป็นสำเนาที่สมบูรณ์เช่นเดียวกับเซิร์ฟเวอร์ใดๆ

ให้ติดตั้งโปรแกรมและตั้งค่าตัวตนของคุณ Git จะปฏิเสธการบันทึก commit หากไม่มีชื่อและที่อยู่อีเมล เนื่องจากข้อมูลทั้งสองอย่างจะถูกเขียนลงไปในตัว commit เอง

sudo apt update && sudo apt install -y git
git --version
git config --global user.name "Your Name"
git config --global user.email "you@example.com"

บน Ubuntu 24.04 คำสั่ง git --version จะแสดงผลลัพธ์เป็น git version 2.43.0 สำหรับ release ใดๆ ในช่วงไม่กี่ปีที่ผ่านมาจะมีพฤติกรรมเหมือนกันในทุกหัวข้อด้านล่างนี้

ตัวอย่าง: คลังเก็บไฟล์สำหรับ deploy บน VPS ของคุณ

Repository หรือที่เรียกสั้นๆ ว่า "repo" คือไดเรกทอรีที่ Git กำลังติดตามอยู่ ไดเรกทอรีจะกลายเป็น repository เมื่อคุณรันคำสั่ง git init ซึ่งจะสร้างโฟลเดอร์ซ่อนชื่อ .git ขึ้นมาภายใน โฟลเดอร์นั้นแหละคือ repository หากคุณลบ .git ทิ้ง คุณก็จะเหลือเพียงไดเรกทอรีธรรมดาที่ไม่มีประวัติการแก้ไขใดๆ หลงเหลืออยู่

mkdir vps-deploy && cd vps-deploy
git init -b main
printf '.env\n*.key\n' > .gitignore

-b main ใช้สำหรับตั้งชื่อ branch แรกให้เป็น main หากคุณไม่ระบุ Git จะแสดงคำแนะนำขนาดยาวเกี่ยวกับชื่อ branch เริ่มต้นแทน .gitignore ใช้สำหรับระบุ path ที่ Git ห้ามติดตามโดยเด็ดขาด คุณควรเขียนชื่อไฟล์ที่มีข้อมูลลับลงไปในนี้ตั้งแต่วันแรก เพราะหากไฟล์ถูก commit ไปแล้วครั้งหนึ่ง ข้อมูลนั้นจะยังคงอยู่ในประวัติแม้ว่าคุณจะลบไฟล์ต้นฉบับทิ้งไปแล้วก็ตาม และการลบไฟล์ออกจากประวัติอย่างถูกต้องนั้นหมายถึงการต้องเขียนประวัติ commit ใหม่ทั้งหมดที่เกิดขึ้นหลังจากนั้น

Commit: หน่วยของประวัติการทำงาน

ตอนนี้ให้เพิ่มสคริปต์และบันทึกการเปลี่ยนแปลงนั้น

printf '#!/bin/sh\nsudo systemctl restart caddy\n' > restart.sh
git add restart.sh .gitignore
git commit -m "Add restart script and gitignore"
git log --oneline

git add เป็นการย้ายการเปลี่ยนแปลงเข้าสู่ staging area ซึ่งเป็นรายการสิ่งที่กำลังจะถูกรวมเข้าไปใน commit ถัดไป git commit จะเขียนรายการนั้นลงในประวัติการทำงานเป็นหนึ่งรายการ โดย commit จะเก็บภาพรวม (snapshot) ของทุกไฟล์ที่ถูกติดตาม, ข้อความอธิบาย, ผู้เขียน, การประทับเวลา และตัวชี้ไปยัง commit ก่อนหน้า git log --oneline จะแสดงผลลัพธ์บรรทัดละหนึ่ง commit โดยแต่ละบรรทัดจะขึ้นต้นด้วย hash สั้นๆ เช่น a1b2c3d ซึ่ง hash ดังกล่าวคือชื่อของ commit นั้น และคำสั่ง Git เกือบทุกคำสั่งสามารถใช้ชื่อนี้อ้างอิงได้

หากข้ามขั้นตอน git add แล้วใช้ git commit คำตอบที่ได้คือ no changes added to commit (use "git add" and/or "git commit -a") ซึ่งไม่มีอะไรเสียหาย Git เพียงแค่แจ้งให้ทราบว่า staging area ว่างเปล่า จึงไม่มีสิ่งใดให้ทำ snapshot git status คือคำสั่งที่ควรเรียกใช้เมื่อใดก็ตามที่คุณสับสน เพราะคำสั่งนี้จะระบุชื่อ branch ปัจจุบัน, การเปลี่ยนแปลงที่อยู่ใน staging และไฟล์ที่ Git มองเห็นแต่ไม่ได้ติดตามอยู่

Branch: ประวัติอีกสายหนึ่ง

Branch คือตัวชี้ที่เคลื่อนที่ได้ซึ่งชี้ไปยัง commit หนึ่งๆ main เป็น branch หนึ่ง และไม่ได้มีความพิเศษใดๆ ใน Git การสร้าง branch ใหม่ไม่มีค่าใช้จ่ายใดๆ เพราะ Git เพียงแค่เขียนตัวชี้ใหม่ขึ้นมาแทนที่จะคัดลอกไฟล์ของคุณ

git switch -c add-backup
printf '#!/bin/sh\nrestic backup /srv\n' > backup.sh
git add backup.sh
git commit -m "Add nightly backup"
git switch main
ls

หลังจาก git switch main แล้ว backup.sh จะหายไปจากรายการไฟล์ ไม่มีการลบข้อมูลใดๆ เกิดขึ้น ไฟล์ดังกล่าวยังคงมีอยู่บน branch add-backup แต่ main ไม่เคยมีไฟล์นี้มาก่อน Git จึงนำไฟล์ออกจาก working directory ของคุณเมื่อคุณย้าย branch สิ่งนี้ทำให้ทุกคนประหลาดใจในครั้งแรกที่พบ git switch add-backup จะนำไฟล์นั้นกลับมาให้คุณ

รีโมท: จุดที่ GitHub ปรากฏตัวขึ้นในที่สุด

ทุกขั้นตอนที่ผ่านมาทำงานบนเครื่องเดียวโดยไม่มีเครือข่ายเลย รีโมท (remote) คือ URL ที่ตั้งชื่อไว้สำหรับสำเนาอื่นของ repository เดียวกัน GitHub ทำหน้าที่โฮสต์สำเนาหนึ่งในนั้นให้คุณ ชื่อมาตรฐานสำหรับรีโมทหลักคือ origin

สร้าง repository เปล่าผ่านเว็บไซต์ GitHub จากนั้นเชื่อมต่อเข้ากับ repository นั้น แนะนำให้ใช้ SSH แทน HTTPS เนื่องจาก SSH key เป็นไฟล์ที่คุณควบคุมเองและไม่มีวันหมดอายุเหมือนกับ personal access token

ssh-keygen -t ed25519 -C "vps-deploy"
cat ~/.ssh/id_ed25519.pub
ssh -T git@github.com

คัดลอก public key ที่แสดงผลไปวางในหน้า SSH keys ของบัญชี GitHub ของคุณ จากนั้นทดสอบอีกครั้ง หาก key ทำงานถูกต้องจะตอบกลับด้วย Hi yourname! You've successfully authenticated, but GitHub does not provide shell access. โดย GitHub จะไม่ให้สิทธิ์ shell แก่คุณ ดังนั้นการปฏิเสธดังกล่าวถือเป็นกรณีที่สำเร็จ ส่วน git@github.com: Permission denied (publickey). หมายความว่า key ของคุณไม่ได้ถูกส่งไปหรือถูกปฏิเสธ ให้ตรวจสอบว่าคุณได้คัดลอกไฟล์ .pub ไปวาง ไม่ใช่ไฟล์ private key ที่อยู่คู่กัน

git remote add origin git@github.com:yourname/vps-deploy.git
git push -u origin main

git push จะส่ง commit ของคุณไปยังรีโมท -u จะบันทึกว่า main ในเครื่องติดตาม main บนรีโมท ดังนั้นในภายหลังคุณสามารถใช้เพียง git push ได้เลย git clone <url> คือการทำงานย้อนกลับเมื่อใช้งานบนเครื่องใหม่ โดยจะคัดลอก repository ทั้งหมดพร้อมประวัติและตั้งค่า origin ให้คุณโดยอัตโนมัติ รีโมทแบบ HTTPS ก็ใช้งานได้เช่นกัน โดยสื่อสารผ่านโปรโตคอลเดียวกับหน้าเว็บทั่วไป ซึ่งช่วยได้ในกรณีที่เครือข่ายบล็อกพอร์ตขาออก 22 หากต้องการรายละเอียดเพิ่มเติม องค์ประกอบของ HTTP request จะอธิบายกลไกการทำงานไว้

Pull requests, issues และ forks: ส่วนประกอบที่เป็นของ GitHub ไม่ใช่ Git

เนื้อหาทั้งหมดข้างต้นคือ Git ซึ่งทำงานร่วมกับเซิร์ฟเวอร์ใดก็ได้ แต่สามคำต่อไปนี้เป็นฟีเจอร์ของ GitHub โดยเฉพาะ ผู้ให้บริการรายอื่นอาจคัดลอกฟีเจอร์เหล่านี้ไปใช้ แต่ตัว Git เองไม่รู้จักฟีเจอร์เหล่านี้

Pull request (PR) คือคำขอเพื่อรวม branch หนึ่งเข้ากับอีก branch หนึ่ง โดยมีหน้าเว็บสำหรับอภิปรายประกอบ คุณ push add-backup แล้วเปิด PR ไปยัง main จากนั้นเว็บไซต์จะแสดงความแตกต่างแบบ commit ต่อ commit ผู้ใช้งานสามารถแสดงความคิดเห็นในแต่ละบรรทัดได้ ระบบตรวจสอบอัตโนมัติจะรายงานผลผ่านหรือล้มเหลวสำหรับ branch นั้น เมื่อคลิก merge แล้ว GitHub จะดำเนินการรวมโค้ดบนสำเนาของตนเอง จากนั้นจึงอัปเดต main ชื่อนี้มาจากขั้นตอนการทำงานดั้งเดิมที่คุณขอให้ผู้ดูแลโปรเจกต์ ดึง (pull) branch ของคุณเข้าไปรวมกับของพวกเขา

Issue คือกระทู้ที่มีหมายเลขกำกับสำหรับแจ้งบั๊กหรือมอบหมายงาน สิ่งนี้อยู่ในฐานข้อมูลของ GitHub ไม่ได้อยู่ใน repository ของคุณ ซึ่งเป็นเรื่องที่ควรทราบก่อนเลือกผู้ให้บริการ: หากคุณ clone repository มา คุณจะได้ทุก commit แต่จะไม่ได้ issue เลย การดึงข้อมูล issue ออกมาต้องเรียกใช้งานผ่าน API

Fork คือสำเนาฝั่งเซิร์ฟเวอร์ของ repository ผู้อื่นที่คุณเป็นเจ้าของ คุณมีสิทธิ์เขียนข้อมูลในสำเนานั้น คุณสามารถ push branch ไปยังสำเนาของคุณ แล้วเปิด pull request จากสำเนาของคุณกลับไปยังต้นทาง นี่คือวิธีที่คุณใช้มีส่วนร่วมกับโปรเจกต์ที่ผู้ดูแลไม่เคยรู้จักคุณมาก่อน Fork คือ clone ที่อยู่บน GitHub และจดจำที่มาของมันได้

ซอฟต์แวร์สามารถอ่านข้อมูลทั้งสามส่วนนี้ผ่าน API เดียวกับที่มนุษย์ใช้ เอเจนต์ตรวจสอบ pull request ที่คุณรันบนเซิร์ฟเวอร์ของคุณเอง จะคอยเฝ้าดู PR ใหม่ๆ อ่านค่า diff และโพสต์ความคิดเห็นในบรรทัดต่างๆ ข้อตกลงอย่างเช่น ไฟล์ AGENTS.md ที่ root ของ repository เกิดขึ้นเพราะปัจจุบัน repository ถูกอ่านโดยเครื่องมือต่างๆ เช่นเดียวกับที่มนุษย์อ่าน

สิ่งที่ GitHub ทำจริง ๆ สำหรับเจ้าของ VPS

เริ่มต้นด้วยการจัดเก็บข้อมูลภายนอกเซิร์ฟเวอร์ สคริปต์สำหรับ deploy และ playbooks ของคุณควรอยู่ในที่ที่ไม่ใช่เซิร์ฟเวอร์ที่ถูกกำหนดค่าเหล่านั้น ให้สร้าง VPS ใหม่จากอิมเมจที่สะอาด จากนั้น clone และรันสคริปต์ เก็บ repository นั้นไว้เป็นส่วนตัวและกำหนด deploy key ให้กับเซิร์ฟเวอร์ ซึ่งเป็น SSH key ที่ลงทะเบียนไว้กับ repository เดียวแทนที่จะเป็นทั้งบัญชีของคุณ โดยตั้งค่าให้เป็นแบบอ่านอย่างเดียว (read-only) หาก deploy key แบบอ่านอย่างเดียวรั่วไหล จะเปิดเผยเพียง repository เดียว แต่หาก key ของบัญชีรั่วไหล จะเปิดเผยทุกอย่างที่คุณสามารถ push ไปได้

sudo git clone git@github.com:yourname/vps-deploy.git /srv/vps-deploy
cd /srv/vps-deploy
git pull --ff-only

--ff-only ปฏิเสธที่จะสร้าง merge commit บนเซิร์ฟเวอร์ที่ทำหน้าที่เพียงรับการเปลี่ยนแปลงเท่านั้น การ merge มักเป็นความผิดพลาด ดังนั้น flag นี้จะเปลี่ยนประวัติที่ซับซ้อนให้กลายเป็นข้อผิดพลาดที่ชัดเจนคือ fatal: Not possible to fast-forward, aborting. มีบางอย่างเปลี่ยนแปลงบนเซิร์ฟเวอร์ซึ่งไม่ควรเกิดขึ้น ให้ตรวจสอบก่อนที่คุณจะ pull อีกครั้ง

หากคุณ clone ในฐานะ root แล้วรัน Git ในฐานะผู้ใช้อื่น คุณจะพบกับ fatal: detected dubious ownership in repository at '/srv/vps-deploy' Git จะปฏิเสธการอ่าน repository ที่เป็นของผู้ใช้อื่น เนื่องจาก .git/config ที่เป็นอันตรายอาจทำให้ Git รันคำสั่งได้ ให้แก้ไขความเป็นเจ้าของด้วย chown แทนการเพิ่มข้อยกเว้น safe.directory เนื่องจากข้อยกเว้นจะเพียงแค่ปิดการแจ้งเตือนโดยไม่ได้กำจัดสาเหตุที่แท้จริงออกไป

GitHub Actions: ไปป์ไลน์สำหรับการ build และ deploy

Actions คือระบบ CI/CD (continuous integration และ continuous delivery) ของ GitHub คุณสามารถ commit ไฟล์ YAML ไว้ภายใต้ .github/workflows/ แล้ว GitHub จะเรียกใช้งานไฟล์นั้นเมื่อเกิดเหตุการณ์ที่คุณกำหนดไว้

name: check
on:
  push:
    branches: [main]
jobs:
  shellcheck:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v7
      - run: sudo apt-get update && sudo apt-get install -y shellcheck
      - run: shellcheck *.sh

ไฟล์ดังกล่าวเรียกว่า workflow โดยหนึ่ง job จะทำงานบนเครื่องหนึ่งเครื่อง และหนึ่ง step คือหนึ่งคำสั่งหรือหนึ่ง action ที่ถูกเผยแพร่ไว้ uses: จะดึง action มาจาก repository อื่น และ @v7 จะเป็นการระบุเวอร์ชันหลัก (v7 คือเวอร์ชันปัจจุบันสำหรับ actions/checkout ณ เดือนสิงหาคม 2026) คุณควรระบุเวอร์ชันเสมอ เพราะการไม่ระบุเวอร์ชันหมายความว่าโค้ดที่คุณไม่ได้ตรวจสอบจะถูกนำมาทำงานโดยมีสิทธิ์เข้าถึงข้อมูลลับ (secrets) ของคุณ

runs-on: ubuntu-latest เป็นการร้องขอ virtual machine เครื่องใหม่จาก GitHub ซึ่งจะถูกลบทิ้งเมื่อ job สิ้นสุดลง Runner มาตรฐานนั้นเปิดให้ใช้งานฟรีสำหรับ repository สาธารณะ และแผนบริการฟรีจะรวมเวลาใช้งาน 2,000 นาทีต่อเดือนสำหรับ repository ส่วนตัว ณ เดือนสิงหาคม 2026 โปรดตรวจสอบหน้าแสดงราคาปัจจุบันก่อนที่คุณจะวางแผนงบประมาณจากตัวเลขดังกล่าว

ข้อมูลลับ (secrets) จะถูกจัดเก็บไว้ในการตั้งค่าของ repository และอ่านผ่าน ${{ secrets.DEPLOY_KEY }} สำหรับ workflow ที่ถูกกระตุ้นโดย pull request จาก fork นั้น จะได้รับ token ที่มีสิทธิ์อ่านอย่างเดียวและไม่สามารถเข้าถึงข้อมูลลับเหล่านั้นได้ เพื่อป้องกันไม่ให้บุคคลภายนอกเปิด PR ที่มีจุดประสงค์เพียงเพื่อสั่งพิมพ์ข้อมูลลับเหล่านั้นออกมา

การรัน Actions runner บน VPS ของคุณเอง

runs-on: self-hosted จะส่งงานไปยังเครื่องที่คุณเป็นเจ้าของแทน หน้าการตั้งค่า runner ของ repository จะให้คำสั่งดาวน์โหลด, ที่อยู่เว็บของ repository และ registration token ซึ่งมีอายุการใช้งาน 1 ชั่วโมง ให้นำข้อมูลสองอย่างหลังไปใส่ใน REPO_URL และ RUNNER_TOKEN จากนั้นการตั้งค่าจะมีเพียง 3 คำสั่งเท่านั้น

./config.sh --url "$REPO_URL" --token "$RUNNER_TOKEN"
sudo ./svc.sh install
sudo ./svc.sh start
./svc.sh status

svc.sh status ควรรายงานสถานะ service ว่า active และแสดงบรรทัด log ล่าสุด ตัว runner จะเปิดการเชื่อมต่อ HTTPS ขาออกไปยัง GitHub เพื่อขอรับงาน ดังนั้นคุณจึงไม่จำเป็นต้องเปิดพอร์ตขาเข้าใดๆ สำหรับมัน svc.sh install จะเขียน systemd unit ซึ่งเป็นขั้นตอนที่คนมักมองข้าม หากไม่มีขั้นตอนนี้ runner จะปิดตัวลงพร้อมกับ session SSH ของคุณ และงานถัดไปทั้งหมดจะค้างอยู่ในคิวโดยไม่มีคำอธิบาย การตั้งค่า self-hosted runner บน VPS ฉบับสมบูรณ์ จะอธิบายขั้นตอนการเพิ่มความปลอดภัยและการทำความสะอาดที่ runner แบบถาวรจำเป็นต้องมี

ผลตอบแทนคือการ deploy ไม่จำเป็นต้องใช้ SSH key ขาเข้าที่เข้าถึงได้จากอินเทอร์เน็ตอีกต่อไป เพราะงานกำลังรันอยู่บนเครื่องนั้นอยู่แล้ว นอกจากนี้ build cache ยังคงอยู่ระหว่างการรันแต่ละครั้ง และไม่มีการนับนาทีการใช้งาน

มีคำเตือนหนึ่งข้อที่ไม่ควรละเลย เอกสารของ GitHub แนะนำให้ใช้ self-hosted runner สำหรับ private repository เท่านั้น เนื่องจาก fork ของ public repository สามารถรันโค้ดที่เป็นอันตรายบน runner ของคุณได้โดยการเปิด pull request ตัว runner จะดำเนินการตามสิ่งที่ไฟล์ workflow ใน branch นั้นระบุไว้ ใน private repo ที่คุณควบคุมได้ว่าใครสามารถ push ได้ ความเสี่ยงจะมีน้อย แต่สำหรับ public repo ให้ถือว่า self-hosted runner ทุกตัวเป็นเครื่องที่คนแปลกหน้าสามารถรันโค้ดได้

คุณจำเป็นต้องใช้ GitHub จริงหรือไม่?

ไม่จำเป็น Git เป็นมาตรฐาน ส่วน GitHub เป็นเพียงความสะดวกสบาย Forgejo และ Gitea เป็นแพลตฟอร์ม Git แบบ self-hosted ซึ่งทำหน้าที่เป็น Git host ที่มาพร้อมกับระบบจัดการ issues และ pull requests ทั้งสองตัวถูกจัดส่งในรูปแบบไฟล์ Go binary เพียงไฟล์เดียวและทำงานบน VPS ขนาดเล็กได้ โดย Forgejo เป็น fork ของ Gitea ที่เกิดขึ้นในปี 2022 และปัจจุบันเป็นเบื้องหลังการทำงานของ Codeberg การย้าย repository สามารถทำได้ด้วยคำสั่งเดียวเนื่องจากใช้ wire protocol เดียวกัน

git remote -v
git remote set-url origin git@git.example.com:you/vps-deploy.git
git push origin main

ทุก commit จะถูกย้ายไปด้วยเพราะทุก clone มีประวัติการทำงานทั้งหมดอยู่แล้ว สิ่งที่จะไม่ถูกย้ายไปด้วยคือเลเยอร์ที่ GitHub สร้างขึ้นมาเสริม เช่น กระทู้ของ issues และ pull requests รวมถึง CI ก็ไม่สามารถย้ายข้ามไปได้เช่นกัน Forgejo มีการใช้งาน Actions ของตนเองที่อ่านไฟล์ YAML ที่คล้ายคลึงกันจาก .forgejo/workflows/ และเอกสารประกอบได้ระบุไว้อย่างชัดเจนเกี่ยวกับข้อจำกัด โดยระบุว่า GitHub Actions และ Forgejo Actions ไม่เหมือนกันและอาจไม่สามารถทำงานได้ทันที นอกจากนี้ยังจำเป็นต้องมี runner ของตนเองด้วย ดังนั้นควรวางแผนขั้นตอนนี้เป็นการย้ายระบบ (port) ไม่ใช่การคัดลอก (copy)

เหตุผลที่แท้จริงที่โปรเจกต์ส่วนใหญ่ยังคงอยู่บน GitHub คือผู้ร่วมพัฒนา (contributors) โค้ดที่เป็นสาธารณะจำเป็นต้องอยู่ในที่ที่ผู้คนมีบัญชีใช้งานอยู่แล้ว แต่สคริปต์การ deploy ส่วนตัวของคุณไม่จำเป็นต้องอยู่ที่นั่น ทั้งสองกรณีเป็นการตัดสินใจที่แยกจากกัน และคุณสามารถเลือกคำตอบที่แตกต่างกันสำหรับแต่ละกรณีได้

สิ่งที่มักจะเกิดปัญหาขึ้นก่อนและข้อความแจ้งเตือนที่ปรากฏ

การ push ถูกปฏิเสธ คุณจะเห็นข้อความดังนี้:

 ! [rejected]        main -> main (fetch first)
error: failed to push some refs to 'github.com:yourname/vps-deploy.git'
hint: Updates were rejected because the remote contains work that you do
hint: not have locally.

มีการ push ข้อมูลเข้ามาหลังจากที่คุณ pull ครั้งล่าสุด ซึ่งมักเกิดจากการแก้ไขผ่าน web editor ให้รันคำสั่ง git pull --rebase เพื่อนำ commit ของคุณไปต่อท้าย commit เหล่านั้น แล้วจึง push อีกครั้ง หลีกเลี่ยงการใช้ git push --force บน branch ที่ใช้งานร่วมกับผู้อื่น เพราะคำสั่งนี้จะลบ commit ของคนอื่นออกจาก branch นั้นบนเซิร์ฟเวอร์

fatal: refusing to merge unrelated histories คุณรันคำสั่ง git init ในเครื่อง และ ปล่อยให้ GitHub สร้าง repository พร้อมไฟล์ README ประวัติทั้งสองส่วนไม่มี commit ใดที่ตรงกัน Git จึงไม่สามารถคาดเดาการรวมข้อมูลได้ วิธีแก้ไขที่สะอาดที่สุดคือการ clone สำเนาจาก GitHub ลงในโฟลเดอร์ใหม่ แล้วย้ายไฟล์ของคุณเข้าไปแทนที่

error: src refspec main does not match any branch ที่คุณระบุไม่มีอยู่จริง โดยปกติแล้ว repository อาจจะยังไม่มี commit ใดๆ หรือ branch ของคุณอาจมีชื่อว่า master การใช้คำสั่ง git branch --show-current จะช่วยแก้ไขปัญหานี้ได้

ข้อมูลลับหลุดเข้าไปใน commit ให้ทำการเปลี่ยน credential ทันที ให้ถือว่าข้อมูลนั้นเป็นสาธารณะตั้งแต่วินาทีที่ถูก push เนื่องจาก fork, mirror และแคชต่างๆ ได้เก็บสำเนาที่คุณไม่สามารถลบออกได้แล้ว

FAQ

GitHub เหมือนกับ Git หรือไม่?

ไม่เหมือนกัน Git เป็นโปรแกรมควบคุมเวอร์ชันที่คุณติดตั้งลงบนเครื่อง ซึ่งทำงานได้โดยไม่ต้องใช้เครือข่ายและไม่ต้องมีบัญชีผู้ใช้ ส่วน GitHub เป็นบริการโฮสต์เชิงพาณิชย์ที่จัดเก็บ Git repository และเพิ่มอินเทอร์เฟซบนเว็บ, ระบบจัดการปัญหา (issues), pull requests และ CI เข้าไป Git ถูกปล่อยออกมาในปี 2005 และ GitHub เปิดตัวในปี 2008 โดยสร้างขึ้นบนพื้นฐานของ Git คุณสามารถใช้งาน Git ได้ตลอดไปโดยไม่ต้องพึ่งพา GitHub แต่ฟีเจอร์ทุกอย่างของ GitHub จำเป็นต้องอาศัย Git ในการทำงานเบื้องหลัง

ฉันจำเป็นต้องมีบัญชี GitHub เพื่อใช้ Git บน VPS หรือไม่?

ไม่จำเป็น git init, git commit และ git log สามารถทำงานบนเซิร์ฟเวอร์ได้โดยไม่ต้องตั้งค่า remote ใดๆ ซึ่งเพียงพอสำหรับการติดตามการเปลี่ยนแปลงของไฟล์ /etc หรือการปรับใช้สคริปต์ บัญชีผู้ใช้จะมีประโยชน์เมื่อคุณต้องการสำรองประวัติการทำงานไว้นอกเซิร์ฟเวอร์ หรือต้องการเครื่องที่สองเพื่อ clone ข้อมูลไปใช้งาน บริการโฮสต์ Git แบบ self-hosted เช่น Forgejo และ Gitea สามารถตอบโจทย์นี้ได้บนฮาร์ดแวร์ของคุณเอง หรือการใช้ SSH remote แบบธรรมดาที่ชี้ไปยัง bare repository บนเครื่องอื่นก็สามารถทำได้โดยไม่ต้องใช้ซอฟต์แวร์จัดการ repository ใดๆ เลย

pull request คืออะไร?

pull request คือคำขอเพื่อรวม branch หนึ่งเข้ากับอีก branch หนึ่ง โดยมีหน้าสำหรับอภิปรายแนบมาด้วย คุณทำการ push branch ขึ้นไป แล้วเปิด PR ไปยัง main จากนั้นโฮสต์จะแสดงการเปลี่ยนแปลงทีละ commit เพื่อให้ผู้ตรวจสอบสามารถแสดงความคิดเห็นในแต่ละบรรทัด และระบบตรวจสอบอัตโนมัติสามารถรายงานผลผ่านหรือล้มเหลวได้ นี่เป็นฟีเจอร์ของ GitHub ไม่ใช่ฟีเจอร์ของ Git ดังนั้นตัว Git เองจึงไม่มีคำสั่งสำหรับทำสิ่งนี้ โฮสต์อื่นก็นำแนวคิดเดียวกันนี้ไปใช้ โดยบางครั้งอาจเรียกว่า merge request

ฉันควรติดตั้ง GitHub Actions runner บน VPS ของตัวเองหรือไม่?

สำหรับ repository ส่วนตัว มักจะควรทำ งานจะรันบนฮาร์ดแวร์ที่คุณจ่ายเงินค่าเช่าอยู่แล้ว ไม่มีการจำกัดเวลาใช้งาน build cache ยังคงอยู่ และการ deploy ไม่จำเป็นต้องเปิดเผย SSH key ขาเข้าสู่อินเทอร์เน็ตอีกต่อไป เพราะ runner จะเชื่อมต่อขาออกไปยัง GitHub เพื่อรับงานเอง สำหรับ repository สาธารณะ GitHub แนะนำว่าไม่ควรทำ เพราะใครก็ตามสามารถ fork repository ของคุณและเปิด pull request ที่มี workflow ซึ่งรันโค้ดบนเครื่องของคุณได้

ฉันสามารถย้าย repository ออกจาก GitHub ในภายหลังได้หรือไม่?

ในส่วนของโค้ดนั้นทำได้ง่ายมาก เพราะทุก clone จะเก็บประวัติการทำงานทั้งหมดไว้ ดังนั้นการใช้ git remote set-url origin <new url> ตามด้วยการ push จะเป็นการย้ายทุกอย่างที่อยู่ใน commit ไปด้วย สิ่งที่จะยังคงค้างอยู่คือส่วนที่ GitHub เป็นเจ้าของ ได้แก่ issues, การอภิปรายใน pull request และประวัติของ Actions ซึ่งอยู่ในฐานข้อมูลของ GitHub ไม่ได้อยู่ในโฟลเดอร์ .git ของคุณ เครื่องมือย้ายข้อมูลสามารถคัดลอก issues ผ่าน API ได้ ส่วนไฟล์ workflow มักจะต้องมีการแก้ไขเพื่อให้เข้ากับระบบ CI ของโฮสต์ใหม่ การตระหนักถึงข้อนี้เป็นเหตุผลสำคัญที่ควรเก็บเอกสารสำคัญไว้ใน repository แทนที่จะเก็บไว้ในกระทู้ของระบบ issue