Bỏ qua để đến nội dung

Terminal, Git, GitHub

Level: L6 — AI Coding & Vibe Coding (Bài 2/12)

Sau bài này, bạn có thể:

  • Giải thích Terminal là gì và vì sao coding agent (kể cả AI) đều thao tác qua terminal thay vì giao diện đồ họa.
  • Phân biệt rõ Git (công nghệ theo dõi thay đổi) với GitHub (nền tảng lưu trữ/cộng tác) — 2 khái niệm hay bị nhầm là một.
  • Đọc hiểu 1 lịch sử commit và biết vì sao “lưu lại từng thay đổi” quan trọng khi làm việc với AI viết code.
  • Biết chính xác phần nào của Git/GitHub bạn cần tự hiểu, phần nào có thể để AI thực hiện thay.

Terminal là giao diện dòng lệnh — nơi bạn (hoặc 1 coding agent) gõ lệnh trực tiếp thay vì bấm chuột qua các cửa sổ đồ họa. Đây là “ngôn ngữ giao tiếp” chung mà mọi coding agent (Claude Code, Codex CLI…) đều dùng để thao tác trên máy tính — hiểu terminal ở mức tối thiểu giúp bạn đọc hiểu được AI đang làm gì, thay vì thấy 1 hộp đen khó hiểu.

Gitdistributed version control system — hệ thống theo dõi thay đổi phổ biến nhất, cho phép “xem toàn bộ dòng thời gian các thay đổi, quyết định, và tiến trình của 1 dự án ở cùng 1 nơi” [S92]. Mỗi lần lưu 1 “snapshot” thay đổi gọi là 1 commit — giống như 1 điểm lưu (save point) trong game, bạn luôn có thể quay lại đúng điểm đó nếu có gì sai.

GitHub là 1 nền tảng khác — không phải là Git: “Git là công nghệ version control chạy trên máy; GitHub là nền tảng lưu trữ Git repository + công cụ cộng tác (issues, pull requests, code review)” [S92]. Ẩn dụ dễ nhớ: Git giống như “viết nhật ký”; GitHub giống như “đăng nhật ký đó lên 1 trang web để người khác đọc/góp ý cùng.”

4 khái niệm cốt lõi (đủ dùng ở mức nền tảng):

  • Repository (repo) — toàn bộ file/folder của 1 dự án, cộng lịch sử chỉnh sửa từng file [S92].
  • Commit — 1 snapshot thay đổi, lưu vào lịch sử dự án [S92].
  • Branch — 1 nhánh phát triển riêng, cho phép thử thay đổi mà không ảnh hưởng ngay tới phiên bản chính [S92].
  • Remote — bản repo lưu trên GitHub, khác bản đang có trên máy bạn [S92].

Khi bạn giao việc cho 1 coding agent, nó sẽ tự động thực hiện các thao tác Git (tạo branch, commit, đôi khi cả mở pull request) — nếu bạn không hiểu tối thiểu Git là gì, bạn sẽ không đọc hiểu được AI vừa làm gì, không biết cách “quay lại điểm lưu” nếu AI làm hỏng thứ gì đó, và không phân biệt được “code trên máy bạn” với “code đã thật sự được lưu lại an toàn.”

Workflow đóng góp cơ bản (6 bước, theo đúng chuẩn công nghiệp) [S92]:

  1. Clone repository về máy (tạo bản sao local từ repo có sẵn).
  2. Tạo 1 branch riêng cho thay đổi bạn sắp làm.
  3. Sửa file, rồi git add (đánh dấu “sẵn sàng lưu” — gọi là staging).
  4. git commit (lưu snapshot, kèm 1 dòng mô tả thay đổi).
  5. Push branch đó lên GitHub.
  6. Mở pull request — nơi thay đổi được xem lại trước khi gộp vào phiên bản chính.

Phân định AI vs con người:

Điều bạn cần hiểu Điều AI có thể thực hiện Điều bạn phải xác nhận
Terminal Đây là nơi lệnh được gõ và chạy Tự gõ lệnh thay bạn Lệnh đó có làm đúng ý bạn không (đọc kết quả trả về)
Commit Mỗi commit là 1 điểm có thể quay lại Tự tạo commit với mô tả Mô tả commit có phản ánh đúng thay đổi thật không
Branch Branch giúp thử nghiệm an toàn Tự tạo/chuyển branch Đang làm việc trên đúng branch dự định, không nhầm sang branch chính
Pull request Đây là bước “xin phép” gộp thay đổi vào bản chính Tự mở pull request Bạn (hoặc người có thẩm quyền) luôn là người bấm “merge” cuối cùng

Coi Git như cuốn nhật ký công trường xây dựng — mỗi commit là 1 trang nhật ký ghi lại chính xác điều gì vừa được xây/sửa, ai làm, khi nào. GitHub là văn phòng công trường — nơi nhật ký đó được lưu trữ tập trung, và cả đội (kể cả bạn + AI) cùng xem, cùng góp ý trước khi 1 thay đổi được chính thức đưa vào công trình.

  1. Mở terminal (có sẵn trên máy tính, hoặc terminal tích hợp trong công cụ coding agent bạn dùng).
  2. Thử 3 lệnh cơ bản đã học: git init (khởi tạo 1 repo mới ngay tại thư mục hiện tại), git add . (đánh dấu toàn bộ thay đổi sẵn sàng lưu), git commit -m "mô tả ngắn" (lưu snapshot) [S92].
  3. Đọc lại lịch sử commit vừa tạo (qua lệnh git log, hoặc để coding agent tóm tắt lại giúp bạn) — xác nhận bạn hiểu commit đó ghi lại điều gì.
  4. Tạo 1 tài khoản GitHub (nếu chưa có) và thử tạo 1 repository trống — làm quen giao diện trước khi để AI thao tác thay bạn ở các bài sau.
  5. Kết nối repo local với GitHub (push lần đầu) — bước này thường được coding agent tự động hóa từ bài 57 trở đi, nhưng nên tự làm 1 lần để hiểu cơ chế.

Tình huống minh họa: bạn yêu cầu 1 coding agent thêm 1 tính năng mới vào ứng dụng. Thay vì sửa trực tiếp vào phiên bản đang chạy, agent tạo 1 branch riêng (ví dụ them-tinh-nang-luu-ghi-chu), thực hiện thay đổi, commit lại với mô tả rõ ràng, rồi báo bạn xem lại trước khi gộp vào bản chính. Nếu tính năng đó có lỗi, bạn chỉ cần không merge branch đó — phiên bản chính hoàn toàn không bị ảnh hưởng. Đây chính là giá trị thực tế của “branch” mà bạn vừa học.

[ ] Mô tả commit có nói rõ thay đổi gì không (không chỉ "update code")?
[ ] Thay đổi này có đúng phạm vi bạn yêu cầu, không lan sang phần khác?
[ ] Bạn có biết cách xem lại nội dung thay đổi cụ thể (diff) nếu cần?
Xem lại lịch sử commit gần đây trong repo này và tóm tắt bằng ngôn ngữ đơn
giản: mỗi commit đã thay đổi điều gì, theo đúng thứ tự thời gian.
mainfeature-branchmerge
Hình 6.2 — Cây branch Git: nhánh chính (main) và 1 nhánh phụ (feature-branch) tách ra rồi gộp lại (merge). [S92]
  1. Mở terminal, tạo 1 thư mục thử nghiệm, chạy git init.
  2. Tạo 1 file văn bản đơn giản, git add + git commit với mô tả rõ ràng.
  3. Sửa file đó, commit lần 2 với mô tả khác.
  4. Chạy git log — đọc lại 2 commit vừa tạo, xác nhận bạn hiểu đúng thứ tự và nội dung.
  5. Tạo 1 repository trên GitHub, push thư mục thử nghiệm lên đó.
  • Nhầm Git và GitHub là 1 thứ — dẫn tới nhầm lẫn khi đọc tài liệu/lỗi.
  • Không đọc mô tả commit của AI — bỏ lỡ cơ hội phát hiện sớm nếu AI làm sai phạm vi yêu cầu.
  • Làm việc trực tiếp trên nhánh chính (main) thay vì tạo branch riêng — rủi ro cao nếu có lỗi, không có “điểm lùi” an toàn.
  • Coi terminal là thứ đáng sợ, bỏ qua không học — mất khả năng tự kiểm tra khi coding agent báo lỗi hoặc hành xử bất thường.

13. Giới hạn & khi nào KHÔNG nên áp dụng

Phần tiêu đề “13. Giới hạn & khi nào KHÔNG nên áp dụng”
  • Bài này không dạy hết mọi lệnh Git (merge conflict phức tạp, rebase, cấu hình nâng cao) — chỉ đủ để đọc hiểu và giám sát 1 coding agent, không phải để trở thành chuyên gia Git.
  • Không cần thiết phải tự gõ lệnh terminal thường xuyên sau khi đã quen — từ bài 57 trở đi, phần lớn thao tác này coding agent sẽ tự làm; mục tiêu của bài 54 là hiểu, không phải tự tay làm mãi mãi.

Không bao giờ commit/push thông tin nhạy cảm (mật khẩu, API key, dữ liệu cá nhân) lên GitHub, kể cả trong 1 repository riêng tư — lịch sử Git ghi nhớ vĩnh viễn mọi commit, kể cả khi bạn xóa file đó ở commit sau, thông tin vẫn còn trong lịch sử trừ khi xử lý kỹ thuật đặc biệt. Nguyên tắc thực dụng: kiểm tra lại nội dung mỗi commit AI tạo ra trước khi push, đặc biệt ở giai đoạn đầu khi bạn chưa quen giám sát AI.

  1. Luôn viết/yêu cầu AI viết mô tả commit rõ ràng, cụ thể — không chấp nhận mô tả mơ hồ kiểu “update” hay “fix”.
  2. Tạo branch riêng cho mỗi thay đổi/tính năng, không làm trực tiếp trên nhánh chính.
  3. Định kỳ (đặc biệt sau khi AI hoàn thành 1 việc) chạy git log hoặc nhờ AI tóm tắt lại lịch sử — giữ thói quen giám sát.
16. Nội dung nâng cao (không bắt buộc)

Từ bài 57 trở đi, phần lớn workflow Git ở mục 4 sẽ được 1 coding agent tự động hóa hoàn toàn (tự tạo branch, tự commit, đôi khi tự mở pull request). Kiến thức nền tảng học ở bài này chính là điều kiện để bạn giám sát quá trình tự động đó một cách có ý nghĩa, thay vì chỉ nhìn AI làm việc mà không hiểu gì.

[S92] About Git, GitHub (Microsoft) (docs.github.com) — định nghĩa Git/GitHub, 4 khái niệm cốt lõi, workflow 6 bước, 4 lệnh nền tảng.

Claim kỹ thuật kiểm chứng qua nguồn Tier 1 (S92) ngày 2026-07-12. Git/GitHub là công nghệ tương đối ổn định — rủi ro lỗi thời thấp so với các bài khác của Level 6.