Bài 1: Đọc Hiểu Git Graph - Chiếc "Bản Đồ" Sống Của Lập Trình Viên

Có bao giờ bạn rơi vào tình huống: Muốn gộp nhánh nhưng sợ mất code, lỡ tay bấm nhầm lệnh khiến commit "bay màu", hoặc nhìn vào lịch sử dự án thấy một đống đường xanh đỏ giao nhau như mạng nhện mà không hiểu gì?

Phần lớn dev chúng ta bắt đầu học Git bằng cách học thuộc lòng các câu lệnh: git add, git commit, git push. Nhưng khi dự án phình to, cách làm đó sẽ khiến bạn "đuối". Để làm chủ Git, bạn cần ngừng nhìn nó như một danh sách các câu lệnh, mà hãy nhìn nó như một Đồ thị (Graph). Hôm nay, chúng ta sẽ cùng học cách đọc chiếc bản đồ này.

1. Bản chất của Git: Đồ thị có hướng không chu trình (DAG)

Đằng sau lớp vỏ bọc của các dòng lệnh, Git quản lý lịch sử code của bạn bằng một cấu trúc dữ liệu gọi là DAG (Directed Acyclic Graph).

• Nodes (Các nút): Chính là các Commit của bạn. Mỗi commit là một ảnh chụp (snapshot) toàn bộ dự án tại một thời điểm.
• Edges (Các cạnh/mũi tên): Là mối liên kết giữa các commit. Có một sự thật ngược đời: Mũi tên trong Git luôn chỉ ngược về quá khứ. Commit mới sẽ có một mũi tên chỉ về commit cha (Parent Commit) của nó. Điều này giúp Git biết được vị trí xuất phát của đoạn code.

Khi nhiều người cùng code, đồ thị sẽ rẽ nhánh (Branching) và chập lại (Merging), tạo nên một mạng lưới đường đi mà chúng ta gọi là Git Graph.

2. Các thành phần cốt lõi trên "Tấm bản đồ" Git Graph

Để không bị lạc đường khi nhìn vào đồ thị, bạn cần phân biệt rõ 3 khái niệm thường bị đánh đồng sau:

• Commit (Nút thắt lịch sử): Là thực thể cố định. Một khi đã tạo ra, nó mang một mã băm SHA-1 duy nhất.
• Branch (Nhánh): Trong Git, Branch thực chất chỉ là một con trỏ (Pointer) có thể di chuyển được, nó dán nhãn và trỏ thẳng vào một commit cụ thể. Khi bạn commit mới trên nhánh đó, con trỏ nhánh sẽ tự động nhảy lên để bám theo commit mới nhất.
• HEAD (Vị trí hiện tại của bạn): HEAD là con trỏ của chính bạn. Nó cho biết bạn đang đứng ở đâu trên đồ thị. Thông thường, HEAD sẽ trỏ vào một Branch (ví dụ: HEAD -> main). Nếu bạn chuyển sang một commit cũ bất kỳ, HEAD sẽ tách khỏi branch và trỏ thẳng vào commit đó—đây chính là trạng thái "Detached HEAD" huyền thoại mà ai cũng từng gặp.

3. Làm sao để "thấy" được Git Graph?

Để bắt đầu làm quen, bạn có hai cách để lôi chiếc bản đồ này ra ánh sáng:

Cách 1: Dùng Terminal "Hack não" (Dành cho dân hardcore) Đừng chỉ gõ git log nhàm chán. Hãy thử câu lệnh quyền lực này trên Terminal của bạn:

git log --oneline --graph --decorate --all

Ngay lập tức, Terminal sẽ vẽ ra các đường sọc (*, |, /, ) biểu thị cho các nhánh chạy song song, các điểm giao cắt kèm theo vị trí của các con trỏ HEAD và branch.

Cách 2: Dùng Extension "Git Graph" trên VS Code (Khuyên dùng) Nếu muốn một giao diện trực quan, mượt mà và có thể click chuột để tương tác, hãy cài ngay extension Git Graph trên VS Code. Nó sẽ biến các dòng lệnh khô khan thành các đường tàu lượn siêu tốc nhiều màu sắc, giúp bạn nhìn rõ mồn một ai đã rẽ nhánh từ đâu và merge vào lúc nào.

Tóm lại là...

Mọi rắc rối về Git (conflict, mất code, lệch nhánh) đều có thể được giải thích và giải quyết một cách cực kỳ logic nếu bạn chịu mở Git Graph lên và quan sát. Hãy nhớ: Commit là nút, Branch là con trỏ, và HEAD là vị trí bạn đang đứng.

Ở bài học số 2, chúng ta sẽ dùng chính chiếc bản đồ này để giải mã hai hành động gây lú nhất trong Git: Sự khác biệt về mặt bản chất đồ thị giữa Merge (Hợp nhất) và Rebase (Tái định tiến). Khi nào nên dùng loại nào để giữ cho đồ thị luôn "sạch và đẹp"? Hãy cùng đón chờ nhé!