Git สำหรับระบบงานข้อมูลและทีมพัฒนา

ทฤษฎีและกลไกการทำงาน (How it works): Git ไม่ได้เก็บความเปลี่ยนแปลงแบบประวัติส่วนต่างของไฟล์รายบรรทัด (Delta-based) แต่จัดเก็บข้อมูลในรูปสแนปช็อต (Snapshots) ทั้งระบบผ่านโครงสร้างข้อมูลแบบกราฟทิศทางไม่มีวัฏจักร หรือ Directed Acyclic Graph (DAG) ออบเจกต์ภายในของ Git จะถูกบันทึกไว้ในไดเรกทอรี `.git/objects/` โดยเข้ารหัสแฮชแบบ SHA-1 และแบ่งออกเป็น 4 รูปแบบหลัก: 1. **Blob**: จัดเก็บเนื้อหาไฟล์ดิบหลังจากทำการบีบอัดด้วยอัลกอริทึม zlib โดยจะไม่บันทึกชื่อไฟล์และสิทธิ์การเข้าถึงใดๆ 2. **Tree**: ทำหน้าที่เสมือนโฟลเดอร์ เก็บรายการสิทธิ์ (Permissions), ชนิดของข้อมูล (Blob หรือ Tree ย่อย), แฮช SHA-1 และชื่อไฟล์จริง 3. **Commit**: เก็บข้อมูล Metadata ได้แก่ ชื่อผู้เขียน, ผู้ตรวจสอบ, วันที่บันทึก, พอยน์เตอร์ชี้ไปยัง Tree หลัก และแฮชของคอมมิตต้นตระกูล (Parent Commits) 4. **Tag**: ออบเจกต์ชี้ตำแหน่งคอมมิตอย่างถาวรเพื่อใช้อ้างอิงเวอร์ชันจำลอง

# Inspecting low-level Git object database directly
# 1. Compute SHA-1 hash of a string and write to Git object database
echo "pipeline_id: spark_elt_01" | git hash-object -w --stdin

# 2. Retrieve object type and content using the generated hash (e.g. 8d3d92...)
git cat-file -t 8d3d92
git cat-file -p 8d3d92
                    

Use Case ในชีวิตจริง (Real-world Scenario): เมื่อเกิดปัญหารหัสโมเดลการประมวลผลข้อมูลใน dbt เสียหายหลังการรวมกิ่ง วิศวกรข้อมูลสามารถใช้คำสั่งล่างระบบ (Plumbing Commands) เช่น `git cat-file` เพื่อย้อนดูข้อมูลในออบเจกต์ Tree และ Commit ของพ่อแม่ ทำให้สามารถตรวจสอบความสัมพันธ์เชิงลำดับของ DAG ได้อย่างอิสระโดยไม่ต้องสลับสาขาโค้ด

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ปัญหา Repository Bloat หรือพื้นที่เก็บมีขนาดบวมโตอย่างรวดเร็ว เกิดจากวิศวกรเผลอคอมมิตไฟล์ข้อมูลดิบ (เช่น `.csv`, `.json` ขนาดเกิน 100MB) ลงในฐานข้อมูล Git แก้ไขโดยติดตั้งโปรแกรมลบประวัติแบบถาวรอย่าง `git-filter-repo` หรือ `BFG Repo-Cleaner` ร่วมกับการเขียนระบุชนิดไฟล์ห้ามติดตามลงในไฟล์ `.gitignore` ก่อนเริ่มโครงการ

ทฤษฎีและกลไกการทำงาน (How it works): การแบ่งปันงานและการจัดการรหัสโครงการขนาดใหญ่แบ่งออกเป็น 2 แนวคิดหลัก: - **Feature Branching (Gitflow)**: นักพัฒนาแยกกิ่งพัฒนา (Feature Branches) ยาวนาน รวบรวมงานส่งผ่านการตรวจสอบรหัส (Pull Requests) เหมาะสำหรับโปรเจกต์ที่มีความเสี่ยงสูงและต้องการระบบอนุมัติหลายชั้น - **Trunk-Based Development**: นักพัฒนาทุกคนส่งรหัสการแก้ไขตรงเข้าสู่สาขาหลัก (main หรือ trunk) ตลอดเวลา หรือผ่านสาขาที่มีอายุน้อยกว่า 24 ชั่วโมง โดยพึ่งพาระบบการตรวจสอบคุณภาพด้วย Automated Testing (CI/CD) เป็นเกณฑ์กั้นการทำงาน

# Configuration variable toggling in Python to support Trunk-Based release
import os

# Use Environment Variables / Feature Flags to isolate incomplete features in Main branch
RUN_NEW_INGESTION_MODEL = os.getenv("FEATURE_NEW_INGESTION", "False") == "True"

def run_pipeline():
    if RUN_NEW_INGESTION_MODEL:
        # Code from new trunk commit (experimental)
        print("Running experimental high-performance polars ingestion.")
    else:
        # Stable legacy pipeline
        print("Running legacy pandas ingestion.")
                    

Use Case ในชีวิตจริง (Real-world Scenario): ทีมผู้สร้างคลังข้อมูลระดับร้อยคนนำระบบ Trunk-Based Development มาใช้ร่วมกับระบบตรวจสอบรหัสอัตโนมัติ เพื่อเลี่ยงปัญหาการขัดแย้งของโค้ดขนาดใหญ่ (Merge Conflicts) ที่มักเกิดขึ้นตอนปลายสัปดาห์ ส่งผลให้ลดระยะเวลาจัดส่งฟีเจอร์แปลงข้อมูลขึ้นระบบงานจริงได้รวดเร็วขึ้น

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): ความเสี่ยงสูงสุดของ Trunk-Based Development คือการที่รหัสบั๊กหลุดไปถึงผู้ใช้บริการหากไม่มีการควบคุมอย่างรัดกุม แก้ไขโดยการเปิดระบบปกป้องสาขาหลัก (Branch Protection Rules) ห้ามดันตรงโดยไม่มีการตรวจสอบ และสร้างระบบทดสอบแบบแยกสภาพแวดล้อมชั่วคราว (Ephemeral environments) เพื่อประเมินผลรันข้อมูลก่อนทำการรวมกิ่งเสมอ

ทฤษฎีและกลไกการทำงาน (How it works): Git มีชุดเครื่องมือสำหรับเขียนประวัติคอมมิตย้อนหลังใหม่เพื่อให้ประวัติโครงการเป็นระเบียบเรียบร้อยก่อนแชร์ให้ผู้อื่น: - **Interactive Rebase (`git rebase -i`)**: เปิดโปรแกรมข้อความเพื่อเข้าไปจัดการคอมมิตย้อนหลังตามระบุ เช่น การเปลี่ยนคำคอมมิต (reword), การลบ (drop), การย้ายลำดับ หรือการควบรวม - **Squash**: การยุบคอมมิตย่อยหลายตัวที่อยู่ติดกัน ให้หลอมรวมเป็นคอมมิตเดียว - **Amend (`git commit --amend`)**: การแทรกสอดการเปลี่ยนรูปไฟล์ล่าสุดลงในคอมมิตปัจจุบัน ช่วยหลีกเลี่ยงการเพิ่มคอมมิตเล็กน้อยที่ไม่จำเป็น

# Interactive rebase process for local cleanup before merge
# 1. Start interactive rebase for last 4 commits
git rebase -i HEAD~4

# 2. Git opens text editor. Modify list like this:
# pick a3c561f feat: add partition config to minio sink
# squash c4d291e tmp: add temp logging
# squash e912a3d fix: resolve snaphshot metadata error
# reword f512cba feat: finalize iceberg table partition script

# 3. Save, resolve conflict if any, then push using lease protection
git push origin feature/iceberg-sync --force-with-lease
                    

Use Case ในชีวิตจริง (Real-world Scenario): ก่อนที่วิศวกรข้อมูลจะผสานรวมกิ่งโปรเจกต์ SQL dbt ไปยังสาขา `main` เขาได้ทำการรัน `git rebase -i` เพื่อรวมคอมมิตขยะอย่าง "try fixing typo" หรือ "re-run check" ทั้งหมดให้หลอมรวมเป็นคอมมิตที่ดูเป็นมืออาชีพเพียงตัวเดียว เพื่อความคลีนในการตรวจสอบย้อนหลัง

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): การเขียนประวัติใหม่จะเปลี่ยนค่าแฮชคอมมิตทั้งหมด หากรันคำสั่งแก้ไขบนประวัติที่แชร์กับนักพัฒนาคนอื่นแล้ว จะส่งผลให้ Git กราฟเสียหายและสับสนอย่างรุนแรง แก้ไขโดยห้ามทำ Rebase/Amend บนสาขาแชร์ภายนอกเด็ดขาด และใช้คำสั่ง `git push --force-with-lease` แทน `--force` เสมอ เพื่อป้องกันการเผลอไปเขียนทับรหัสที่สมาชิกดันขึ้นมาใหม่

ทฤษฎีและกลไกการทำงาน (How it works): Git Hooks คือชุดโปรแกรมต้นแบบที่รันอัตโนมัติเมื่อเกิดเหตุการณ์สำคัญในโปรเซสของ Git (เช่น ก่อนการส่งบันทึก `pre-commit` หรือก่อนดันโค้ดขึ้นระบบ `pre-push`) โดยไฟล์เหล่านี้จะเก็บอยู่ในโฟลเดอร์ซ่อน `.git/hooks/` วิศวกรข้อมูลนิยมประยุกต์ใช้เฟรมเวิร์ก **pre-commit** เพื่อคุมมาตรฐานรหัสผ่านการรันเครื่องมือประเมินคุณภาพ โดยจะสกัดไฟล์เฉพาะบรรทัดที่เปลี่ยนแปลงไปสแกน ทำให้ประหยัดเวลารันโปรแกรมทดสอบ

# Production-ready .pre-commit-config.yaml configuration schema
repos:
  - repo: https://github.com/pre-commit/pre-commit-hooks
    rev: v4.4.0
    hooks:
      - id: check-yaml
      - id: end-of-file-fixer
      - id: check-added-large-files
        args: ['--maxkb=500']
  - repo: https://github.com/sqlfluff/sqlfluff
    rev: 2.1.2
    hooks:
      - id: sqlfluff-lint
        additional_dependencies: ['sqlfluff-templater-dbt']
  - repo: https://github.com/Yelp/detect-secrets
    rev: v1.4.0
    hooks:
      - id: detect-secrets
        args: ['--baseline', '.secrets.baseline']
                    

Use Case ในชีวิตจริง (Real-world Scenario): สถาบันการเงินบังคับให้วิศวกรข้อมูลรัน pre-commit hooks ทุกครั้ง โดยหากโปรแกรมตรวจจับพบรหัสลับ (Database Credentials, Cloud Access Keys) ในโค้ดหรือการเขียนสคริปต์ SQL ที่ไม่มีการจัดรูปแบบตามมาตรฐาน SQLFluff ตัว Git จะป้องกันและขัดขวางไม่ให้มีการบันทึกคอมมิต

ข้อควรระวังและวิธีแก้ (Pitfalls & Mitigations): นักพัฒนาอาจใช้พารามิเตอร์ `git commit --no-verify` เพื่อเลี่ยงการรันตรวจสอบความปลอดภัย ส่งผลให้รหัสที่มีจุดอ่อนรั่วไหลขึ้นระบบ แก้ไขโดยการเซ็ตอัประบบตรวจสอบความปลอดภัยซ้ำอีกเลเยอร์หนึ่งที่ฝั่งผู้ให้บริการคลาวด์ ผ่านโปรแกรมจำลอง CI/CD (เช่น GitHub Actions, GitLab CI) เพื่อทำการปฏิเสธรหัสที่ไม่ผ่านมาตรฐานตั้งแต่ชั้นแรก