จากมือใหม่สู่มือโปร GitHub: คู่มือฉบับสมบูรณ์

หากคุณต้องการสร้างรายได้จาก GitHub เส้นทางที่ตรงไปตรงมาที่สุดก็ไม่ซับซ้อน: ภายใต้เงื่อนไขที่ได้รับอนุญาตจากใบอนุญาต ให้ค้นหาโปรเจกต์โอเพนซอร์สที่มีคุณค่า นำการปรับใช้ การทำเอกสารภาษาจีน และการบริการหลังการขายมารวมกันเป็นบริการเดียว แล้วขายการส่งมอบบนแพลตฟอร์มอย่าง Xianyu

อย่างไรก็ตาม สิ่งที่สร้างรายได้จริงๆ คือความสามารถในการกรองข้อมูลและความสามารถในการนำไปปฏิบัติ หากคุณต้องการทำ AI ย้ายไปเป็น FDE (Full-stack Development Engineer) หรือเปลี่ยนตัวเองเป็น OPC (One Person Company) โค้ด เอกสาร เวอร์ชัน และการทำงานร่วมกันจะต้องมาลงเอยที่ GitHub ในที่สุด

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

ผมใช้เวลากว่าครึ่งเดือนในการขัดเกลาบทความนี้ ฝึกฝน Git, GitHub, Commits, Branches, PRs และข้อผิดพลาดทั่วไปตั้งแต่ 0 ถึง 1 การถ่ายทอดสดในอนาคตก็จะดำเนินตามกระบวนการเดียวกันนี้ ก่อนการออกอากาศอย่างเป็นทางการ ผมจะเปิดเผยบทช่วยสอนนี้เป็นสาธารณะก่อน คุณสามารถบุ๊กมาร์กไว้หรือทำตามไปทีละขั้นตอนก็ได้

1. Git และ GitHub: ใครจัดการอะไร?

Git เป็นเครื่องมือจัดการเวอร์ชันที่ติดตั้งบนคอมพิวเตอร์ของคุณ เมื่อออฟไลน์ คุณยังสามารถ commit, ดูประวัติ, สร้าง branch และ merge ได้ GitHub เป็นพื้นที่เก็บข้อมูลระยะไกลและแพลตฟอร์มการทำงานร่วมกัน มันรับ commits ที่ Git push มา และให้บริการ Issues, Pull Requests, Actions, การตรวจสอบโค้ด และการจัดการสิทธิ์

สิ่งที่สับสนที่สุดใน Git คือการแก้ไขเดียวกันสามารถมีอยู่ได้ในสี่ตำแหน่งที่แตกต่างกัน อินโฟกราฟิกด้านล่างแยกพื้นที่ทำงาน (workspace), staging area, local repository และ remote repository ออกเป็นสี่ชั้น

การกดบันทึก (save) จะเขียนเนื้อหาลงในฮาร์ดไดรฟ์เท่านั้น git add มีหน้าที่เลือก git commit ทิ้งเวอร์ชันไว้ในเครื่อง และ git push ส่ง commits เหล่านี้ไปยัง GitHub

ดังนั้น ก่อนที่จะ commit ให้ตรวจสอบ diff, รันมัน หรือทดสอบมัน หลังจาก push สำเร็จ ให้กลับไปที่หน้าเว็บเพื่อตรวจสอบอีกครั้ง วิธีนี้ หากเกิดปัญหา คุณจะรู้ได้ทันทีว่ามันหยุดอยู่ที่ชั้นไหน

2. ก่อนเริ่ม: เตรียมแค่สี่สิ่งเท่านั้น

คุณต้องมี Git, บัญชี GitHub, โปรแกรมแก้ไข และโปรเจกต์สำหรับฝึกฝน VS Code ก็เพียงพอสำหรับโปรแกรมแก้ไข และโปรเจกต์อาจเป็นหน้าเว็บหรือเอกสาร Markdown

ขั้นแรก ยืนยัน Git ในเทอร์มินัล:

1git --version

แบบฝึกหัดนี้ใช้ macOS และ Git 2.49.0 ผู้ใช้ Windows สามารถใช้ Git Bash หรือเทอร์มินัลในตัวของ VS Code คำสั่ง Git ด้านล่างนี้เหมือนกัน

จากนั้น กำหนดค่าผู้เขียน commit:

1git config --global user.name "Your Name"
2git config --global user.email "Your Email"

นี่คือข้อมูลผู้เขียนที่เขียนลงในบันทึก commit มันไม่รับผิดชอบในการเข้าสู่ระบบ GitHub หากคุณต้องการกำหนดค่าเฉพาะสำหรับโปรเจกต์ฝึกฝนปัจจุบัน ให้แทนที่ --global ด้วย --local

การเข้าสู่ระบบ GitHub เป็นอีกเรื่องหนึ่ง โดยทั่วไปบรรทัดคำสั่งใช้สามวิธี:

• GitHub CLI, อนุญาตผ่านเบราว์เซอร์ด้วย gh auth login;
• HTTPS, ใช้ Personal Access Token หรือ credential manager;
• SSH, เพิ่มคีย์สาธารณะไปยัง GitHub และตรวจสอบสิทธิ์ผ่านคีย์ในภายหลัง

ผู้เริ่มต้นสามารถเลือก GitHub CLI หรือ HTTPS เมื่อใช้ HTTPS หากเทอร์มินัลถามหารหัสผ่าน ให้กรอก Token รหัสผ่านบัญชีธรรมดาใช้ไม่ได้อีกต่อไป อย่าเขียน Token ลงในคำสั่ง, URL ระยะไกล, README, แชท หรือภาพหน้าจอ

3. อย่ารีบ init: ยืนยันว่าเทอร์มินัลอยู่ที่ไหนจริงๆ

แบบฝึกหัดนี้เริ่มต้นด้วยหน้าเว็บธรรมดา มันสามารถเปิดในเบราว์เซอร์ได้ แต่ยังไม่มีประวัติ Git

มีสามไฟล์ในโปรเจกต์:

1index.html
2style.css
3.gitignore

ใน VS Code ให้เลือก "Open Folder" อย่าแค่คลิกที่ไฟล์ HTML ไฟล์เดียว จากนั้นรันในเทอร์มินัลในตัว:

1pwd
2ls

pwd แสดงไดเรกทอรีปัจจุบัน และ ls แสดงรายการไฟล์ ให้ดำเนินการต่อเมื่อเห็น index.html และ style.css เท่านั้น

การตรวจสอบนี้ดูเหมือนไร้สาระ แต่ป้องกันอุบัติเหตุที่สร้างปัญหามากที่สุด: มีคนรัน git init บน Desktop, Documents หรือแม้แต่โฮมไดเรกทอรีของผู้ใช้ แล้ว git add . ทำให้ไฟล์ที่ไม่เกี่ยวข้องหลายพันไฟล์เข้าไปใน staging area Git ไม่ได้เสียหาย แต่ไดเรกทอรีผิด

4. git init ทำอะไร?

ตอนนี้เริ่มต้นพื้นที่เก็บข้อมูล:

1git init -b main
2git status --short

git init -b main สร้างไดเรกทอรี .git ในโฟลเดอร์ปัจจุบันและตั้งชื่อ branch เริ่มต้นเป็น main .git เป็นไดเรกทอรีที่ซ่อนอยู่ซึ่งเก็บข้อมูลเช่น commits, branches, staging area และที่อยู่ระยะไกล ไฟล์โปรเจกต์ยังคงอยู่ที่เดิม Git เริ่มสังเกตการณ์พวกมันจากช่วงเวลานี้

?? ในภาพหน้าจอบ่งชี้ไฟล์ที่ไม่ได้ติดตาม (untracked files) ไฟล์มีอยู่ แต่ Git ยังไม่ได้ตัดสินใจว่าจะบันทึกมันหรือไม่

เพื่อยืนยันไดเรกทอรีรากของพื้นที่เก็บข้อมูล คุณสามารถรัน:

1git rev-parse --show-toplevel

ผลลัพธ์ควรเป็นโฟลเดอร์โปรเจกต์ปัจจุบัน หากมันบอกว่า fatal: not a git repository ให้ตรวจสอบไดเรกทอรีก่อน แล้วดูว่าได้รัน git init หรือไม่

5. Commit ครั้งแรก: รักษาจุดเริ่มต้นที่เชื่อถือได้

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

จากนั้นดูที่ .gitignore เนื้อหาที่ใช้ในครั้งนี้คือ:

1.env
2.env.*
3*.log
4node_modules/
5dist/
6build/

.gitignore ใช้เพื่อบล็อกคีย์, ไฟล์บันทึก, dependencies และ build artifacts มันทำงานหลักกับไฟล์ที่ยังไม่ได้ติดตาม หากคีย์ถูก commit ไปแล้ว และคุณเพิ่มมันลงใน .gitignore ในภายหลัง ประวัติศาสตร์นั้นยังคงอยู่ การจัดการที่แท้จริงยังรวมถึงการเพิกถอนหรือหมุนเวียนคีย์ด้วย

เริ่มเลือกไฟล์สำหรับ commit ครั้งแรก:

1git add index.html style.css .gitignore
2git status --short
3git diff --cached --stat

A ในสถานะหมายถึง Added (เพิ่มแล้ว) บ่งชี้ว่าไฟล์เข้าสู่ staging area แล้ว git diff --cached --stat จะบอกคุณว่าคุณกำลังเตรียม commit กี่ไฟล์และมีการเปลี่ยนแปลงกี่บรรทัดโดยประมาณ หากต้องการดูเนื้อหาเฉพาะ ให้รัน:

1git diff --cached

Commit หลังจากยืนยัน:

1git commit -m "chore: Initialize campus AI recruitment page"
2git log --oneline
3git status

Commit สามารถเข้าใจได้ว่าเป็นภาพรวมของโปรเจกต์ (snapshot) พร้อมด้วยผู้เขียน เวลา คำอธิบาย และ parent commit ffdf4ff คือรุ่นสั้นของ hash ของ commit นี้ การใช้มันในพื้นที่เก็บข้อมูลปัจจุบันสามารถระบุเวอร์ชันได้อย่างแม่นยำ

feat, fix, docs, style, chore เป็นประเภท commit ทั่วไป ไม่ใช่ไวยากรณ์บังคับของ Git สิ่งสำคัญกว่าคำนำหน้าคือคำอธิบายภาษาไทย (หรืออังกฤษ) ที่ตามมา: ทำอะไรไป, วัตถุใดถูกแก้ไข, และเพราะเหตุใด

6. Commit ครั้งที่สอง: ปฏิบัติต่อการแก้ไขของ AI เหมือนร่างสำหรับตรวจสอบ

ขั้นตอนต่อไป เพิ่มปุ่ม "ดูวิธีการสมัคร" ลงในหน้า เมื่อใช้เครื่องมือเขียนโปรแกรม AI ผมจะเขียนขอบเขตลงใน prompt:

1แก้ไขเฉพาะ index.html เพิ่มลิงก์ "ดูวิธีการสมัคร" ใต้ข้อความแนะนำ
2ลิงก์ไปยัง #apply ภายในหน้า ห้ามแก้ไข style.css ห้ามรัน Git commits
3บอกฉันว่าไฟล์ใดถูกแก้ไขเมื่อเสร็จสิ้น

การแก้ไขด้วยตนเองก็ง่ายเช่นกัน:

1<a class="cta" href="#apply">ดูวิธีการสมัคร</a>

AI บอกว่าเสร็จแล้ว แต่อย่าเพิ่ง commit รัน:

1git status --short
2git diff -- index.html
3git diff --check

git diff แสดงการเปลี่ยนแปลงในพื้นที่ทำงานที่ยังไม่ได้ staged + สีเขียวคือบรรทัดที่เพิ่ม - สีแดงคือบรรทัดที่ถูกลบ git diff --check ไม่มีเอาต์พุต แสดงว่าไม่พบปัญหาการจัดรูปแบบที่ชัดเจน เช่น ช่องว่างต่อท้าย มันจะไม่ตรวจสอบให้คุณว่าปุ่มคลิกได้หรือไม่

กลับไปที่เบราว์เซอร์แล้วรีเฟรช คลิกปุ่ม จากนั้นย่อหน้าต่าง หน้าควรเลื่อนไปยังพื้นที่ลงทะเบียน และปุ่มและการ์ดควรยังคงปกติบนหน้าจอแคบ

Commit หลังจากทดสอบผ่านแล้วเท่านั้น:

1git add index.html
2git diff --cached
3git commit -m "feat: Add registration entry for quick viewing of application methods"
4git log --oneline -2

ณ จุดนี้ มีสองเวอร์ชันที่ชัดเจนในพื้นที่เก็บข้อมูล: หน้าเริ่มต้นและปุ่มลงทะเบียน หากปุ่มมีปัญหาในภายหลัง คุณสามารถค้นหาได้โดยตรงว่า commit ไหนเป็นคนเพิ่มมัน

อีกอย่าง แยกแยะ diff สองแบบ:

1git diff             # ความแตกต่างระหว่างพื้นที่ทำงานและ staging area
2git diff --cached    # ความแตกต่างระหว่าง staging area และ commit ล่าสุด

หาก git diff ไม่มีเอาต์พุต ไฟล์อาจจะไม่ได้บันทึก หรืออาจถูก staged หรือ commit ไปแล้ว การตรวจสอบ git status, git diff --cached และ git log ตามลำดับนั้นเชื่อถือได้มากกว่าการพิมพ์ git add . ซ้ำๆ

7. Branches: เว้นจุดทดสอบสำหรับการเปลี่ยนแปลงที่ไม่แน่นอน

ปุ่มเพิ่มเพียงบรรทัดเดียว ดังนั้นความเสี่ยงจึงน้อย การเปลี่ยนธีมทั้งหมดจากสีม่วงเป็นสีส้มอาจดูดีหรืออาจดูเชย การแก้ไขแบบนี้เหมาะสำหรับการทำ branch

1git switch -c experiment/warm-theme
2git branch --show-current

Branch ในทางแนวคิดคือชื่อที่ชี้ไปยัง commit หนึ่งๆ เมื่อสร้าง branch ใหม่ครั้งแรก มันจะชี้ไปยัง commit เดียวกับ main ดังนั้นไฟล์จึงเหมือนกันทุกประการ เฉพาะเมื่อ branch ทดลองสร้าง commits ใหม่ เส้นทั้งสองจึงจะแยกออกจากกัน

ในแผนภาพ main สีน้ำเงินยังคงชี้ไปยัง commit ที่สอง ในขณะที่ experiment สีส้มชี้ไปยัง commit ที่สามแล้ว โปรเจกต์ไม่ได้ทำการคัดลอกไฟล์สองชุด มีเพียงพอยน์เตอร์ของชื่อ branch ทั้งสองเท่านั้นที่เปลี่ยนไป

แก้ไขตัวแปรสีใน style.css, รีเฟรชหน้าเพื่อยืนยัน แล้ว commit:

1git diff -- style.css
2git diff --check
3git add style.css
4git commit -m "style: Try warm theme in experimental branch"
5git log --oneline --graph --decorate --all

HEAD บ่งชี้ว่าคุณกำลังยืนอยู่ตรงไหน ในภาพหน้าจอ HEAD ชี้ไปที่ experiment/warm-theme ในขณะที่ main ยังคงอยู่ที่ commit ของปุ่ม

ตัดสินใจเก็บธีมอุ่นไว้ สลับกลับไปที่ main และ merge:

1git switch main
2git merge experiment/warm-theme

Fast-forward เกิดขึ้นที่นี่เพราะ main ไม่มี commits ใหม่ในระหว่างการทดลอง Git จะเลื่อนพอยน์เตอร์ main ไปข้างหน้าสู่ commit ธีมอุ่นโดยตรง การเปลี่ยนแปลงได้ถูกผสานสำเร็จแล้ว

Branch ที่ merge แล้วสามารถลบได้อย่างปลอดภัย:

1git branch -d experiment/warm-theme

-d ตัวพิมพ์เล็กจะตรวจสอบว่า branch ถูก merge แล้วหรือไม่ -D ตัวพิมพ์ใหญ่จะบังคับลบ และ commits ใน branch ที่ยังไม่ได้ merge อาจสูญเสียการอ้างอิง อย่าใช้มันเป็นคำสั่งทำความสะอาดประจำวัน

8. Conflicts ไม่ใช่เรื่องลึกลับ Git แค่ไม่กล้าเลือกให้คุณ

เพื่อตรวจสอบ conflicts ผมได้ทำการคัดลอกพื้นที่เก็บข้อมูล main เปลี่ยนชื่อเรื่องหลักเป็น "ให้ความคิดสร้างสรรค์ในมหาวิทยาลัยเป็นที่เห็นของผู้คนมากขึ้น" และ branch feature เปลี่ยนบรรทัดเดียวกันเป็น "เปลี่ยนความคิดให้เป็นผลงานที่ใช้งานได้จริง" Git หยุดระหว่างการ merge:

เครื่องหมาย conflict แบ่งออกเป็นสามส่วน:

1<<<<<<< HEAD
2เนื้อหาของ branch ปัจจุบัน
3=======
4เนื้อหาของ branch ที่จะ merge เข้ามา
5>>>>>>> feature/rewrite-heading

วิธีการจัดการคือแก้ไขไฟล์ ทิ้งข้อความสุดท้ายที่ต้องการ ลบเครื่องหมายทั้งสามชุด ทดสอบมัน แล้วรัน:

1git add index.html
2git commit

หากคุณไม่ต้องการจัดการในเวลานั้น คุณสามารถยกเลิกการ merge:

1git merge --abort

Conflict หมายถึงคนสองคนหรือ Agent สองคนให้คำตอบที่แตกต่างกันสำหรับตำแหน่งเดียวกัน และ Git ไม่สามารถเลือกได้เอง

9. ส่ง Local Repository ไปยัง GitHub

โปรเจกต์มีประวัติในเครื่องแล้ว ตอนนี้ไปที่ GitHub เพื่อสร้างพื้นที่เก็บข้อมูล คลิก + ที่มุมขวาบน เลือก "New repository" และกรอกชื่อพื้นที่เก็บข้อมูล เช่น:

1campus-ai-demo

สำหรับการฝึกครั้งแรก แนะนำให้ตั้งเป็น Private เนื่องจากในเครื่องมี README, .gitignore และประวัติ commit อยู่แล้ว ให้เก็บพื้นที่เก็บข้อมูล GitHub ใหม่ให้ว่างเปล่า อย่าเริ่มต้น README, license หรือ .gitignore ทางฝั่งเว็บ มิฉะนั้น ในเครื่องและระยะไกลจะมีประวัติเริ่มต้นคนละชิ้น และการ push ครั้งแรกจะต้องจัดการความสัมพันธ์ระหว่างทั้งสองฝ่ายก่อน เอกสารทางการของ GitHub เรื่อง "Adding locally hosted code" ก็เตือนอย่างชัดเจนเช่นกัน

คัดลอกที่อยู่ HTTPS:

1https://github.com/YourUsername/campus-ai-demo.git

กลับไปที่เทอร์มินัลของโปรเจกต์:

1git remote add origin https://github.com/YourUsername/campus-ai-demo.git
2git remote -v
3git push -u origin main

origin เป็นนามแฝงสำหรับที่อยู่ระยะไกล มันสามารถทำงานกับชื่ออื่นได้ แต่ชุมชนมักจะเรียก remote หลักว่า origin -u จะสร้างความสัมพันธ์การติดตาม (tracking relationship) ระหว่าง main ในเครื่องและ origin/main การดำเนินการในภายหลังมักจะแค่รัน git push

แผนภาพเทอร์มินัลด้านล่างใช้ local bare repository เพื่อรัน push และ clone ดังนั้นจึงไม่ได้เปลี่ยนบัญชี GitHub ที่มีอยู่ เมื่อสลับไปใช้ GitHub เพียงแค่เปลี่ยน origin URL ตรรกะสำหรับ Git ในการส่ง commits และสร้างความสัมพันธ์การติดตามก็เหมือนกัน

หลังจาก push จริงเสร็จสิ้น ให้กลับไปที่หน้าเว็บ GitHub และรีเฟรชเพื่อยืนยันว่าไฟล์, README, default branch และประวัติ commit ทั้งหมดมองเห็นได้ ข้อความสำเร็จในเทอร์มินัลเป็นหลักฐานชั้นหนึ่ง และการตรวจสอบทางเว็บเป็นอีกชั้นหนึ่ง

10. อ่าน GitHub Repository เป็นครั้งแรก: อ่านสิ่งเหล่านี้บนหน้าได้อย่างไร

ด้านล่างคือหน้าจริงของพื้นที่เก็บข้อมูลเอกสารทางการของ GitHub ซึ่งถ่ายภาพหน้าจอเมื่อวันที่ 15 สิงหาคม 2026

เมื่อเปิดพื้นที่เก็บข้อมูล ให้ดูที่ตำแหน่งเหล่านี้ก่อน:

• Code: ไฟล์, ไดเรกทอรี, branches และ commits;
• Issues: บั๊ก, ข้อกำหนด, งาน และการสนทนา;
• Pull requests: การเปลี่ยนแปลงที่รอการตรวจสอบหรือ merge;
• Actions: การทดสอบอัตโนมัติ, การสร้าง และการปรับใช้;
• Security: นโยบายความปลอดภัยและฟังก์ชันที่เกี่ยวข้องกับช่องโหว่;
• Insights: การมีส่วนร่วม, ปริมาณการใช้งาน และกิจกรรมของพื้นที่เก็บข้อมูล;
• README: บทนำโปรเจกต์และจุดเริ่มต้นการใช้งาน;
• LICENSE: อนุญาตให้ใช้, แก้ไข และแจกจ่ายอย่างไร

เมื่ออ่านโปรเจกต์ที่ไม่คุ้นเคย อย่าจ้องที่ Stars ก่อน ตอบคำถามห้าข้อก่อน: มันแก้ปัญหาอะไร, มันทำงานอย่างไร, มันขึ้นอยู่กับอะไร, มันได้รับการบำรุงรักษาล่าสุดหรือไม่, และใบอนุญาตอนุญาตให้ฉันทำอะไรได้บ้าง Stars สะท้อนถึงความสนใจ มันไม่ได้ตรวจสอบความปลอดภัย ความเข้ากันได้ หรือการอนุญาตให้คุณ

11. clone, fetch, pull, push: อย่าสับสนสี่ทิศทาง

การนำพื้นที่เก็บข้อมูลระยะไกลมาที่เครื่องของคุณเป็นครั้งแรก:

1git clone https://github.com/OWNER/REPO.git

Clone จะนำไฟล์, ประวัติ commit และการกำหนดค่าระยะไกลกลับมา โดยปกติจะตั้งชื่อ remote ว่า origin โดยอัตโนมัติ การดาวน์โหลด ZIP จะให้เฉพาะภาพรวมของไฟล์ในเวลานั้น โดยไม่มีประวัติทั้งหมด และจะไม่สร้างความสัมพันธ์ระยะไกล

สามการดำเนินการที่ใช้บ่อยหลังจากนั้นคือ:

1git fetch origin   # ดาวน์โหลดข้อมูลระยะไกล ไม่เปลี่ยนไฟล์ทำงานปัจจุบัน
2git pull           # fetch แล้วรวมเข้ากับ branch ปัจจุบัน
3git push           # ส่ง commits ในเครื่องไปยังระยะไกล

หากต้องการดูก่อนว่าเกิดอะไรขึ้นในระยะไกล คุณสามารถ:

1git fetch origin
2git status -sb
3git log --oneline HEAD..origin/main

เมื่อยืนยันว่าไม่มีความแตกต่างในเครื่องและต้องการรับเฉพาะการอัปเดตแบบ fast-forward:

1git pull --ff-only

pull จะ fetch ก่อน จากนั้นจึงดำเนินการ merge หรือ rebase ตามการกำหนดค่า ทีมควรตกลงวิธีการรวมก่อนการทำงานร่วมกันครั้งแรก และอย่าพึ่งพา force push เพื่อแก้ปัญหาเมื่อเกิดความแตกต่าง

12. จาก Personal Repository สู่การทำงานร่วมกันบน GitHub

Pull Request คือข้อเสนอการ merge และเป็นที่ที่การทำงานร่วมกันเกิดขึ้น การสนทนา, การตรวจสอบโค้ด และการตรวจสอบอัตโนมัติทั้งหมดเกี่ยวข้องกับการเปลี่ยนแปลงชุดเดียวกัน และมันจะถูก merge เข้าสู่ main หลังจากยืนยันแล้วเท่านั้น

สมมติว่า Issue คือ "เพิ่มคำอธิบายเวลากิจกรรม" การดำเนินการในเครื่องสามารถทำได้ดังนี้:

1git switch -c feat/event-time
2# แก้ไขและทดสอบหน้า
3git add index.html
4git commit -m "feat: Add event time description"
5git push -u origin feat/event-time

หลังจาก push โดยปกติ GitHub จะแจ้งให้สร้าง Pull Request PR คือข้อเสนอการ merge ที่แสดงคำอธิบาย, commits, ความแตกต่างของไฟล์, ความคิดเห็น, บทวิจารณ์ และการตรวจสอบอัตโนมัติ มันจะไม่เข้าสู่ main โดยอัตโนมัติเพียงเพราะถูกสร้างขึ้น

PR ที่ผู้คนยินดีตรวจสอบควรอธิบายอย่างน้อยสามสิ่ง: มีการเปลี่ยนแปลงอะไร, ทำไมจึงเปลี่ยน, และจะตรวจสอบได้อย่างไร ยิ่งการเปลี่ยนแปลงมีความเฉพาะเจาะจงมากเท่าไร ผู้ตรวจสอบก็จะยิ่งพบปัญหาได้ง่ายขึ้นเท่านั้น

ในทีมเดียวกัน หากคุณมีสิทธิ์เขียนในพื้นที่เก็บข้อมูล คุณสามารถส่ง PR ได้โดยตรงจาก branch เมื่อมีส่วนร่วมในโปรเจกต์โอเพนซอร์สที่ไม่คุ้นเคย แนวทางปฏิบัติทั่วไปคือ Fork มันไปยังบัญชีของคุณก่อน แล้วจึง clone Fork ของคุณเอง:

1git clone https://github.com/YourUsername/ProjectName.git
2cd ProjectName
3git remote add upstream https://github.com/OriginalAuthor/ProjectName.git
4git remote -v

โดยปกติจะมีสอง remotes ที่นี่:

1origin    Fork ของคุณเอง
2upstream  พื้นที่เก็บข้อมูลของผู้เขียนต้นฉบับ

ซิงค์โปรเจกต์ต้นฉบับ:

1git fetch upstream
2git switch main
3git merge --ff-only upstream/main
4git push origin main

จากนั้นทำการแก้ไขใน branch ใหม่, push ไปยัง Fork ของคุณเอง, แล้วส่ง PR ไปยัง upstream Fork, clone และ branch แก้ไขสามสิ่งที่แตกต่างกัน: Fork คือชุดพื้นที่เก็บข้อมูลบน GitHub, clone นำพื้นที่เก็บข้อมูลมาที่เครื่อง, และ branch คือสายการพัฒนาภายในพื้นที่เก็บข้อมูล

13. README และ LICENSE กำหนดว่าคนอื่นจะกล้าใช้มันหรือไม่

README ควรตอบคำถามเหล่านี้อย่างน้อย:

1. โปรเจกต์คืออะไร;
2. มันแก้ปัญหาอะไร;
3. วิธีติดตั้งหรือรันมัน;
4. ปัจจุบันเสร็จสมบูรณ์แค่ไหน;
5. ไฟล์หลักอยู่ที่ไหน;
6. ผู้เขียน, วัสดุ และแหล่งที่มาคือใคร

หากโค้ดสามารถรันได้แต่ README คลุมเครือ คุณอาจจะไม่สามารถหยิบมันขึ้นมาใช้เองได้ในอีกสามเดือนต่อมา README ขั้นต่ำไม่จำเป็นต้องสวยงาม แค่เขียนโปรเจกต์, วิธีการรัน และสถานะให้ชัดเจน

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

MIT, Apache-2.0, GPL ฯลฯ มีภาระผูกพันที่แตกต่างกัน เมื่อพบกับการใช้งานเชิงพาณิชย์ การแจกจ่ายซ้ำ หรือใบอนุญาตแบบผสม ให้อ่านไฟล์ทั้งหมดและปรึกษาผู้เชี่ยวชาญหากจำเป็น อย่าแค่ถาม AI ว่า "ฉันสามารถใช้เพื่อการค้าได้ไหม?"

14. หลังจากทำผิด: พิจารณาว่าการเปลี่ยนแปลงอยู่ในชั้นไหน

ยาถอนพิษควรเลือกตามสถานะ

Staged ไฟล์ผิดแต่ต้องการเก็บเนื้อหาไฟล์ไว้:

1git restore --staged filename

ข้อความ commit ล่าสุดเขียนผิดและยังไม่ได้ push:

1git commit --amend -m "ข้อความ commit ใหม่"

Commit บน branch ที่ใช้ร่วมกันจำเป็นต้องถูกเพิกถอน:

1git revert commit_hash

revert จะสร้าง commit ย้อนกลับใหม่ และประวัติเก่ายังคงมองเห็นได้ ซึ่งเหมาะสำหรับ branch ที่ถูก push แล้วและมีคนหลายคนใช้งาน

git restore filename จะทิ้งการแก้ไขที่ยังไม่ได้ commit; git reset --hard จะทำให้ commits, staging area และพื้นที่ทำงานทั้งหมดกลับไปยังตำแหน่งที่ระบุ; git push --force อาจเขียนทับ commits ระยะไกล การดำเนินการทั้งสามประเภทนี้ต้องการการยืนยันเป้าหมายและการสำรองข้อมูลก่อนดำเนินการ อย่าปฏิบัติต่อมันเหมือนปุ่มซ่อมแซมทั่วไปในช่วงเริ่มต้น

15. ข้อผิดพลาดทั่วไปแปดประการ: ตรวจสอบตามลำดับนี้

1. fatal: not a git repository

1pwd
2ls
3git status

โดยปกติแล้ว ไดเรกทอรีผิด หรือโปรเจกต์ปัจจุบันยังไม่ได้ git init

2. Author identity unknown

1git config --local user.name "Your Name"
2git config --local user.email "Your Email"

3. nothing to commit

ตรวจสอบว่าไฟล์ถูกบันทึกหรือไม่, คุณแก้ไขสำเนาอื่นหรือไม่, และการเปลี่ยนแปลงถูก commit ไปแล้วหรือไม่:

1git status
2git log --oneline -3

4. remote origin already exists

1git remote -v
2git remote set-url origin ที่อยู่GitHubที่ถูกต้อง

5. src refspec main does not match any

พื้นที่เก็บข้อมูลอาจยังไม่มี commit หรือ branch ปัจจุบันไม่ได้ชื่อ main:

1git log --oneline
2git branch --show-current

6. Authentication failed or 403

ตรวจสอบ URL ระยะไกล, ความเป็นเจ้าของพื้นที่เก็บข้อมูล, สิทธิ์ของบัญชี และวิธีการตรวจสอบสิทธิ์ อย่าส่ง Token ให้ผู้อื่นเพื่อแก้ไขปัญหา

7. rejected non-fast-forward

มี commits ในระยะไกลที่ไม่มีในเครื่อง ให้ fetch และดูความแตกต่างก่อน อย่าเพิ่ง force push:

1git fetch origin
2git status -sb
3git log --oneline --graph --decorate --all -10

8. Merge Conflict

รัน git status เพื่อค้นหาไฟล์ UU, กำหนดเนื้อหาสุดท้ายด้วยตนเอง, ทดสอบ, จากนั้น add และ commit; หากยังไม่จัดการในตอนนี้ ให้ใช้ git merge --abort

เมื่อนักเรียนหรือเพื่อนร่วมงานแค่พูดว่า "Git มันพัง" ให้ขอให้พวกเขาส่งข้อมูลห้าอย่างนี้มา:

1pwd
2git status
3git branch --show-current
4git log --oneline -5
5git remote -v

จากนั้นเพิ่มระบบปฏิบัติการ คำสั่งเต็มที่เพิ่งรันไป และข้อความแสดงข้อผิดพลาดเต็มๆ ปัญหาส่วนใหญ่จะตกอยู่ในเลเยอร์ใดเลเยอร์หนึ่งอย่างรวดเร็ว ได้แก่ ไดเรกทอรี สถานะ ตัวตน ที่อยู่รีโมท หรือสิทธิ์การเข้าถึง

16. ในยุค AI, Git เปรียบเสมือนระบบการยอมรับมากกว่า

AI สามารถพิมพ์คำสั่งให้คุณได้ แต่มันไม่สามารถรู้โดยอัตโนมัติว่าการแก้ไขใดตรงกับความต้องการทางธุรกิจ หากพรอมต์เปลี่ยนไฟล์ไป 20 ไฟล์และคุณไม่ดู diff, ไม่รันโปรเจกต์, และไม่ตรวจสอบคีย์ต่างๆ Git ก็จะบันทึกความยุ่งเหยิงนี้ไว้อย่างซื่อสัตย์

วิธีที่เสถียรกว่าคือการจำกัดขอบเขตงานและให้มนุษย์อยู่ในตำแหน่งผู้ยอมรับ หลังจากที่ขอบเขต ความแตกต่าง การทดสอบ และการตรวจสอบคีย์ผ่านทั้งหมดแล้ว มนุษย์จึงตัดสินใจว่าการแก้ไขเหล่านี้สามารถกลายเป็น commit ได้หรือไม่

เมื่อให้ AI จัดการ Git ก็ควรกำหนดขอบเขตด้วย:

1โปรดตรวจสอบ git status และ git diff ก่อน และสรุปเฉพาะการเปลี่ยนแปลงปัจจุบันเท่านั้น
2ห้ามทิ้งเนื้อหาที่ยังไม่ได้ commit, ห้ามรัน reset --hard, clean, หรือ force push
3ให้ผลการตรวจสอบหลังจากทำการแก้ไขเสร็จ ห้าม commit หรือ push โดยอัตโนมัติ

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

17. รันกระบวนการทั้งหมดอีกครั้ง

1# 1. ยืนยันตำแหน่ง
2pwd
3ls
4
5# 2. เริ่มต้น
6git init -b main
7git status
8
9# 3. Commit ครั้งแรก
10git add index.html style.css .gitignore
11git diff --cached
12git commit -m "chore: เริ่มต้นโปรเจกต์"
13
14# 4. แก้ไข, ตรวจสอบ, ทดสอบ, commit อีกครั้ง
15git status --short
16git diff
17git diff --check
18git add index.html
19git commit -m "feat: เพิ่มจุดลงทะเบียน"
20
21# 5. ทดลอง branch
22git switch -c experiment/warm-theme
23git add style.css
24git commit -m "style: ทดลองธีมโทนอุ่น"
25git switch main
26git merge experiment/warm-theme
27
28# 6. เชื่อมต่อกับ GitHub
29git remote add origin https://github.com/YourUsername/RepoName.git
30git remote -v
31git push -u origin main
32
33# 7. ตรวจสอบครั้งสุดท้าย
34git status
35git log --oneline --graph --decorate --all
36git remote -v
37git diff --check
38git ls-files

เมื่อคุณสามารถอธิบายได้ว่าแต่ละคำสั่งเปลี่ยนเลเยอร์ไหน และสามารถจัดการกับไดเรกทอรีที่ผิดพลาด การ staging ที่ผิดพลาด และ merge conflict ได้ด้วยตัวเอง GitHub ก็จะไม่ใช่แค่เว็บไซต์สำหรับเก็บโค้ดอีกต่อไป คุณสามารถเปลี่ยนโปรเจกต์ส่วนตัวให้กลายเป็น repository ที่สามารถตรวจสอบ ตรวจทาน และทำงานร่วมกันได้

ขั้นตอนต่อไปไม่จำเป็นต้องสะสมคำสั่งอีกต่อไป หาโปรเจกต์เล็กๆ จริงๆ สักอันแล้วทำติดต่อกัน 7 วัน: ทำการแก้ไขเล็กๆ น้อยๆ เพียงครั้งเดียวในแต่ละวัน ดู diff, ทดสอบ, commit, แล้ว push ไปยัง GitHub ประวัติ commit จะค่อยๆ เปลี่ยนสิ่งเหล่านี้ให้เป็นนิสัยการทำงานของคุณ

ผม Miles ผู้เชี่ยวชาญด้านอัลกอริทึม AI ที่เปลี่ยนจากบริษัทใหญ่มาสู่ FDE เคยทำงานด้าน R&D อัลกอริทึม, การปรับใช้เพื่อประสิทธิภาพ, และการฝึกอบรมองค์กร ติดตามผมได้ที่ @miles_mazy เติบโตไปด้วยกัน, หาเงินไปด้วยกัน