Cherry-pick: nó là gì, cách thực hiện và lệnh Git

Cherry-pick trong Git là gì

Cherry-pick là lệnh git cherry-pick lấy các thay đổi từ một commit hiện có và áp dụng chúng như một commit mới trong nhánh hiện tại. Commit gốc vẫn ở nguyên vị trí trong nhánh của nó, trong khi một bản sao của các thay đổi được tạo trong nhánh đích. Lệnh này hữu ích khi bạn cần chuyển một bản sửa lỗi cụ thể mà không di chuyển toàn bộ nhánh.

Cú pháp: git cherry-pick <commit-hash>. Git phân tích sự khác biệt (diff) của commit được chỉ định so với commit cha của nó và áp dụng sự khác biệt đó vào nhánh hiện tại. Nếu nhiều tệp được thay đổi, tất cả đều được chuyển cùng nhau. Lệnh cũng chấp nhận phạm vi: git cherry-pick A..B — tất cả các commit từ A đến B, không bao gồm A.

Các cờ mở rộng khả năng: -n (--no-commit) áp dụng các thay đổi vào thư mục làm việc và chỉ mục mà không tạo commit — hữu ích khi bạn cần kết hợp các thay đổi từ nhiều commit thành một. Cờ -x thêm một dòng (cherry picked from commit ...) vào thông điệp commit, giúp dễ dàng theo dõi nguồn gốc của các thay đổi trong lịch sử.

# Cherry-pick một commit duy nhất bằng hash
git cherry-pick a1b2c3d

# Cherry-pick nhiều commit (tuần tự)
git cherry-pick a1b2c3d e4f5g6h i6j7k8l

# Cherry-pick không tự động commit
git cherry-pick -n a1b2c3d

# Cờ -x thêm tham chiếu đến commit gốc
git cherry-pick -x a1b2c3d

Khi nào sử dụng cherry-pick

Kịch bản chính là chuyển các bản sửa lỗi giữa các nhánh phát hành. Hãy tưởng tượng: một lỗi nghiêm trọng được tìm thấy và sửa trong develop. Nhánh phát hành release/v2.1 đã được tách ra và cũng chứa lỗi này. Merge toàn bộ develop vào release sẽ mang theo nhiều mã chưa hoàn thành, trong khi cherry-pick commit sửa lỗi duy nhất là một giải pháp an toàn và chính xác.

Kịch bản thứ hai là hoàn tác các thay đổi với khôi phục sau đó. Nếu một commit bị hoàn tác qua git revert và sau đó phát hiện ra việc hoàn tác là sai lầm — cherry-pick commit đã bị hoàn tác sẽ khôi phục các thay đổi. Điều này đúng đắn hơn việc hoàn tác một revert vì nó không tạo ra xung đột lặp lại.

Kịch bản thứ ba là kết hợp các commit từ các nhánh tính năng khác nhau vào một nhánh thử nghiệm để kiểm thử tích hợp. Thay vì merge nhiều nhánh chưa hoàn thành (với mã chưa xong), bạn có thể chọn chỉ những commit đã sẵn sàng từ mỗi nhánh và kiểm tra cách chúng hoạt động cùng nhau.

• Sửa lỗi — chuyển bản sửa lỗi từ develop sang release mà không có mã chưa hoàn thành.
• Hotfix — áp dụng bản sửa lỗi từ nhánh hotfix sang main và develop đồng thời.
• Hoàn tác revert sai — cherry-pick commit đã bị hoàn tác để khôi phục các thay đổi.
• Kiểm thử — thu thập các commit được chọn từ các nhánh khác nhau để kiểm thử tích hợp.

Cherry-pick so với rebase và merge

Cherry-pick khác với rebase và merge ở chỗ nó hoạt động ở cấp độ commit riêng lẻ thay vì toàn bộ nhánh. Trong khi rebase chuyển tất cả các commit của một nhánh và merge kết hợp hai nhánh, cherry-pick chỉ chọn những commit cần thiết. Điều này làm cho nó trở thành một công cụ chính xác hơn, nhưng cũng thủ công hơn.

Một điểm khác biệt nữa là quyền tác giả. Khi cherry-pick, Git theo mặc định giữ lại tác giả của commit gốc, nhưng người commit (committer) trở thành người dùng hiện tại. Thông điệp commit có thể theo dõi nguồn gốc qua cờ -x. Khi rebase, cả tác giả và người commit đều trở thành người dùng hiện tại với hash mới.

Hiệu suất: cherry-pick một commit duy nhất nhanh hơn merge hai nhánh với nhiều commit. Nhưng nếu bạn cần chuyển hàng chục commit, tốt hơn nên tạo một nhánh tạm thời và thực hiện rebase — sẽ hiệu quả hơn và không yêu cầu chỉ định hàng chục hash.

Chuyển nhiều commit

Nhiều commit có thể được chuyển bằng một lệnh duy nhất bằng cách liệt kê các hash của chúng cách nhau bằng dấu cách: git cherry-pick A B C. Git áp dụng các commit theo tuần tự theo thứ tự được chỉ định. Nếu bất kỳ commit nào gây ra xung đột, cherry-pick tạm dừng và nhà phát triển phải giải quyết xung đột, sau đó tiếp tục với git cherry-pick --continue.

Phạm vi commit: git cherry-pick A..B (tất cả các commit sau A đến B, không bao gồm A) và git cherry-pick A^..B (tất cả các commit từ A bao gồm đến B). Phạm vi thuận tiện khi bạn cần chuyển tất cả các commit từ một nhánh mà không có mối quan hệ cha — ví dụ: khi di chuyển một tính năng đã hoàn thành từ nhánh cũ sang nhánh mới.

Cờ --strategy xác định cách Git áp dụng các thay đổi. Theo mặc định, chiến lược recursive được sử dụng, nhưng bạn có thể chỉ định ours hoặc theirs để tự động chọn một bên xung đột. Cờ --mainline được sử dụng khi cherry-pick một commit merge — nó chỉ định số cha (1 hoặc 2) mà diff được tính toán dựa trên đó.

# Phạm vi commit cherry-pick
git cherry-pick develop~5..develop~2

# Cherry-pick commit merge (chỉ định cha)
git cherry-pick -m 1 m9n0o1p

# Sử dụng chiến lược theirs
git cherry-pick --strategy=recursive \
  --strategy-option=theirs a1b2c3d

# Tiếp tục sau khi giải quyết xung đột
git cherry-pick --continue

Xung đột khi cherry-pick

Xung đột khi cherry-pick xảy ra khi các thay đổi của commit được chuyển ảnh hưởng đến cùng các dòng đã được thay đổi trong nhánh đích. Git tạm dừng thực thi, đánh dấu các tệp xung đột và chờ giải quyết. Trong trạng thái, các tệp này được hiển thị là both modified.

Các bước giải quyết xung đột: mở tệp xung đột, tìm các điểm đánh dấu xung đột (<<<<<<<, =======, >>>>>>>), chỉnh sửa nội dung, xóa các điểm đánh dấu, chạy git add cho các tệp đã giải quyết và chạy git cherry-pick --continue. Nếu không thể giải quyết xung đột — git cherry-pick --abort hủy toàn bộ cherry-pick, đưa nhánh trở lại trạng thái ban đầu.

Một vấn đề thường gặp: commit đã chứa các thay đổi tương đương với các thay đổi hiện có. Trong trường hợp này, Git báo cáo “nothing to commit” hoặc “empty commit” khi cố gắng cherry-pick. Các cờ --keep-redundant-commits và --empty=keep buộc Git tạo một commit trống để giữ nguyên trình tự, trong khi --skip cho phép bỏ qua commit đó.

# Xung đột khi cherry-pick — dừng
git cherry-pick a1b2c3d
# error: không thể áp dụng a1b2c3d... thông điệp commit

# Giải quyết xung đột → thêm vào chỉ mục
git add src/conflicted_file.swift
git cherry-pick --continue

# Bỏ qua commit trống (đã được áp dụng)
git cherry-pick --skip

# Hủy bỏ hoàn toàn
git cherry-pick --abort

Thực hành tốt nhất cherry-pick

Quy tắc đầu tiên: luôn kiểm tra rằng commit được chuyển là độc lập. Nếu commit A phụ thuộc vào các thay đổi trong commit B không được chuyển, cherry-pick A có thể phá vỡ quá trình xây dựng. Trước khi cherry-pick, hãy kiểm tra tệp nào commit đã thay đổi qua git show --stat <hash>.

Quy tắc thứ hai: ghi lại các thao tác cherry-pick. Sử dụng cờ -x để thông điệp commit giữ lại tham chiếu đến commit gốc. Điều này sẽ giúp ích trong quá trình phân tích lịch sử sau này để hiểu thay đổi đến từ đâu. Không có -x, cherry-pick trông giống như một commit thông thường và nguồn gốc của nó chỉ có thể được xác định qua git log --graph.

Quy tắc thứ ba: tránh cherry-pick giữa các nhánh đã phân kỳ quá xa. Nếu đã nhiều thời gian trôi qua kể từ khi commit được tạo và cơ sở mã đã thay đổi đáng kể, các xung đột sẽ rất nhiều và phức tạp. Trong những trường hợp như vậy, tốt hơn nên thực hiện lại bản sửa lỗi trong nhánh đích — sẽ mất ít thời gian hơn so với giải quyết hàng chục xung đột.

• Cherry-pick chỉ các commit độc lập không có phụ thuộc bên ngoài.
• Cờ -x là bắt buộc để ghi lại nguồn gốc commit trong thông điệp.
• Tránh cherry-pick các commit cũ với sự khác biệt lớn về cơ sở mã.
• CI/CD kiểm tra bản dựng sau cherry-pick: xung đột có thể không xảy ra, nhưng mã có thể không biên dịch được.
• Bình luận PR khi tạo pull request, hãy chỉ rõ commit nào đã được chuyển qua cherry-pick.