Hãy tưởng tượng một tình huống oái oăm: Đồng nghiệp của bạn đang phát triển một tính năng rất lớn trên nhánh feature-X. Nhánh này có tới 20 commit và hiện tại code vẫn chưa chạy được hoàn chỉnh. Tuy nhiên, trong số 20 commit đó, có đúng 1 commit duy nhất chứa đoạn code fix lỗi bảo mật cực kỳ quan trọng mà bạn đang rất cần cho nhánh main để deploy gấp lên Production.
Bạn không thể dùng git merge vì sẽ kéo theo cả 19 commit lỗi kia vào main. Bạn cũng không thể dùng git rebase vì sẽ làm đảo lộn cả nhánh tính năng của đồng nghiệp.
Lúc này, Git Cherry-pick xuất hiện như một vị cứu tinh.
1. Bản chất của Git Cherry-pick trên Đồ thị
Hiểu một cách đơn giản, git cherry-pick <commit-hash> là hành động: Sao chép nội dung của một commit cụ thể từ một nhánh bất kỳ, rồi áp dụng (apply) nó vào vị trí HEAD hiện tại của bạn để tạo ra một commit hoàn toàn mới.
Hãy quan sát sự thay đổi trên Git Graph trước và sau khi chạy lệnh:
Trước khi Cherry-pick:
Nhánh feature của đồng nghiệp đang có commit C3 (chứa đoạn code fix lỗi) mà bạn đang thèm khát. Bạn thì đang đứng ở đỉnh của nhánh main (commit M2).
main : M1 --- M2 (HEAD)
\
feature : C1 --- C2 --- C3 (Fix lỗi) --- C4
Sau khi gõ lệnh git cherry-pick C3:
main : M1 --- M2 --- C3' (HEAD)
\
feature : C1 --- C2 --- C3 --- C4
Điều gì vừa xảy ra trên Git Graph?
- Một nút mới tên là C3' được sinh ra ngay sau M2.
- Commit C3 gốc bên nhánh feature vẫn nằm im tại chỗ, không hề bị suy suyển.
- Lưu ý chí tử: C3' là một bản sao. Dù nội dung code giống hệt C3, nhưng nó sở hữu một mã băm SHA-1 hoàn toàn mới và mốc thời gian mới. Trên đồ thị, không có bất kỳ đường nối nào giữa nhánh main và nhánh feature cả. Hai nhánh vẫn là hai đường thẳng song song biệt lập.
2. Những kịch bản "Vàng" để dùng Cherry-pick
Trong thực tế vận hành dự án, Cherry-pick thường được các Tech Lead hoặc DevOps trưng dụng trong các trường hợp sau:
- Hotfix khẩn cấp: Bạn fix một lỗi nghiêm trọng trên nhánh develop, nhưng khách hàng yêu cầu phải có bản sửa lỗi đó trên nhánh production ngay lập tức mà không muốn đem theo các tính năng mới chưa test xong trên develop.
- Khôi phục code từ nhánh bị bỏ hoang (Abandoned Branch): Đôi khi team quyết định hủy bỏ một tính năng lớn vì khách hàng đổi ý. Nhánh đó bị bỏ hoang. Tuy nhiên, trong đó có một vài đoạn code xử lý logic hoặc giao diện rất đẹp có thể tái sử dụng cho task hiện tại của bạn. Bạn chỉ cần mở Git Graph lên, tìm mã commit đó và "hái" nó về.
- Vô tình commit nhầm nhánh: Bạn đang hì hục code task A nhưng quên không check-out sang nhánh mới, dẫn đến việc commit thẳng vào nhánh main. Đừng hoảng hốt! Hãy chuyển sang nhánh đúng, cherry-pick cái commit đó qua, rồi quay lại nhánh main dùng git reset để xóa nó đi là xong.
3. Mặt tối của Cherry-pick: "Quả táo độc" trên đồ thị
Cherry-pick rất tiện, nhưng nếu lạm dụng, bạn sẽ phải trả giá đắt.
- Thảm họa Duplicate Commits: Vì C3' và C3 là hai commit độc lập có nội dung giống nhau, nên sau này nếu bạn quyết định merge nhánh feature vào main, Git sẽ phải bối rối xử lý lại đoạn code đó một lần nữa.
- Xáo trộn ngữ cảnh (Context Shift): Nếu commit C3 của đồng nghiệp có sử dụng một hàm hoặc một thư viện được định nghĩa ở commit C2, khi bạn chỉ bốc mỗi C3 về nhánh của mình, code của bạn chắc chắn sẽ bị lỗi biên dịch (Compile Error) vì thiếu đi phần nền tảng ở C2.
Tóm lại là...
Git Cherry-pick là một công cụ phẫu thuật chính xác cao. Nó chỉ nên được dùng khi bạn thực sự hiểu rõ cấu trúc code của commit đó và không có nhu cầu gộp toàn bộ nhánh. Hãy nhớ: Cherry-pick tạo ra bản sao, không tạo ra đường nối lịch sử trên đồ thị.
Ở bài học số 4, chúng ta sẽ cùng nhau học cách "thu dọn tàn cuộc" và làm sạch đồ thị bằng một kỹ năng nâng cao: Cách sử dụng Interactive Rebase (git rebase -i) để gộp nhiều commit rác (Squash) thành một commit duy nhất trước khi push. Lịch sử dự án của bạn nhìn sẽ chuyên nghiệp hơn rất nhiều!
