Bài 2: Merge vs Rebase - Trận Chiến Giữ Lại Lịch Sử Hay Làm Sạch Bản Đồ?

Trong quá trình làm việc nhóm, việc một lập trình viên rẽ nhánh ra để làm tính năng mới (Feature branch), trong khi nhánh chính (main/develop) vẫn liên tục có commit mới từ người khác là chuyện xảy ra như cơm bữa.

Đến cuối ngày, khi bạn muốn cập nhật code mới nhất từ main vào nhánh của mình, bạn đứng trước hai sự lựa chọn: git merge main hoặc git rebase main.

Nếu bạn chọn bừa theo tâm linh, Git Graph của dự án sẽ sớm biến thành một bớ bòng bong. Hãy cùng lên bàn mổ để xem đồ thị thay đổi thế nào sau hai lệnh này.

1. Git Merge: Người bảo tồn lịch sử (True History)

Khi bạn đứng ở nhánh feature và gõ git merge main, Git sẽ nhìn vào đồ thị và tìm điểm chung cuối cùng (Common Ancestor) của hai nhánh, sau đó thực hiện gộp. Sẽ có hai kịch bản xảy ra trên Graph:

• Fast-Forward (Tua nhanh): Nếu từ lúc bạn rẽ nhánh, nhánh main không hề có commit nào mới. Git sẽ không tạo thêm commit nào cả. Nó chỉ đơn giản là "cầm" con trỏ của nhánh main kéo tuột lên vị trí commit mới nhất của nhánh feature. Đồ thị lúc này vẫn là một đường thẳng tắp.
• 3-Way Merge (Hợp nhất 3 điểm): Đây mới là trường hợp phổ biến. Nếu cả main và feature đều đã có những commit mới riêng. Git sẽ tự động tạo ra một Commit gộp (Merge Commit). Commit này rất đặc biệt vì trên đồ thị, nó có tới 2 commit cha (một chỉ về main, một chỉ về feature).

Đặc điểm trên Git Graph: Nhánh feature sẽ uốn cong một đường, chạy song song với main, rồi cắm ngược đầu vào main tại điểm tạo Merge Commit. Đồ thị phản ánh chính xác 100% dòng thời gian thực tế: Ai đã làm gì, vào lúc nào, rẽ nhánh từ đâu.

2. Git Rebase: Kẻ viết lại lịch sử (Linear History)

"Re-base" hiểu thô thiển là "Đặt lại gốc". Thay vì tạo một commit gộp để nối 2 nhánh lại với nhau, git rebase main sẽ làm một việc mang tính "hắc ám" hơn:

1. Git tạm thời nhấc toàn bộ các commit mới của nhánh feature ra một vùng nhớ tạm.
2. Nó dịch chuyển gốc rẽ nhánh của feature tiến lên vị trí commit mới nhất của main.
3. Nó lấy các commit trong vùng nhớ tạm xếp chồng lên trên đỉnh mới của main.

Bản chất của hành động này là Xóa bỏ các commit cũ và tạo ra các commit hoàn toàn mới (mang mã băm SHA-1 mới) nối tiếp vào đuôi của main.

Đặc điểm trên Git Graph: Đồ thị của bạn sạch sẽ một cách hoàn hảo! Toàn bộ lịch sử dự án biến thành một đường thẳng duy nhất không hề có đường rẽ nhánh hay các Merge Commit rác. Cảm giác như thể bạn là người duy nhất đang code trong dự án và vừa mới rẽ nhánh ra từ commit mới nhất của main vậy.

3. Lên bàn cân: Chọn "Sự thật" hay "Mỹ quan"?

Không có lệnh nào tốt hơn lệnh nào, chỉ có lệnh phù hợp với triết lý của team bạn:

4. Quy tắc vàng của Rebase (The Golden Rule)

Bởi vì Rebase bản chất là hủy hoại commit cũ và viết lại lịch sử, nên bạn tuyệt đối phải khắc cốt ghi tâm quy tắc sau:

"Không bao giờ được Rebase những commit đã được PUSH lên Public Repository (như GitHub/GitLab)."

Nếu bạn rebase trên nhánh local của riêng bạn, không sao cả. Nhưng nếu bạn rebase một nhánh mà nhiều người khác đang cùng kéo về dùng (ví dụ nhánh develop), bạn sẽ làm lệch toàn bộ gốc đồ thị của họ. Khi họ push code lên lại, một thảm họa conflict và trùng lặp commit sẽ xảy ra trên Graph.

Tóm lại là...

• Dùng Merge khi bạn muốn giữ lại lịch sử rõ ràng để sau này dễ truy vết xem tính năng đó được phát triển trong nhánh nào.
• Dùng Rebase khi bạn muốn dọn dẹp các commit local của mình trước khi tạo Pull Request để giữ cho đồ thị của cả team luôn đẹp và thẳng.

Ở bài học số 3, chúng ta sẽ đi sâu vào một kỹ năng "thượng thừa" giúp bạn sửa sai trên đồ thị: Cách sử dụng Git Cherry-pick để "bốc" chính xác một commit từ nhánh này sang nhánh khác mà không cần mang theo cả rổ code thừa. Hãy cùng đón đọc nhé!