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` 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.
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.
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".
Tôi & khao khát "chơi chữ"
Bạn đã thử viết? Và rồi thất bại hoặc chưa ưng ý? Tại 2coffee.dev chúng tôi đã có quãng thời gian chật vật với công việc viết. Đừng nản chí, vì giờ đây chúng tôi đã có cách giúp bạn. Hãy bấm vào để trở thành hội viên ngay!
Đăng ký nhận thông báo bài viết mới
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ình luận (0)