hotfix bằng git cherry-pick

hotfix bằng git cherry-pick

Threads
  • Tuôi" để ý là cứ đợt nào ham đọc cái là lại lười viết, tuần nay tuôi đang đọc một lúc 3 cuốn, à phải là đọc 2 và nghe 1.

    Cuốn sách ám ảnh nhất đến thời điểm hiện tại: Đại dương đen - thuật lại 12 câu chuyện của 12 người mắc bệnh trầm cảm. Thần kinh vững, nhưng mới đọc 2 câu truyện đầu thôi mà cảm giác ngộp thở, bứt rứt thật khó tả 😰

    Câu chuyện tiếp theo đó thì mang lại cảm giác dễ thở hơn vì họ kiểm soát được bản thân. Nhưng sang tiếp câu chuyện thứ 4, thứ 5 thì lại như một có một bàn tay siết họng mình lại. Không thể nhắm mắt mà nghe được á, có gì đó rất đáng sợ.

    Một câu mà mình cảm thấy ám ảnh nhất là khi ba mẹ của người mắc trầm cảm luôn miệng hỏi tại sao con lại như thế mỗi khi sắp lên cơn và gào thét. Họ chỉ đành bất lực trả lời là "Làm sao mà con biết! Cũng giống như hỏi một người bị ốm là tại sao lại ốm? Làm sao mà biết được chứ! Có ai muốn đâu!".

    » Xem thêm
  • Mistral.ai là một công ty AI có trụ sở tại Pháp, được biết đến với nhiều mô hình ngôn ngữ lớn Mistral. Mới đây họ vừa ra mắt thêm một số mô hình có kích thước siêu lớn, siêu mạnh... Nhưng tạm khoan nói đến vì Mistral Chat cũng vừa được ra mắt với nhiều tính năng hay ho tương tự như Chat GPT mà lại miễn phí 😇

    » Xem thêm
  • Qwen2.5-Coder-32B đang là tâm điểm của sự chú ý khi điểm số của nó đánh bại cả GPT-4o hay kể cả là Claude Sonet 3.5. Điều đáng chú ý là nó là mã nguồn mở. Điều đó đồng nghĩa với việc bạn hoàn toàn có thể kéo models về máy và chạy cục bộ dưới máy tính của mình. Nhưng...

    Để chạy được mô hình thì GPU máy tính phải đạt cấp độ quái vật. Cụ thể trong một bài đăng của người dùng thử nghiệm Qwen2.5-Coder-32B trên GTX 3090 thì tốc độ tối đa models cho ra nằm ở mức hơn 30 tokens/s.

    Hy vọng vài nữa sẽ có một bên như Groq hay SambaNova dựng lên để "kiểm thử" hiệu năng con chip của họ, và quan trọng hơn hết là cho anh em dùng "chùa" thì hay biết mấy 🫣

    Tham khảo: Qwen2.5-Coder-32B is an LLM that can code well that runs on my Mac

    » Xem thêm

Vấn đề

Phải nói rằng từ khi biết dùng git tôi không cần phải copy project ra thư mục mới để "backup" mỗi khi sắp sửa làm một thứ gì đó to lớn. Hồi chưa biết dùng git, cách đó là cách mà tôi có thể nghĩ ra được để bảo vệ mã của mình an toàn trong trường hợp code ra bug còn có đường lui.

Git là một công cụ quản lý phiên bản mà tôi tin rằng hiệu quả cho hầu hết lập trình viên. Tính năng nổi bật của git là cho phép chúng ta tạo ra commit gọi như là "cam kết" đối với từng dòng mã bạn thêm vào. Mỗi cam kết này đều được ghi vào trong lịch sử và có thể dễ dàng xem lại được cũng như đưa mã trở về trạng thái đó.

Đối với mỗi cá nhân, tổ chức lại có các cách sử dụng git khác nhau tạo nên sự đa dạng về flow. Flow là một từ chỉ quy trình làm việc trong git, ví dụ thường thấy nhất: nhánh master là nhánh chính, develop là nhánh phát triển, các nhánh với prefix chứa feature như feature/01, feature/02... là cách nhánh được checkout ra từ develop để liên tục triển khai tính năng mới.

hotfix cũng là một prefix trong nhánh để sửa một lỗi nào đó trong môi trường production. Sau khi release ứng dụng, chẳng may có một lỗi phát sinh buộc chúng ta cần phải sửa ngay lập tức. Bởi những lỗi như thế được được đánh cờ là nghiêm trọng và cần phải được ưu tiên xử lý. Thông thường cách để giải quyết là checkout từ master ra một nhánh hotfix, ví dụ như hotfix/01, tiến hành sửa lỗi, kiểm thử và nếu mọi thứ ổn thỏa thì merge hotfix/01 vào cả hai nhánh develop và master.

Đó là trong trường hợp chúng ta vừa release xong thì phát hiện ra lỗi, hay ít nhất là khoảng thời gian phát hiện ra lỗi ngắn và những thay đổi trên develop chưa quá nhiều so với master. Đặt vấn đề ngược lại, tức là develope đã có quá nhiều thay đổi do team liên tục phát triển tính năng mới, thì lúc đó khả năng hotfix khi merge vào develop sẽ gây ra tình trạng conflic.

Trường hợp này cũng dễ hiểu thôi, vì tính năng mới có thể đã sửa mã ở một nơi nào đó so với master. Và khi master đang "outdate" mà lại merge hotfix được checkout từ master vào thì khả năng xung đột sẽ xảy ra. Để khắc phục trường hợp này, chúng ta cần đến một phương pháp gọi là "cherry pick" để hotfix.

git cherry-pick

`git cherry-pick` là một lệnh trong Git được sử dụng để áp dụng một hoặc nhiều commit từ một nhánh khác vào nhánh hiện tại của bạn. Điều này cho phép bạn áp dụng các thay đổi từ các commit cụ thể mà không cần phải merge toàn bộ nhánh.

Ví dụ, nếu bạn có một commit trên một nhánh phát triển mới nhất đã giải quyết một vấn đề cụ thể mà bạn cần để áp dụng vào nhánh sản phẩm của bạn, bạn có thể sử dụng git cherry-pick để áp dụng commit đó vào nhánh hiện tại.

git cherry pick

Thông thường, nếu merge một nhánh vào nhánh khác git sẽ lấy tất cả thay đổi từ các commit để merge vào. Nhưng với cherry pick ta hoàn toàn có thể chỉ chọn một commit để đưa vào nhánh.

Áp dụng vào trong trường hợp hotfix bên trên. Chúng ta sẽ tạo ra một nhánh hotfix từ develop, sửa mã, commit rồi cherry pick commit đó vào master.

Để giải thích, vì nhánh develop luôn chứa mã mới hơn hoặc bằng với master cho nên nếu tạo hotfix từ develop rồi sửa mã và chỉ "pick" commit đó vào trong master thôi thì sẽ giảm bớt nguy cơ gây xung đột.

Áp dụng ra rộng hơn, cherry pick không chỉ để dành cho hotfix mà còn nhiều trường hợp khác nữa, miễn là khi nào bạn cần "pick" một commit vào một nhánh nào đó mà không phải merge toàn bộ nhánh.

Tổng kết

git cherry-pick được sử dụng để áp dụng một hoặc nhiều commit từ một nhánh khác vào nhánh khác. Trong bài viết này chúng ta đang nói đến việc sử dụng cherry-pick để hotfix đối với trường hợp nhánh develop đã đi quá xa so với master và mang nhiều thay đổi. Nếu merge hotfix từ master vào develop khả năng mã "outdate" sẽ gây conflic trên mã mới, thay vào đó chúng ta tạo hotfix từ develop và cherry-pick commit vào master sẽ giảm nguy cơ gây "xung đột".

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.
Author

Xin chào, tôi tên là Hoài - một anh Dev kể chuyện bằng cách viết ✍️ và làm sản phẩm 🚀. Với nhiều năm kinh nghiệm lập trình, tôi đã đóng góp một phần công sức cho nhiều sản phẩm mang lại giá trị cho người dùng tại nơi đang làm việc, cũng như cho chính bản thân. Sở thích của tôi là đọc, viết, nghiên cứu... Tôi tạo ra trang Blog này với sứ mệnh mang đến những bài viết chất lượng cho độc giả của 2coffee.dev.Hãy theo dõi tôi qua các kênh LinkedIn, Facebook, Instagram, Telegram.

Bạn thấy bài viết này có ích?
Không

Bình luận (0)

Nội dung bình luận...