hotfix bằng git cherry-pick

hotfix bằng git cherry-pick

Những mẩu tin ngắn hàng ngày dành cho bạn
  • countless.dev là một trang web khá thú vị khi mà nó so sánh giá tiền sử dụng các mô hình LLMs của các nhà cung cấp khác nhau.

    Tại đây bạn có thể nhìn thấy tất cả các mô hình ngôn ngữ lớn phổ biến bởi các nhà cung cấp như OpenAI, Azure, Mistral... Bảng giá cho mỗi 1M tokens đầu vào/ra. Hoặc thậm chí có thể so sánh chúng với nhau để tìm ra nhà cung cấp hoặc mô hình rẻ nhất tuỳ theo mục đích sử dụng.

    » Xem thêm
  • 1,2 năm trước, Kubernetes (k8s) tự nhiên được nhắc đến như một hiện tượng, chắc vì nó bá quá nên ai cũng muốn học và sử dụng. Nó là một công cụ "Automating deployment, scaling, and management of containerized applications" - Vâng! nghe hay ho đấy chứ 🤤.

    Hồi đó thì mình đang đam mê với Docker, đặc biệt là Docker Swarm, cũng tương tự như k8s ý nhưng ở quy mô nhỏ hơn. Docker Swarm thì có vẻ ít phức tạp hơn nhiều so với k8s. Mà như thế cũng tốt vì nó đã và đang đáp ứng rất tốt nhu cầu sử dụng của mình lúc đó, lại còn bớt đi phần phức tạp, lằng nhằng.

    Ấy thế mà 1-2 tháng trở lại đây, các bài viết có tiêu đề "bạn có thực sự cần đến Kubernetes" lại đang nổi lên với tần suất dày hơn. Quả thật k8s rất mạnh nhưng cũng quá phức tạp. Tại sao phải cố dùng dao "mổ trâu để giết gà" cơ chứ? Trừ khi bạn lường trước được độ phức tạp khi muốn áp dụng một công nghệ. Một cái nữa k8s tiêu tốn tài nguyên và nguồn lực ghê ghớm, để vận hành được nó không đơn giản là dựng lên được là xong mà còn phải có rất nhiều nhiều kiến thức nữa 😨.

    À, chắc cũng một phần nữa là do các "ông lớn" đang tập trung đẩy mạnh vào Serverless, giảm bớt sự phức tạp trong khâu vận hành đi, thay vào đó là nên tập trung vào phát triển ứng dụng.

    Bên cạnh đó, thì cái tên WASM cũng đang được nhắc đến rất là nhiều 🤔

    Do you really need Kubernetes in your company/startup? | dev.to

    Do You Really Need Kubernetes?

    » Xem thêm
  • Trước mình cứ khen lấy khen để Serverless, rằng tối ưu chi phí xuống 0đ để duy trì blog các thứ. Đúng là như vậy thật! Nhưng bên cạnh đó serverless cũng có các mặt tối đáng để lưu tâm đấy!

    Hôm kia mình phải mất ngày trời để truy tìm và khắc phục sự cố chỉ vì gọi hàm build-in của Cloudflare KV. Cụ thể là hàm list với limit 1000 - tức là một lần gọi nó trả về 1000 keys của KV. Cơ mà đời không như là mơ. Con số 1000 chỉ là trên lý thuyết. Lúc thì trả về vài trăm, lúc thì vài chục, thậm chí lúc thì lẹt đẹt có vài cái. Thế là làm tắc nghẽn cả hệ thống. À mà cũng không phải là nghẽn mà là hệ thống "nhàn rỗi" quá không có việc gì để làm, trong khi thực tế đáng ra nó phải xử lý cả trăm ngàn cái keys cơ 🥲

    » 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".

Cao cấp
Hello

5 bài học sâu sắc

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

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...