reveal.js

# 8. Control Version (Git)
**ผู้จัดทำ:** อรรถพล คงหวาน

---

# Outline

1. แนวคิดของ Version Control System
2. การติดตั้งและตั้งค่า Git
3. คำสั่งพื้นฐานของ Git
4. Branching และ Merging
5. Remote Repository
6. Git Workflow

---

# Outline (ต่อ)

7. การทำงานร่วมกัน (Collaboration)
8. การจัดการประวัติ (History Management)
9. Tag และ Release
10. Git Hosting และ Tools
11. Advanced Git
12. สรุปท้ายบท

---

# 8.1
# แนวคิดของ
# Version Control System

---

## 8.1 Version Control System

**ระบบควบคุมเวอร์ชัน (Version Control System – VCS)** คือเครื่องมือที่ใช้บันทึกการเปลี่ยนแปลงของไฟล์ (โดยเฉพาะซอร์สโค้ด) ตลอดเวลา

ทำให้สามารถ:
- ย้อนดูประวัติ
- เปรียบเทียบความต่าง
- กลับไปยังเวอร์ชันก่อนหน้า
- ทำงานร่วมกับผู้อื่นได้อย่างเป็นระบบ

---

## 8.1.1 ประเภทของ VCS

VCS ถูกพัฒนามาในสามรูปแบบหลัก ซึ่งสะท้อนวิวัฒนาการของวิธีจัดเก็บประวัติการเปลี่ยนแปลง:

1. **Local VCS** – เก็บประวัติในเครื่องเดียว
2. **Centralized VCS (CVCS)** – เก็บใน Server กลาง
3. **Distributed VCS (DVCS)** – ทุก Client มี Clone เต็มรูปแบบ

---

## 8.1.1.1 Local VCS

**Local VCS** เป็นรูปแบบดั้งเดิมที่สุด เก็บประวัติไว้ในเครื่องของผู้ใช้เพียงเครื่องเดียว โดยใช้ฐานข้อมูลในเครื่อง (Local Database)

- **ตัวอย่าง:** RCS (Revision Control System)
- **ข้อดี:** ติดตั้งง่าย ไม่ต้องอาศัยเครือข่าย
- **ข้อเสีย:** ทำงานร่วมกันหลายคนไม่ได้ ถ้าฮาร์ดดิสก์เสีย ประวัติทั้งหมดจะหายไป

---

## 8.1.1.2 Centralized VCS (CVCS)

**CVCS** เก็บประวัติทั้งหมดไว้บน **Server กลาง** เพียงตัวเดียว ผู้พัฒนาแต่ละคนต้อง Checkout ไฟล์มาที่เครื่องตนเอง

- **ตัวอย่าง:** CVS, Subversion (SVN), Perforce
- **ข้อดี:** ผู้ดูแลระบบควบคุมสิทธิ์ได้ดี
- **ข้อเสีย:** Single Point of Failure ถ้า Server ล่ม ไม่สามารถ commit ได้

---

## 8.1.1.3 Distributed VCS (DVCS)

**DVCS** ทุก Client มีสำเนา (Clone) ของ Repository **เต็มรูปแบบ** รวมประวัติทั้งหมด

- **ตัวอย่าง:** Git, Mercurial (hg), Fossil, Bazaar
- **ข้อดี:** ทำงาน Offline ได้, แตก Branch ได้รวดเร็ว, สำรองข้อมูลกระจาย
- **ข้อเสีย:** Learning curve สูงกว่า, การจัดการสิทธิ์ละเอียดต้องอาศัยเครื่องมือเสริม

---

## เปรียบเทียบ VCS แต่ละประเภท

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'secondaryColor':'#504945', 'tertiaryColor':'#665c54', 'background':'#282828'}}}%%
flowchart LR
    subgraph LOCAL["Local VCS"]
        DEV1[Developer] --- DB1[(Local DB)]
    end
    subgraph CENTRAL["Centralized VCS"]
        DEV2[Dev A] --> SRV[Central Server]
        DEV3[Dev B] --> SRV
        SRV --- DB2[(Repository)]
    end
    subgraph DIST["Distributed VCS"]
        DEV5[Dev A] --- DB3[(Full Clone)]
        DEV6[Dev B] --- DB4[(Full Clone)]
        DEV5 -.sync.- DEV6
    end
    LOCAL ~~~ CENTRAL ~~~ DIST
    style LOCAL fill:#3c3836,stroke:#d79921,color:#ebdbb2
    style CENTRAL fill:#3c3836,stroke:#458588,color:#ebdbb2
    style DIST fill:#3c3836,stroke:#98971a,color:#ebdbb2
</pre>

---

## ตารางเปรียบเทียบ VCS

| คุณสมบัติ | Local VCS | Centralized | Distributed |
| --- | --- | --- | --- |
| ที่เก็บประวัติ | เครื่องเดียว | Server กลาง | ทุกเครื่อง |
| ทำงาน Offline | ✓ | ✗ | ✓ |
| Single Point of Failure | ✓ | ✓ | ✗ |
| ความเร็ว Branch | ช้า | ช้า | เร็วมาก |
| ตัวอย่าง | RCS | CVS, SVN | Git, Hg |

---

## 8.1.2 ประโยชน์ของ VCS

ประโยชน์หลักของการใช้ VCS โดยเฉพาะ Git:

1. **ประวัติการเปลี่ยนแปลง (History Tracking)** – บันทึก commit ทุกครั้ง
2. **การทำงานร่วมกัน (Collaboration)** – ผ่าน Branch + Merge
3. **การแตกสาขา (Branching)** – ทดลองได้โดยไม่กระทบโค้ดหลัก

---

## 8.1.2 ประโยชน์ของ VCS (ต่อ)

4. **การสำรองข้อมูล (Backup)** – ทุก clone คือ full backup
5. **Code Review** – บูรณาการกับ Pull Request / Merge Request
6. **Continuous Integration/Deployment** – CI/CD Pipeline อ่าน commit history เพื่อ build, test, deploy อัตโนมัติ

---

## สูตร MTTR ของ VCS

**Mean Time To Recovery (MTTR)** เมื่อเกิดปัญหา:

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mi>M</mi><mi>T</mi><mi>T</mi><mi>R</mi>
  <mo>=</mo>
  <mfrac>
    <mrow><mi>T</mi><mo>(</mo><mi>Detect</mi><mo>)</mo>
      <mo>+</mo><mi>T</mi><mo>(</mo><mi>Revert</mi><mo>)</mo>
      <mo>+</mo><mi>T</mi><mo>(</mo><mi>Deploy</mi><mo>)</mo></mrow>
    <mrow><mi>N</mi><mo>(</mo><mi>Incidents</mi><mo>)</mo></mrow>
  </mfrac>
</math>

ยิ่ง MTTR ต่ำ ยิ่งแสดงว่าระบบฟื้นตัวได้เร็ว

---

## 8.1.3 ประวัติของ Git

Git ถือกำเนิดในปี **ค.ศ. 2005** จากความจำเป็นของโครงการ **Linux Kernel**

- เดิม Linux ใช้ระบบเชิงพาณิชย์ชื่อ **BitKeeper** ฟรี
- ผู้พัฒนา BitKeeper ถอนสิทธิ์การใช้งานฟรี
- **Linus Torvalds** จึงตัดสินใจสร้าง VCS ใหม่ที่ตรงตามที่ Linux Kernel ต้องการ

---

## เป้าหมายการออกแบบของ Git

- **เร็ว (Speed)** – จัดการ Linux Kernel ที่มี source หลายล้านบรรทัดได้
- **เรียบง่ายในแง่ data model** – snapshot-based ไม่ใช่ delta-based
- **รองรับ Non-linear development** – แตก Branch จำนวนมากได้
- **กระจายอย่างเต็มรูปแบบ (Fully Distributed)**
- **จัดการโครงการขนาดใหญ่** ได้อย่างมีประสิทธิภาพ

---

## Timeline วิวัฒนาการของ VCS

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
flowchart TB
    subgraph ERA1["1970s-1980s Local VCS"]
        SCCS[SCCS 1972] --> RCS[RCS 1982]
    end
    subgraph ERA2["1990s-2000s Centralized"]
        CVS[CVS 1990] --> SVN[SVN 2000]
    end
    subgraph ERA3["2005+ Distributed"]
        GIT[Git 2005]
        HG[Mercurial 2005]
    end
    subgraph ERA4["2008+ Cloud Hosting"]
        GH[GitHub 2008]
        GL[GitLab 2011]
    end
    RCS --> CVS
    SVN --> GIT
    GIT --> GH
    GIT --> GL
    style ERA1 fill:#3c3836,stroke:#cc241d,color:#ebdbb2
    style ERA2 fill:#3c3836,stroke:#d79921,color:#ebdbb2
    style ERA3 fill:#3c3836,stroke:#98971a,color:#ebdbb2
    style ERA4 fill:#3c3836,stroke:#458588,color:#ebdbb2
</pre>

---

## ที่มาของชื่อ "Git"

> Linus Torvalds เคยให้สัมภาษณ์ขำ ๆ ว่าชื่อ Git มาจากภาษา British Slang ที่หมายถึง "**คนน่ารำคาญ**"
>
> และเล่นมุกว่า "ผมตั้งชื่อโปรแกรมตามตัวเองทุกครั้ง คราวก่อนคือ Linux คราวนี้คือ Git"

---

# 8.2
# การติดตั้งและ
# ตั้งค่า Git

---

## 8.2.1 การติดตั้งบน Linux

```bash
# Debian/Ubuntu - APT
sudo apt update && sudo apt install -y git

# Fedora/RHEL - DNF
sudo dnf install -y git

# Arch/Manjaro - Pacman
sudo pacman -S git

# ตรวจสอบเวอร์ชัน
git --version
```

---

## 8.2.1 การติดตั้งบน Linux (ต่อ)

```bash
# openSUSE - Zypper
sudo zypper install git

# Alpine Linux - APK
sudo apk add git

# ตรวจสอบเวอร์ชันหลังติดตั้ง
git --version
# ตัวอย่าง output: git version 2.43.0
```

---

## 8.2.1.2 การติดตั้งบน macOS

```bash
# ผ่าน Homebrew (แนะนำ)
brew install git

# ผ่าน Xcode Command Line Tools
xcode-select --install

# ตรวจสอบ
git --version
```

---

## 8.2.1.3 การติดตั้งบน Windows

```bash
# ผ่าน winget (Windows 10/11)
winget install --id Git.Git -e

# ผ่าน Chocolatey
choco install git -y

# ผ่าน Scoop
scoop install git
```

หรือดาวน์โหลด Git for Windows จาก `https://git-scm.com/`

---

## 8.2.2 ระดับของ git config

Git มี config 3 ระดับ ที่ override ซึ่งกันและกัน (local มีลำดับสูงสุด):

| ระดับ | Flag | ตำแหน่งไฟล์ |
| --- | --- | --- |
| System | `--system` | `/etc/gitconfig` |
| Global | `--global` | `~/.gitconfig` |
| Local | `--local` | `.git/config` |

---

## คำสั่ง git config ที่ใช้บ่อย

```bash
# ดูค่า config ทั้งหมด พร้อมแหล่งที่มา
git config --list --show-origin

# ตั้งค่าระดับ Global
git config --global user.name "Moo Lecturer"
git config --global user.email "moo@example.ac.th"

# แก้ไข config ผ่าน editor
git config --global --edit
```

---

## 8.2.3 ค่าพื้นฐานที่ควรตั้ง

```bash
# ตัวตนของผู้ใช้
git config --global user.name "Moo Lecturer"
git config --global user.email "moo@rmutsv.ac.th"

# Editor ที่ใช้เขียน commit message
git config --global core.editor "vim"

# ชื่อ Branch เริ่มต้น
git config --global init.defaultBranch main
```

---

## ค่า config ที่แนะนำเพิ่มเติม

```bash
# pull ด้วย rebase
git config --global pull.rebase true

# จัดการ line ending
git config --global core.autocrlf input   # Linux/macOS
git config --global core.autocrlf true    # Windows

# เปิดสีใน output
git config --global color.ui auto
```

---

## ตั้งค่า Alias

```bash
git config --global alias.st "status -sb"
git config --global alias.co "checkout"
git config --global alias.br "branch"
git config --global alias.lg "log --oneline --graph --all --decorate"

# Push เฉพาะ branch ปัจจุบัน
git config --global push.default current

# rerere - ลดการแก้ conflict ซ้ำ
git config --global rerere.enabled true
```

---

## 8.2.4 Credential Helper

**Credential Helper** ช่วยจดจำ username/password หรือ token

```bash
# Cache ใน RAM
git config --global credential.helper "cache --timeout=3600"

# บน macOS - ใช้ Keychain
git config --global credential.helper osxkeychain

# บน Windows - ใช้ Git Credential Manager
git config --global credential.helper manager-core
```

---

## SSH Key (วิธีที่แนะนำที่สุด)

```bash
# สร้าง SSH key
ssh-keygen -t ed25519 -C "moo@rmutsv.ac.th"

# แสดง public key เพื่อเพิ่มใน GitHub/GitLab
cat ~/.ssh/id_ed25519.pub
```

ใช้ SSH key แทน HTTPS เพื่อไม่ต้องพิมพ์รหัสและปลอดภัยกว่า

---

# 8.3
# คำสั่งพื้นฐาน
# ของ Git

---

## 8.3.1 git init

```bash
# สร้าง repository ใหม่
mkdir my-project && cd my-project
git init
# ผลลัพธ์: สร้างโฟลเดอร์ .git/

# ระบุ branch เริ่มต้น
git init --initial-branch=main

# สร้าง bare repository (สำหรับ server)
git init --bare /srv/git/my-project.git
```

---

## 8.3.1 git clone

```bash
# Clone ผ่าน HTTPS
git clone https://github.com/torvalds/linux.git

# Clone ผ่าน SSH
git clone git@github.com:torvalds/linux.git

# Clone ลง folder ชื่ออื่น
git clone https://github.com/user/repo.git my-folder

# Shallow clone (เฉพาะ commit ล่าสุด)
git clone --depth 1 https://github.com/user/repo.git
```

---

## 8.3.2 git status & git add

```bash
# ดูสถานะ
git status
git status -s    # short format
git status -sb   # short + branch info

# เพิ่มไฟล์เข้า Staging Area
git add file1.txt          # ไฟล์เดียว
git add .                  # ทุกไฟล์ในโฟลเดอร์
git add -A                 # ทุกไฟล์ที่เปลี่ยน
git add -p                 # interactive: เลือก hunk
```

---

## 8.3.2 git commit

```bash
# Commit ปกติ
git commit -m "feat: add user login feature"

# Commit ทุกไฟล์ที่ tracked (ข้าม staging)
git commit -am "fix: typo in README"

# แก้ commit ล่าสุด
git commit --amend --no-edit          # ไม่แก้ message
git commit --amend -m "new message"   # แก้ message
```

---

## 8.3.2.1 Conventional Commits

มาตรฐานการเขียน commit message ที่นิยมในโปรเจกต์โอเพนซอร์ส:

```
<type>(<scope>): <subject>

<body>

<footer>
```

ตัวอย่าง:
```
feat(auth): add OAuth2 login with Google
```

---

## Conventional Commits Types

| Type | ความหมาย |
| --- | --- |
| `feat` | ฟีเจอร์ใหม่ |
| `fix` | แก้ไขบั๊ก |
| `docs` | เปลี่ยนเอกสาร |
| `style` | จัดรูปแบบ |
| `refactor` | ปรับโครงสร้างโค้ด |
| `test` | เพิ่ม/แก้ test |
| `chore` | งานบำรุงรักษา |

---

## 8.3.3 Three Trees Model

Git มี **3 พื้นที่หลัก** ที่ไฟล์เดินทางผ่าน:

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
flowchart LR
    WD["Working<br>Directory"]
    SA["Staging<br>Area / Index"]
    REPO["Repository<br>(.git/objects)"]
    REMOTE["Remote<br>Repository"]

style WD fill:#3c3836,stroke:#d79921,color:#ebdbb2
    style SA fill:#3c3836,stroke:#d65d0e,color:#ebdbb2
    style REPO fill:#3c3836,stroke:#98971a,color:#ebdbb2
    style REMOTE fill:#3c3836,stroke:#458588,color:#ebdbb2
</pre>

---

## สรุป Three Trees Model

- **Working Directory** – ไฟล์ที่อยู่ในเครื่องตอนนี้ ที่เรา edit ได้จริง
- **Staging Area (Index)** – พื้นที่กลางที่บอก Git ว่า "ไฟล์ใดบ้างจะรวมใน commit ถัดไป"
- **Repository** – ที่เก็บ snapshot ของ commit ทั้งหมดในโฟลเดอร์ `.git/`

---

## 8.3.4 git log

```bash
# ดูประวัติทั้งหมด
git log

# แบบบรรทัดเดียว
git log --oneline

# แสดงกราฟของ branch
git log --oneline --graph --all --decorate

# กรองตาม author
git log --author="Moo"
```

---

## git log - การค้นหาขั้นสูง

```bash
# กรองตามช่วงเวลา
git log --since="2 weeks ago" --until="yesterday"

# ค้นหาใน commit message
git log --grep="bug"

# ค้นหาใน source code (pickaxe)
git log -S"function_name"

# ดูพร้อม diff
git log -p file.txt
```

---

## 8.3.5 git diff

```bash
# Working Directory vs Staging Area
git diff

# Staging Area vs HEAD
git diff --staged
git diff --cached    # alias เดียวกัน

# Working Directory vs HEAD
git diff HEAD

# เปรียบเทียบ 2 commit
git diff abc123 def456
```

---

## git diff - การเปรียบเทียบ branch

```bash
# เปรียบเทียบ branch
git diff main..feature
git diff main...feature   # 3 dots = หา common ancestor

# เปรียบเทียบเฉพาะไฟล์
git diff main feature -- src/app.py

# แสดงเฉพาะชื่อไฟล์ที่เปลี่ยน
git diff --name-only
git diff --name-status    # พร้อมสถานะ A/M/D
```

---

## 8.3.6 .gitignore

ไฟล์ `.gitignore` บอก Git ว่า "ไฟล์ใดไม่ต้อง track"

```bash
# ตัวอย่าง .gitignore สำหรับ Python
__pycache__/
*.py[cod]
venv/
.venv/

# === Environment & Secrets ===
.env
.env.local
*.pem
```

---

## .gitignore สำหรับ Node.js และ IDE

```bash
# === Node.js ===
node_modules/
npm-debug.log*

# === IDE / Editor ===
.vscode/
.idea/
*.swp
.DS_Store

# === ยกเว้นบางไฟล์ (negation) ===
!important.log
```

---

## Global .gitignore

```bash
# Global gitignore (ใช้กับทุก repo)
git config --global core.excludesfile ~/.gitignore_global

# ถ้าไฟล์ถูก track แล้ว ต้องลบออกก่อน
git rm --cached secret.env
git commit -m "chore: stop tracking secret.env"

# ตรวจว่าไฟล์ถูก ignore เพราะ rule ไหน
git check-ignore -v node_modules/foo.js
```

---

# 8.4
# Branching และ
# Merging

---

## 8.4.1 แนวคิด Branch และ HEAD

ใน Git **Branch** คือ **pointer (ตัวชี้) ไปยัง commit หนึ่ง** ไม่ใช่สำเนาของไฟล์

- ทำให้แตก branch เร็วและประหยัดพื้นที่มาก
- **HEAD** คือ pointer พิเศษที่ชี้ไปยัง branch ปัจจุบัน
- ทุก commit รู้ "parent" ของตัวเอง = **DAG (Directed Acyclic Graph)**

---

## ตัวอย่าง Git Graph

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
gitGraph
    commit id: "C1"
    commit id: "C2"
    branch feature/login
    checkout feature/login
    commit id: "C3"
    commit id: "C4"
    checkout main
    commit id: "C5"
    checkout feature/login
    commit id: "C6"
    checkout main
    merge feature/login id: "C7"
    commit id: "C8"
</pre>

---

## 8.4.2 git branch - ดู branch

```bash
git branch              # local branch
git branch -r           # remote branch
git branch -a           # ทั้ง local + remote
git branch -v           # พร้อม commit hash ล่าสุด
git branch --merged     # branch ที่ merge แล้ว
git branch --no-merged  # branch ที่ยังไม่ merge
```

---

## git branch - สร้างและสลับ

```bash
# สร้าง branch ใหม่ (ยังไม่ switch)
git branch feature/user-auth

# สร้าง + switch ทีเดียว (วิธีเก่า)
git checkout -b feature/user-auth

# สร้าง + switch (วิธีใหม่ - Git 2.23+)
git switch -c feature/user-auth

# Switch กลับไป branch อื่น
git switch main
```

---

## git branch - เปลี่ยนชื่อและลบ

```bash
# เปลี่ยนชื่อ branch
git branch -m old-name new-name
git branch -m new-name        # ชื่อ branch ปัจจุบัน

# ลบ branch (ปลอดภัย)
git branch -d feature/user-auth

# ลบ branch แบบบังคับ
git branch -D feature/user-auth

# Detached HEAD
git switch -d abc1234
```

---

## 8.4.3 git merge

มี **2 รูปแบบหลัก** ของการ merge:

1. **Fast-forward Merge** – เกิดเมื่อ target branch ไม่มี commit ใหม่ Git แค่เลื่อน pointer
2. **Three-way Merge** – เกิดเมื่อทั้งสอง branch มี commit ใหม่ Git สร้าง merge commit ใหม่ที่มี 2 parents

---

## Fast-forward Merge

```bash
# scenario: main ไม่มี commit ใหม่
git switch main
git merge feature/login
# Git จะ "fast-forward" main pointer
```

ตัวเลือกพิเศษ:
```bash
# บังคับสร้าง merge commit แม้ fast-forward ได้
git merge --no-ff feature/login

# บังคับ fast-forward เท่านั้น
git merge --ff-only feature/login
```

---

## Three-way Merge และ Squash

```bash
# Three-way merge ปกติ
git switch main
git merge feature/login
# Git สร้าง merge commit ใหม่

# Squash merge - รวมทุก commit เป็น 1
git merge --squash feature/login
git commit -m "feat: complete login feature"
```

---

## Three-way Merge Diagram

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
gitGraph
    commit id: "A"
    commit id: "B"
    branch feature
    checkout feature
    commit id: "C"
    commit id: "D"
    checkout main
    commit id: "E"
    merge feature id: "F"
    commit id: "G"
</pre>

---

## 8.4.4 Merge Conflict

**Merge Conflict** เกิดเมื่อสอง branch แก้บรรทัดเดียวกันในไฟล์เดียวกันด้วยวิธีต่างกัน

```
<<<<<<< HEAD
main updated
=======
feature version
>>>>>>> feature
```

Git จะหยุดและให้คนตัดสินใจเลือกเวอร์ชัน

---

## ขั้นตอนการแก้ Conflict

```bash
# 1. ดูสถานะและไฟล์ที่ conflict
git status

# 2. แก้ไขไฟล์ - ลบเครื่องหมาย <<<, ===, >>> ออก
vim config.txt

# 3. add ไฟล์ที่แก้แล้ว
git add config.txt

# 4. commit เพื่อจบ merge
git commit
```

---

## ยกเลิก Merge

```bash
# ยกเลิก merge ทั้งหมด
git merge --abort

# ใช้ tool ช่วยแก้ conflict
git mergetool

# ตั้งค่า merge tool
git config --global merge.tool vimdiff
git config --global merge.tool meld
```

---

## 8.4.5 git rebase

**Rebase** ย้าย commit ของ branch ปัจจุบันไป "วาง" บนยอดของ branch อื่น

```bash
# Merge - คง history แท้จริง
git switch feature
git merge main

# Rebase - ทำให้ history เป็นเส้นตรง
git switch feature
git rebase main
```

> **กฎทอง:** อย่า rebase commit ที่ push ไป shared branch แล้ว

---

## จัดการ Rebase Conflict

```bash
# ถ้า conflict ระหว่าง rebase
git add <resolved-file>
git rebase --continue

# ยกเลิก rebase
git rebase --abort

# ข้าม commit ที่ conflict
git rebase --skip

# Interactive Rebase (อธิบายในหัวข้อ 8.8)
git rebase -i HEAD~3
```

---

## Merge vs Rebase

| ลักษณะ | Merge | Rebase |
| --- | --- | --- |
| รักษา history | ✓ ตรงตามจริง | ✗ เขียนใหม่ |
| Merge commit | สร้าง | ไม่มี |
| ความสะอาดกราฟ | ซับซ้อน | เป็นเส้นตรง |
| ความปลอดภัย | สูง | ต่ำ |
| เหมาะกับ | shared branch | private branch |

---

## 8.4.6 Cherry-pick

นำเฉพาะ **commit ที่เลือก** จาก branch หนึ่งไปอีก branch หนึ่ง

```bash
# Cherry-pick commit เดียว
git cherry-pick abc1234

# Cherry-pick หลาย commit
git cherry-pick abc1234 def5678

# Cherry-pick ช่วง commit
git cherry-pick abc1234..def5678
git cherry-pick abc1234^..def5678  # รวม abc1234
```

---

## Cherry-pick - การจัดการ

```bash
# Cherry-pick โดยไม่ commit
git cherry-pick -n abc1234

# จัดการ conflict
git cherry-pick --continue
git cherry-pick --abort
git cherry-pick --skip
```

**Use case:** นำ hotfix จาก `main` ไปใส่ branch ของรุ่น release เก่าที่ยังต้อง support

---

# 8.5
# Remote
# Repository

---

## 8.5.1 git remote

**Remote Repository** คือ repository ที่อยู่บน server อื่น (เช่น GitHub)

```bash
# ดู remote ทั้งหมด
git remote
git remote -v   # พร้อม URL

# เพิ่ม remote ชื่อ "origin"
git remote add origin git@github.com:moo/my-project.git

# เพิ่ม remote ที่สอง (กรณี fork)
git remote add upstream git@github.com:original/my-project.git
```

---

## git remote - การจัดการ

```bash
# เปลี่ยน URL ของ remote
git remote set-url origin git@gitlab.com:moo/my-project.git

# เปลี่ยนชื่อ remote
git remote rename origin github

# ลบ remote
git remote remove old-remote

# ดูข้อมูลละเอียด
git remote show origin
```

---

## 8.5.2 git fetch

```bash
# Fetch - ดาวน์โหลด commit แต่ไม่ merge
git fetch origin
git fetch --all       # ทุก remote
git fetch --prune     # ลบ remote-tracking ที่ไม่มีแล้ว
```

**Fetch** ปลอดภัย ดูได้ก่อนตัดสินใจ merge

---

## 8.5.2 git pull

```bash
# Pull = Fetch + Merge (default)
git pull origin main

# Pull = Fetch + Rebase
git pull --rebase origin main

# ยอมเฉพาะ fast-forward (ปลอดภัย)
git pull --ff-only origin main
```

---

## 8.5.2 git push

```bash
# Push commit ของ local ไปที่ remote
git push origin main

# -u = ตั้ง upstream ครั้งแรก
git push -u origin feature/new

# Push ทุก branch
git push --all origin

# Push tags
git push --tags origin

# ลบ branch บน remote
git push origin --delete feature/old
```

---

## Force Push (อันตราย!)

```bash
# Force push - อันตรายมาก
git push --force origin feature

# Force-with-lease - ปลอดภัยกว่า
git push --force-with-lease origin feature
```

ใช้เมื่อ rebase แล้วและรู้ว่าทำอะไรอยู่เท่านั้น

---

## 8.5.3 Tracking Branch

**Tracking Branch** = local branch ที่ผูกกับ remote branch เฉพาะตัว

```bash
# ตั้ง upstream ครั้งแรก
git push -u origin feature/login
# หลังจากนี้ git push / git pull ได้เลย

# เปลี่ยน upstream ของ branch ปัจจุบัน
git branch --set-upstream-to=origin/main

# ดูสถานะ ahead/behind
git status -sb
```

---

## 8.5.4 Origin, Upstream, Fork

ในวัฒนธรรม OSS เมื่อ contribute โปรเจกต์ของผู้อื่น:

1. **Fork** repo ผ่าน GitHub UI → ได้ copy ใน account ตัวเอง
2. **Clone** fork ของตัวเอง → ตั้งเป็น `origin`
3. เพิ่ม **upstream** ชี้ไปที่ repo ต้นฉบับ
4. ดึง update จาก upstream เป็นระยะ

---

## Workflow Fork & Pull Request

```bash
git clone git@github.com:moo/awesome-lib.git
cd awesome-lib
git remote add upstream git@github.com:original/awesome-lib.git

# อัปเดตจาก upstream
git fetch upstream
git switch main
git merge upstream/main
git push origin main
```

---

## สร้าง Feature Branch + PR

```bash
# สร้าง feature branch
git switch -c feature/cool-feature

# ... แก้โค้ด commit ...
git push -u origin feature/cool-feature

# เปิด Pull Request ผ่าน GitHub UI
# จาก fork ไปยัง upstream
```

---

## 8.5.5 Refspec

**Refspec** บอก Git ว่า "อ้างอิง local จะตรงกับอ้างอิง remote อย่างไร"

รูปแบบ: `<src>:<dst>` หรือ `+<src>:<dst>` (force)

```bash
# Push local feature ไปเป็น wip บน remote
git push origin feature:wip

# Pull เฉพาะ branch
git fetch origin main:main

# ดู refspec ใน config
git config --get-all remote.origin.fetch
```

---

# 8.6
# Git
# Workflow

---

## 8.6.1 Centralized Workflow

ทีมเล็ก ทุกคนทำงานบน `main` โดยตรง ใช้ `git pull --rebase` ก่อน push

```bash
git switch main
git pull --rebase origin main
# แก้โค้ด
git add . && git commit -m "feat: ..."
git pull --rebase origin main
git push origin main
```

**ข้อเสีย:** เสี่ยงโค้ดพังบน main, ไม่มี code review

---

## 8.6.2 Feature Branch Workflow

ทุก feature ทำใน branch แยก แล้ว merge กลับ main ผ่าน Pull Request

```bash
git switch main && git pull
git switch -c feature/payment-integration

# ... ทำงาน + commit ...
git push -u origin feature/payment-integration

# เปิด PR ใน GitHub/GitLab
# หลัง review ผ่าน → merge
```

---

## 8.6.3 Git Flow

โครงสร้างซับซ้อน เหมาะกับโปรเจกต์ที่มี release schedule ชัดเจน

- `main` – production ready (tag ทุก release)
- `develop` – integration ของ feature
- `feature/*` – แยกจาก develop merge กลับ develop
- `release/*` – เตรียม release
- `hotfix/*` – แก้บั๊ก production ด่วน

---

## Git Flow Diagram

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
gitGraph
    commit id: "init"
    branch develop
    checkout develop
    commit id: "dev-1"
    branch feature/A
    commit id: "feat-A"
    checkout develop
    merge feature/A
    branch release/1.0
    commit id: "rel-prep"
    checkout main
    merge release/1.0 tag: "v1.0"
    branch hotfix/1.0.1
    commit id: "hotfix"
    checkout main
    merge hotfix/1.0.1 tag: "v1.0.1"
</pre>

---

## 8.6.4 GitHub Flow

เรียบง่าย เหมาะกับ Continuous Deployment

1. แตก branch จาก `main`
2. commit + push
3. เปิด Pull Request
4. Code Review
5. Deploy + Merge

---

## 8.6.5 GitLab Flow

เพิ่ม **environment branch** ระหว่าง main กับ deployment

```
main → pre-production → production
```

ทุก deploy คือ merge จาก branch หนึ่งไปอีก branch หนึ่ง

ทำให้ track ได้ว่ามี code ไหนอยู่ environment ไหน

---

## 8.6.6 Trunk-based Development

ทุกคน commit เข้า `main` (trunk) ผ่าน short-lived branch (1-2 วัน) ใช้ **Feature Flag** ซ่อนของที่ยังไม่พร้อม

- **ข้อดี:** integration ถี่ ลด merge hell, เหมาะกับ DevOps ระดับสูง
- **ข้อเสีย:** ต้องการ test coverage และวินัยสูงมาก

---

## เปรียบเทียบ Workflow

| Workflow | ขนาดทีม | Release | ความซับซ้อน |
| --- | --- | --- | --- |
| Centralized | 1-3 | ต่ำ | ต่ำมาก |
| Feature Branch | 3-20 | ปานกลาง | ต่ำ |
| Git Flow | 20+ | ตามรอบ | สูง |
| GitHub Flow | 5-50 | สูง (CD) | ต่ำ-กลาง |
| Trunk-based | 5-1000+ | สูงมาก | ต่ำ + วินัยสูง |

---

# 8.7
# การทำงานร่วมกัน
# (Collaboration)

---

## 8.7.1 Pull / Merge Request

**Pull Request (GitHub)** หรือ **Merge Request (GitLab)** = feature ของ git host ที่ให้ผู้พัฒนาเสนอให้ merge branch ของตน

มาพร้อมระบบ:
- Review
- Discussion
- CI Integration

---

## ขั้นตอนการเปิด PR

1. Push branch ขึ้น remote: `git push -u origin feature/x`
2. ไปที่ web UI แล้วกด "New Pull Request"
3. เลือก base branch และ compare branch
4. เขียน title + description (what/why/how to test)
5. กำหนด reviewer, label, milestone
6. รอ CI ผ่าน + approval
7. Merge (Merge / Squash / Rebase)

---

## PR Description Template

```markdown
## What
อธิบายสิ่งที่เปลี่ยนแปลงในระดับสูง

## Why
ที่มาของการเปลี่ยนแปลง อ้างอิง Issue (Closes #123)

## How
รายละเอียดทางเทคนิคที่ผู้รีวิวควรรู้

## Test
- [ ] Unit test ผ่าน
- [ ] อัปเดต documentation
```

---

## 8.7.2 Code Review

แนวปฏิบัติของการรีวิวที่ดี:

- **มองหาความถูกต้อง** ก่อน style
- ใช้ **conventional comment**: `nit:`, `suggestion:`, `question:`, `issue:`, `praise:`
- รีวิวที่ละ ≤ 400 บรรทัด มิเช่นนั้น quality ตก
- ตอบกลับภายใน 24 ชั่วโมง
- ผู้เขียนอย่าตอบโต้แบบส่วนตัว

---

## 8.7.3 Fork และ Upstream Sync

```bash
# Sync fork กับ upstream (ผ่าน rebase)
git fetch upstream
git switch main
git rebase upstream/main
git push origin main

# หรือ merge
git merge upstream/main
```

ควรทำเป็นประจำเพื่อไม่ให้ fork ตกรุ่น

---

## 8.7.4 git format-patch

สำหรับโครงการแบบ Linux Kernel ที่ใช้ email-based workflow

```bash
# สร้าง patch จาก commit
git format-patch -1 HEAD
git format-patch main..feature

# ผลลัพธ์: 0001-feat-add-x.patch, ...

# ส่ง patch ทาง email
git send-email --to=list@kernel.org *.patch
```

---

## git am - Apply Patch

```bash
# Apply patch ที่ได้รับ
git am < patch.eml
git am 0001-feat-add-x.patch

# ยกเลิก
git am --abort

# หลังแก้ conflict
git am --continue
```

---

## 8.7.5 CONTRIBUTING.md

ไฟล์มาตรฐานในรากของ repo:

- **`CONTRIBUTING.md`** – คู่มือสำหรับผู้ contribute
- **`.github/CODEOWNERS`** – กำหนด reviewer อัตโนมัติ

```
# .github/CODEOWNERS
*           @moo @team-lead
/backend/   @backend-team
*.tsx       @frontend-team
```

---

# 8.8
# การจัดการประวัติ
# (History Management)

---

## 8.8.1 git reset - 3 modes

`git reset` ย้าย HEAD ไปยัง commit ที่ระบุ

| Mode | HEAD | Staging | Working Dir |
| --- | --- | --- | --- |
| `--soft` | ย้าย | คงเดิม | คงเดิม |
| `--mixed` | ย้าย | reset | คงเดิม |
| `--hard` | ย้าย | reset | reset (อันตราย!) |

---

## git reset - ตัวอย่าง

```bash
# ยกเลิก commit ล่าสุด เก็บ staging
git reset --soft HEAD~1

# ยกเลิก commit ล่าสุด เก็บ working dir
git reset HEAD~1   # default --mixed

# ยกเลิก + ทิ้งการเปลี่ยนแปลง (ระวัง!)
git reset --hard HEAD~1

# Unstage ไฟล์ (วิธีใหม่)
git restore --staged file.txt
```

---

## 8.8.2 git revert vs git reset

- **reset** = "เขียน history ใหม่" – อันตรายบน shared branch
- **revert** = "ลบล้างผลด้วย commit ใหม่" – ปลอดภัย เพิ่ม history

```bash
# สร้าง commit ใหม่ที่ลบล้าง commit เก่า
git revert abc1234

# Revert merge commit (ระบุ parent)
git revert -m 1 <merge-commit>

# Revert โดยไม่ commit
git revert -n abc1234
```

---

## 8.8.3 git reflog

**reflog** = บันทึกของทุกครั้งที่ HEAD หรือ branch reference เปลี่ยน

```bash
# ดู reflog ทั้งหมด
git reflog

# ตัวอย่าง output:
# abc1234 HEAD@{0}: reset: moving to HEAD~3
# def5678 HEAD@{1}: commit: feat: add feature X
```

**ช่วยกู้ commit ที่ "หาย" ได้** (เก็บใน local เท่านั้น)

---

## กู้คืน commit ด้วย reflog

```bash
# กู้ commit ที่ลบทิ้งไป
git reset --hard HEAD@{1}
# หรือ
git reset --hard def5678

# reflog ของ branch
git reflog show feature/login

# default เก็บนาน 90 วัน
git config gc.reflogExpire
```

---

## 8.8.4 Interactive Rebase

เครื่องมือทรงพลังที่สุดในการจัดระเบียบ history

```bash
# rebase 5 commit ล่าสุด แบบ interactive
git rebase -i HEAD~5
```

Editor จะเปิดให้แก้คำสั่งของแต่ละ commit:
- `pick` – ใช้ commit นี้
- `reword` – ใช้แต่แก้ message
- `squash` / `fixup` – รวมเข้า commit ก่อนหน้า

---

## Interactive Rebase - Commands

```
p, pick   = ใช้ commit นี้
r, reword = ใช้แต่แก้ message
e, edit   = หยุดเพื่อแก้ commit
s, squash = รวมเข้า commit ก่อน (รวม message)
f, fixup  = รวมเข้า commit ก่อน (ทิ้ง message)
x, exec   = รัน shell command
d, drop   = ลบ commit นี้
```

---

## Interactive Rebase - ตัวอย่าง

ก่อนแก้:
```
pick abc1234 feat: add login
pick def5678 fix: typo
pick ghi9012 feat: add logout
pick jkl3456 wip: testing
```

หลังแก้:
```
pick abc1234 feat: add login
fixup def5678 fix: typo
pick ghi9012 feat: add logout
drop jkl3456 wip: testing
```

---

## Auto-squash Workflow

```bash
# สร้าง commit "fixup!"
git commit --fixup=abc1234

# จัดเรียงและรวมอัตโนมัติ
git rebase -i --autosquash HEAD~10
```

ช่วยให้ commit history สะอาดโดยไม่ต้องแก้ทีละ commit

---

## 8.8.5 git stash

**Stash** = พักงานที่ยังไม่พร้อม commit ไว้ที่ "ชั้นวางชั่วคราว"

```bash
# พักงานปัจจุบัน
git stash
git stash push -m "WIP: refactoring auth"
git stash -u    # รวม untracked file
git stash -a    # รวม ignored file ด้วย
git stash push -p   # interactive
```

---

## git stash - การจัดการ

```bash
# ดู stash ทั้งหมด
git stash list

# ดูเนื้อหา stash
git stash show -p stash@{1}

# กลับมาทำงานต่อ
git stash pop          # apply + ลบ stash
git stash apply        # apply แต่เก็บไว้
git stash apply stash@{2}

# ลบ stash
git stash drop stash@{1}
git stash clear        # ลบทั้งหมด
```

---

## สร้าง branch จาก stash

```bash
# สร้าง branch ใหม่จาก stash
git stash branch new-feature stash@{0}
```

มีประโยชน์เมื่อรู้ว่างานที่ stash ไว้ควรเป็น branch แยก ไม่ใช่ commit บน branch ปัจจุบัน

---

# 8.9
# Tag และ
# Release

---

## 8.9.1 ประเภทของ Tag

**Tag** คือ pointer ไปยัง commit เฉพาะ ที่ไม่เคลื่อนที่ ใช้ทำเครื่องหมาย version release

| คุณสมบัติ | Lightweight | Annotated |
| --- | --- | --- |
| ผู้สร้าง/วันที่ | ✗ | ✓ |
| Message | ✗ | ✓ |
| GPG sign | ✗ | ✓ |
| ใช้สำหรับ | bookmark | release ทางการ |

---

## สร้าง Tag

```bash
# Lightweight Tag
git tag v1.0-light

# Annotated Tag (แนะนำสำหรับ release)
git tag -a v1.0 -m "Release version 1.0"

# Tag commit เก่า (ไม่ใช่ HEAD)
git tag -a v0.9 abc1234 -m "Beta release"

# GPG signed tag
git tag -s v1.0 -m "Signed release"
```

---

## 8.9.2 git tag - การจัดการ

```bash
# ดู tag ทั้งหมด
git tag
git tag -l "v1.*"      # filter pattern
git tag -n             # พร้อม annotation

# ดูรายละเอียด tag
git show v1.0

# ลบ tag ใน local
git tag -d v1.0

# ลบ tag บน remote
git push origin --delete v1.0
```

---

## Push Tag ไป Remote

```bash
# Push tag เดียว
git push origin v1.0

# Push ทุก tag
git push origin --tags

# Push เฉพาะ annotated tag ที่เกี่ยวข้อง
git push origin --follow-tags

# Checkout ที่ tag (detached HEAD)
git checkout v1.0
git switch --detach v1.0
```

---

## 8.9.3 Semantic Versioning

มาตรฐาน **MAJOR.MINOR.PATCH** ตาม semver.org

<math xmlns="http://www.w3.org/1998/Math/MathML" display="block">
  <mi>v</mi><mo>=</mo>
  <mtext>MAJOR</mtext><mo>.</mo>
  <mtext>MINOR</mtext><mo>.</mo>
  <mtext>PATCH</mtext>
  <mo>[</mo><mo>-</mo><mtext>PRERELEASE</mtext><mo>]</mo>
  <mo>[</mo><mo>+</mo><mtext>BUILD</mtext><mo>]</mo>
</math>

---

## SemVer - ความหมาย

- **MAJOR** – เพิ่มเมื่อมี breaking change (API ไม่เข้ากันย้อนหลัง)
- **MINOR** – เพิ่มเมื่อมี feature ใหม่ที่ backward compatible
- **PATCH** – เพิ่มเมื่อแก้บั๊กเล็กน้อย
- **PRERELEASE** – เช่น `-alpha.1`, `-rc.2`
- **BUILD** – เช่น `+20240125`

---

## SemVer - ตัวอย่าง

| ตัวอย่าง | ความหมาย |
| --- | --- |
| `v1.0.0` | Stable release แรก |
| `v1.0.1` | Patch แก้บั๊ก |
| `v1.1.0` | Minor – feature ใหม่ |
| `v2.0.0` | Major – breaking change |
| `v2.0.0-rc.1` | Release candidate |
| `v2.0.0-beta.3+a1b2c3d` | Beta + build metadata |

---

## 8.9.4 Release บน GitHub

**Release** = Tag + เอกสาร changelog + binary artifact

```bash
# ผ่าน GitHub CLI (gh)
gh release create v1.0.0 \
  --title "v1.0.0 - Initial Release" \
  --notes "Initial public release" \
  ./dist/myapp-linux-amd64.tar.gz

# Auto-generate notes จาก commit/PR
gh release create v1.1.0 --generate-notes
```

---

## Release บน GitLab

```bash
# ผ่าน GitLab CLI (glab)
glab release create v1.0.0 \
  --name "Version 1.0.0" \
  --notes "Initial release"
```

ใช้ **Conventional Changelog** tools เช่น:
- `git-cliff` (Rust)
- `standard-version`
- `release-please`

---

## git-cliff - สร้าง Changelog

```bash
# ติดตั้ง git-cliff
cargo install git-cliff

# สร้าง CHANGELOG.md
git cliff --output CHANGELOG.md

# สำหรับ tag เฉพาะ
git cliff --tag v1.1.0 --output CHANGELOG.md
```

สร้าง CHANGELOG อัตโนมัติจาก Conventional Commits

---

# 8.10
# Git Hosting
# และ Tools

---

## 8.10.1 Git Hosting หลัก

| Hosting | จุดเด่น | Free Private | CI/CD |
| --- | --- | --- | --- |
| **GitHub** | Community ใหญ่ที่สุด, Actions | ✓ ไม่จำกัด | Actions |
| **GitLab** | DevOps ครบวงจร, Self-host | ✓ ไม่จำกัด | GitLab CI |
| **Bitbucket** | บูรณาการ Jira/Confluence | ≤5 user | Pipelines |

---

## 8.10.2 Self-hosted Git

สำหรับองค์กรที่ต้องการ host เอง:

- **Gitea** – Go, เบามาก (~200MB RAM), UI คล้าย GitHub
- **Forgejo** – Fork ของ Gitea, community-driven
- **Gogs** – ต้นกำเนิดของ Gitea
- **GitLab CE** – ครบวงจร แต่หนัก (~4GB RAM)

---

## Gitea ผ่าน Docker

```yaml
services:
  gitea:
    image: gitea/gitea:latest
    environment:
      - USER_UID=1000
      - GITEA__database__DB_TYPE=sqlite3
    restart: always
    volumes:
      - ./gitea:/data
    ports:
      - "3000:3000"
      - "2222:22"
```

---

## 8.10.3 Decentralized Git

**Radicle** เป็น P2P git hosting ที่:

- ไม่ต้องพึ่ง server กลาง
- ใช้ public-key cryptography ในการระบุตัวตน
- Replicate ระหว่าง peer แบบ peer-to-peer

เหมาะกับโครงการที่ต้องการ decentralization สูง

---

## 8.10.4 GUI Client

- **GitKraken** – cross-platform, UI สวย
- **Sourcetree** – Atlassian, Windows/macOS
- **GitHub Desktop** – Windows/macOS, simple
- **Fork** – Windows/macOS, fast, paid
- **Lazygit** – TUI, vim-like keybind
- **Tig** – TUI light-weight

---

## Lazygit - TUI ที่นิยม

```bash
# ติดตั้ง Lazygit
sudo pacman -S lazygit            # Arch
brew install lazygit              # macOS
sudo dnf copr enable atim/lazygit  # Fedora

# ใช้งาน
cd repo && lazygit
```

เหมาะกับคนที่ทำงานบน terminal และต้องการความเร็ว

---

## 8.10.5 Git Hooks

**Hook** = script ที่ Git รันอัตโนมัติเมื่อเกิด event ใน repo (เก็บใน `.git/hooks/`)

```bash
ls .git/hooks/
# pre-commit.sample
# commit-msg.sample
# pre-push.sample
# prepare-commit-msg.sample
# post-update.sample
```

---

## pre-commit Hook - ตัวอย่าง

```bash
#!/usr/bin/env bash
# .git/hooks/pre-commit
set -e

files=$(git diff --cached --name-only --diff-filter=ACM \
        | grep -E '\.py$' || true)
[ -z "$files" ] && exit 0

echo "Running ruff..."
echo "$files" | xargs ruff check

# ทำให้ executable
chmod +x .git/hooks/pre-commit
```

---

## 8.10.6 pre-commit framework

**pre-commit** (pre-commit.com) = framework ของ Python ที่บริหาร hook ผ่าน YAML

```yaml
# .pre-commit-config.yaml
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.6.0
    hooks:
      - id: trailing-whitespace
      - id: end-of-file-fixer
      - id: check-yaml
```

---

## pre-commit - ใช้งาน

```bash
# ติดตั้ง
pip install pre-commit
pre-commit install         # ติดตั้ง hook

# รันทันทีทุกไฟล์
pre-commit run --all-files

# อัพเดต rev
pre-commit autoupdate
```

ข้อดี: แชร์ config กับทีมง่ายกว่า hook ใน `.git/hooks/`

---

# 8.11
# Advanced
# Git

---

## 8.11.1 Submodule

ฝัง repo อีกตัวภายใน repo หลัก โดยเก็บเป็น pointer

```bash
# เพิ่ม submodule
git submodule add https://github.com/lib/awesome.git external/awesome
git commit -m "chore: add awesome lib"

# Clone repo ที่มี submodule
git clone --recurse-submodules https://github.com/me/myapp.git

# อัปเดต submodule
git submodule update --remote --merge
```

---

## ลบ Submodule

```bash
git submodule deinit -f external/awesome
git rm -f external/awesome
rm -rf .git/modules/external/awesome
```

**ข้อเสีย:** complex ต้องจำคำสั่ง `--recurse-submodules` ตลอด

---

## 8.11.1 Subtree

ฝัง repo อีกตัว โดยเก็บไฟล์รวมในเดียวกัน

```bash
# เพิ่ม subtree
git subtree add --prefix=external/awesome \
    https://github.com/lib/awesome.git main --squash

# Pull update
git subtree pull --prefix=external/awesome \
    https://github.com/lib/awesome.git main --squash
```

---

## Submodule vs Subtree

| คุณสมบัติ | Submodule | Subtree |
| --- | --- | --- |
| ขนาด repo | เล็ก | ใหญ่ |
| Clone | ต้อง --recurse | ไม่ต้องคิด |
| Update | submodule update | subtree pull |
| Learning curve | สูง | ปานกลาง |

---

## 8.11.2 Git LFS

สำหรับไฟล์ binary ขนาดใหญ่ (รูป, video, model AI)

```bash
# ติดตั้ง
sudo apt install git-lfs        # Debian/Ubuntu
brew install git-lfs            # macOS
sudo pacman -S git-lfs          # Arch

# Initialize
git lfs install

# Track ไฟล์
git lfs track "*.psd"
git lfs track "models/*.pt"
```

---

## Git LFS - ใช้งาน

```bash
# .gitattributes ถูกอัปเดตอัตโนมัติ
git add .gitattributes
git add big-file.psd
git commit -m "feat: add design source"

# ดูไฟล์ LFS
git lfs ls-files
git lfs status
```

---

## 8.11.3 git worktree

ทำงานหลาย branch พร้อมกันโดยไม่ต้อง stash/switch

```bash
# สร้าง worktree
git worktree add ../hotfix hotfix/v1.2

# สร้างพร้อม branch ใหม่
git worktree add -b feature/x ../feature-x main

# ดู worktree ทั้งหมด
git worktree list

# ลบ worktree
git worktree remove ../hotfix
```

---

## Worktree - Use Case

กำลังทำ feature ใหญ่บน branch หนึ่ง ขณะ production มีบั๊กด่วน

→ สร้าง worktree ของ hotfix branch ในอีกโฟลเดอร์

→ เปิด terminal/editor 2 หน้าต่าง ทำงานพร้อมกัน

ไม่ต้อง stash, ไม่ต้อง switch ไปมา

---

## 8.11.4 git bisect

หา commit ที่ทำให้บั๊กเกิดด้วย **binary search**

**ตัวอย่าง:** 1024 commit ใช้แค่ 10 ครั้งทดสอบ

---

## git bisect - ใช้งาน

```bash
# เริ่ม bisect
git bisect start

# บอกว่า HEAD บั๊ก
git bisect bad

# บอก commit ที่รู้ว่ายังดี
git bisect good v1.0

# ทดสอบแล้วบอกผล
git bisect good    # ถ้าดี
git bisect bad     # ถ้าบั๊ก
git bisect skip    # ถ้า build ไม่ผ่าน

# จบ
git bisect reset
```

---

## git bisect - Automate

```bash
# Automate ด้วย script
# script return: 0=good, 1=bad, 125=skip
git bisect start HEAD v1.0
git bisect run ./test.sh
```

Git จะหา bad commit อัตโนมัติโดยรัน script ที่แต่ละ step

---

## 8.11.5 Signed Commit - GPG

ลงนาม commit ด้วย key เพื่อยืนยันตัวตน

```bash
# สร้าง GPG key
gpg --full-generate-key
gpg --list-secret-keys --keyid-format=long

# ตั้งค่า Git
git config --global user.signingkey YOUR_KEY_ID
git config --global commit.gpgsign true

# Sign
git commit -S -m "signed commit"
git tag -s v1.0 -m "signed tag"
```

---

## Signed Commit - SSH (Git 2.34+)

ง่ายกว่า GPG เพราะใช้ SSH key ที่มีอยู่แล้ว

```bash
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true

# ตรวจสอบ signature
git log --show-signature
git verify-commit HEAD
```

อัพโหลด public key ไป GitHub/GitLab เพื่อ "Verified" badge

---

## 8.11.6 git blame

หาว่าใครแก้บรรทัดไหน เมื่อไร

```bash
# blame ทั้งไฟล์
git blame src/app.py

# blame เฉพาะบรรทัด 10-20
git blame -L 10,20 src/app.py

# blame หา function
git blame -L :function_name src/app.py

# ละเว้น whitespace change
git blame -w src/app.py
```

---

## git blame - ขั้นสูง

```bash
# ติดตามผ่าน rename
git blame -C -C src/app.py

# ละเว้น commit reformat
git config --global blame.ignoreRevsFile .git-blame-ignore-revs
echo "abc1234567890" > .git-blame-ignore-revs
```

ช่วยให้เห็น original commit แม้ผ่าน reformat code

---

## 8.11.7 git clean

ลบไฟล์ untracked

```bash
# Dry run (แค่แสดง ไม่ลบ)
git clean -n

# ลบไฟล์ untracked
git clean -f

# ลบทั้งไฟล์ + folder
git clean -fd

# รวมที่อยู่ใน .gitignore
git clean -fdx

# Interactive
git clean -i
```

---

## 8.11.7 git gc

Garbage collection - รวม loose objects เป็น pack file

```bash
# รัน gc ปกติ
git gc

# Aggressive (ใช้เวลานาน แต่บีบอัดดีกว่า)
git gc --aggressive --prune=now

# ดูขนาด repo
git count-objects -vH

# Verify integrity
git fsck --full
```

---

## ตัวอย่าง Workflow ครบวงจร

```bash
# 1. เริ่ม feature ใหม่
git switch main
git pull --rebase origin main
git switch -c feature/user-profile

# 2. ทำงาน + commit
git add user.py
git commit -m "feat(user): add user model"

# 3. จัดระเบียบ commit
git rebase -i HEAD~2
```

---

## Workflow - ต่อ

```bash
# 4. Sync กับ main แล้ว push
git fetch origin
git rebase origin/main
git push -u origin feature/user-profile

# 5. เปิด PR
gh pr create --title "feat: add user profile"

# 6. หลัง merge → tag release
git tag -a v1.2.0 -m "Release: User Profile"
git push origin v1.2.0
gh release create v1.2.0 --generate-notes
```

---

# 8.12
# สรุปท้ายบท
# (Chapter Summary)

---

## ประเด็นหลักที่ควรจดจำ

1. **Git เป็น Distributed VCS** – ทุก clone คือ full backup
2. **Three Trees Model** – Working Dir → Staging → Repository
3. **Branch ใน Git คือ pointer** ไม่ใช่สำเนา
4. **Merge vs Rebase** มีบทบาทต่างกัน
5. **Workflow ขึ้นกับบริบทของทีม**

---

## ประเด็นหลัก (ต่อ)

6. **Pull Request เป็นมากกว่าเครื่องมือ merge** – เป็นพื้นที่ Code Review
7. **History Management** (`reset`, `revert`, `reflog`, rebase, stash) – กู้สถานการณ์
8. **เครื่องมือเสริม** เช่น pre-commit hook, signed commit, Git LFS, worktree – ยกระดับคุณภาพ

---

## Mental Model ของ Git

<pre class="mermaid">
%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#3c3836', 'primaryTextColor':'#ebdbb2', 'primaryBorderColor':'#928374', 'lineColor':'#a89984', 'background':'#282828'}}}%%
mindmap
  root((Git))
    Local
      Working Dir
      Staging
      Repository
      Stash
    History
      Commit DAG
      Branches
      Tags
      Reflog
    Collaboration
      Remote
      Pull Request
      Fork
    Workflow
      GitHub Flow
      Git Flow
      Trunk-based
    Advanced
      Submodule
      Worktree
      Bisect
      LFS
</pre>

---

## Best Practices (1/3)

- **Commit เล็กและบ่อย** ใช้ Conventional Commits
- **Pull ด้วย rebase** เป็นพฤติกรรมเริ่มต้น (`pull.rebase=true`)
- **อย่า commit secret** ลง repo เด็ดขาด – ใช้ `.gitignore`, `.env`, secret manager

ใช้ tool เช่น `gitleaks`, `trufflehog` เพื่อ scan

---

## Best Practices (2/3)

- **เปิด pre-commit hook** – ทำ lint/format/test อัตโนมัติ
- **ใช้ SSH key + signed commit** – ปลอดภัยและ verifiable
- **อย่า force push** บน shared branch
- ถ้าจำเป็น ใช้ `--force-with-lease` แทน `--force`

---

## Best Practices (3/3)

- **เรียนรู้ git reflog** – ตาข่ายช่วยชีวิตเมื่อ reset ผิด
- **เขียน CONTRIBUTING.md และ CODEOWNERS** สำหรับโครงการเปิด

> Git เป็นเครื่องมือที่เรียนรู้ได้ตลอดชีวิต — เริ่มจาก 10 คำสั่งพื้นฐาน แล้วค่อย ๆ ขยับไปสู่ workflow ที่ซับซ้อนขึ้น

---

## ตารางสรุปคำสั่ง (1/2)

| หมวด | คำสั่ง |
| --- | --- |
| Setup | `init`, `clone`, `config` |
| Snapshot | `status`, `add`, `commit`, `restore` |
| History | `log`, `diff`, `blame`, `reflog` |
| Branch | `branch`, `switch`, `checkout` |
| Merge | `merge`, `rebase`, `cherry-pick` |

---

## ตารางสรุปคำสั่ง (2/2)

| หมวด | คำสั่ง |
| --- | --- |
| Remote | `remote`, `fetch`, `pull`, `push` |
| Undo | `reset`, `revert`, `stash` |
| Tag | `tag`, `describe` |
| Advanced | `worktree`, `bisect`, `submodule`, `lfs` |

---

## เส้นทางการเรียนรู้ต่อ

1. **CI/CD Pipeline** – GitHub Actions, GitLab CI/CD, Jenkins
2. **Container & Deployment** – Docker, Kubernetes (บทที่ 11)
3. **Code Review Culture** – conventional comments
4. **Monorepo Tools** – Nx, Turborepo, Bazel
5. **Git Internals** – blob, tree, commit, tag, pack file, plumbing commands

---

## คำสุดท้าย

> Git เป็นเครื่องมือที่เรียนรู้ได้ตลอดชีวิต
>
> เริ่มจาก **10 คำสั่งพื้นฐาน**: init, clone, status, add, commit, push, pull, branch, switch, log
>
> ผู้พัฒนาที่ใช้ Git อย่างเชี่ยวชาญจะมี **ความมั่นใจในการทดลอง** เพราะรู้ว่าทุกการเปลี่ยนแปลงสามารถย้อนกลับได้เสมอ

---

# คำถาม - ข้อสงสัย
<img src="/revealjs/pics/os.png" width="55%" />