Hãy thử cherry-pick GitHub PR

• Đã 4 tháng kể từ khi bắt đầu sử dụng mono-repository trong công ty
• Đồng thời cũng đang áp dụng trunk-based development — từ khóa luôn đi cùng mono-repository
• Theo chiến lược trunk-based development, nhóm đang sử dụng flow commit vào nhánh main rồi cherry-pick sang nhánh release
• Dựa trên nội dung từ blog kỹ thuật của LinkedIn, tác giả đã cấu hình GitHub Action, nhưng không thể tự động giải quyết CONFLICT. Khi xảy ra CONFLICT, người dùng vẫn phải tự chạy lệnh git cherry-pick trên local
• Tác giả đã tự làm một plugin gh để hỗ trợ lệnh cherry-pick này.

Cách dùng

gh cherry-pick -pr <pr_number> -onto <target_branch> [-merge auto|squash|rebase] [-push]  

• Với tùy chọn -merge, có thể chọn cherry-pick merge commit của PR hoặc cherry-pick các commit gốc của PR
  • Nếu không chỉ định hoặc dùng -merge=auto, công cụ sẽ tự động kiểm tra chiến lược merge đã được dùng cho PR và áp dụng tương ứng
• Với tùy chọn -push, nếu cherry-pick thành công thì sẽ tự động push lên remote

Cảm nghĩ sau khi làm

• Trong quá trình phát triển một chương trình liên tục tương tác với process và trạng thái bên ngoài, tác giả đã tạo riêng một test repository để tạo test dataset
  • Kinh nghiệm từng đóng góp cho dự án libgit2 và refined-github trước đây đã giúp ích khá nhiều
• Nhiều phần học hỏi để mang lại trải nghiệm CLI tốt hơn
  • Việc tự học để thử làm docker-cli một mình cũng có ích
• Hóa ra làm một chương trình CLI tốn công hơn tưởng tượng rất nhiều
  • Quản lý nhiều giá trị trạng thái trong mô hình pipeline
  • Cung cấp input interface trực quan cho người dùng
  • Đưa ra input validation ở thời điểm sớm nhất có thể
  • Khôi phục hệ thống của người dùng về trạng thái ban đầu, v.v.
  • Ban đầu tưởng có thể làm trong khoảng một ngày, nhưng thực tế mất khoảng 5 ngày để hoàn thành (dù việc cải thiện GitHub Actions Workflow cũng được phát triển song song, nhưng vẫn tốn thời gian hơn dự kiến rất nhiều)

[qncnxnlrla]

Xin chào~ Khi cần revert một commit đã được merge vào nhánh main (trunk), mọi người thường xử lý thế nào?

• Nếu revert trên nhánh main thì có cherry-pick sang nhánh release luôn không?
• Hay không dùng revert mà thêm một commit sửa khác?

Vì đã tích lũy khá nhiều commit nên có vẻ sẽ có những trường hợp khó cherry-pick do phát sinh conflict; mình muốn hỏi liệu mọi người có kinh nghiệm xử lý những case như vậy không!

[a1eng0]

Xin chào~ cảm ơn bạn đã để lại bình luận!

Trong trường hợp cần revert một commit đã được merge vào nhánh main(trunk) thì bạn xử lý như thế nào?

Chúng tôi chỉ định cherry-pick ngay trong PR revert được mở trên nhánh main. Vì toàn bộ lịch sử cherry-pick đều còn lại trong link PR gốc nên không có khó khăn gì trong việc theo dõi. Ngoài ra cũng không thực hiện kiểm tra máy móc riêng nào cả haha

Trường hợp có quá nhiều commit tích lại dẫn đến conflict, khiến việc cherry-pick trở nên khó khăn

Trước hết, khi làm trunk-based development thì mỗi PR đều là đơn vị nhỏ nên conflict không xảy ra thường xuyên. Nếu conflict thực sự phát sinh thì phải viết code thủ công. Chúng tôi phát hành release thường xuyên để nhanh chóng deprecate việc hỗ trợ các phiên bản quá cũ, từ đó tránh hiện tượng cấu trúc code thay đổi quá lớn.

[lamanus]

Mình không thật sự hiểu đây là một chiến lược cần thiết vì lý do gì...

[a1eng0]

Nếu bạn đọc nội dung được giới thiệu trong release-from-trunk thì có lẽ sẽ giúp bạn hiểu hơn đó haha