Đơn giản hóa - git merge và git rebase sử dụng thế nào cho hợp lý?

Đơn giản hóa - git merge và git rebase sử dụng thế nào cho hợp lý?

Tin ngắn hàng ngày dành cho bạn
  • Cuộc đua mô hình ngày càng khốc liệt khiến các công ty công nghệ không ai muốn bỏ lại phía sau. Llama 4 Scout, Llama 4 Maverick là hai mô hình mã nguồn mở mới nhất của Meta, được quảng cáo với hiệu năng vượt trội, thậm chí còn đánh bại các mô hình tiên tiến nhất như GPT-4.5, Claude Sonnet 3.7, hay Gemini 2.0 Pro... Nhưng bênh cạnh đó, Scout và Maverick đang vấp phải chỉ trích về việc gian lận. Liệu chúng ta có nên đặt lòng tin vào Meta thêm lần nữa 🤔

    Llama 4 Scandal: Meta’s release of Llama 4 overshadowed by cheating allegations on AI benchmark

    » Xem thêm
  • Hôm nay tình cờ mình biết đến trang web notes.andymatuschak.org có cách ghi chú rất hay. Bấm vào liên kết nó mở ra một thẻ mới bên cạnh. Cứ thế bấm vào thì nó lại tiếp tục mở ra. Giống như các ngăn tài liệu vậy.

    Kiểu trình bày này vừa dễ theo dõi mà còn đúng như kiểu viết theo mạch cảm xúc luôn. Tiếc là không thấy tác giả nguồn mở dự án này. Không biết có cái nào tương tự không ta 🤔

    » Xem thêm
  • Bạn nhận thấy sự khác biệt gì trong bức ảnh này không 😁

    » Xem thêm

Vấn đề

Mỗi khi làm xong một tính năng, chúng ta tiến hành merge nó vào develop. Lệnh git merge về cơ bản là hợp nhất những thay đổi từ nhánh này sang nhánh khác và nó có thể tạo ra thêm một commit để đánh dấu việc hợp nhất các thay đổi.

Gần đây, bạn nghe đến lệnh git rebase. Qua tìm hiểu thì nó cũng được dùng để hợp nhất những thay đổi từ nhánh này sang nhánh khác. Có điều, cách git mergegit rebase tạo ra lịch sử commit là khác nhau thôi.

Nhưng hẳn bạn đã nghe lời khuyên rằng: nếu là người mới thì đừng vội sử dụng git rebase. Trong khi git merge đang giải quyết tốt vấn đề của bạn thì hãy tiếp tục sử dụng nó. Thú thật tôi cũng không chắn chắn về việc sử dụng git rebase, nhưng có một tips nhỏ mà tôi muốn chia sẻ nó với các bạn trong bài viết dưới đây, hy vọng sẽ giúp ích.

Một trường hợp phổ biến

Trong thực tế, nhiều dự án có hai nhánh cơ bản là master và develop. Mã trong master được go production còn mã trong develop thì được chạy trong môi trường development. (Thực tế các nhánh có thể nhiều hơn và phức tạp hơn nhưng tôi chỉ lấy ví dụ cơ bản).

Để phát triển một tính năng mới, tôi checkout từ develop ra một nhánh mới rồi phát triển trên đó. Các nhánh có thể theo quy tắc feature/01, feature/02... với 01, 02... là tên của tính năng.

cây git ban đầu

Trong quá trình phát triển, có thể có nhiều tính năng được phát triển cùng lúc và độc lập với nhau. Đến một lúc nào đó bạn cần những thay đổi từ feature/01 vào feature/02 thì sao? Merge feature/01 vào feature/02? Không tồi! Nhưng nếu tiếp tục làm thế lịch sử commit của bạn có thể sẽ rối tung lên, thay vào đó sao không thử cách này?

Nguyên tắc: Luôn để develop làm nhánh trung gian giữa các nhánh tính năng, bởi tính năng suy cho cùng sẽ phải đưa vào develop. Nên nếu cần các thay đổi từ feature/01 vào feature/02 bạn hãy merge feature/01 vào develop, và từ feature/02 tiến hành rebase develop.

cây git sau khi rebase

Nếu từ feature/02 mà merge trực tiếp feature/01 thì sẽ có lịch sử commit trông như thế này:

cây git sau khi merge

Trông cây git phần phức tạp hơn so với cách ban đầu rồi đúng không?

Nguyên tắc vàng của rebase

Quy tắc vàng của rebase được nêu ra rất rõ trong bài viết Merging vs. Rebasing. Tôi sẽ tóm tắt lại, là không bao giờ sử dụng rebase trên nhánh dùng chung. Trong ví dụ trên nhánh dùng chung là develop. Vì sao? Nếu từ develop mà ta tiến hành rebase feature/01 hoặc feature/02 thì lúc này lịch sử commit trên develop "bị viết lại".

thử rebase feature vào develop

Như trên, khi từ develop (trong hình là Main) mà rebase feature/01, các commit mới của develop được thêm vào sau commit mới nhất của feature. Lúc này nhánh develop, lịch sử commit "bị viết lại". Tưởng tượng mà xem khi có nhiều người đang làm việc dựa trên nhánh develop từ thời điểm trước đó. Sau này có thực hiện thao tác merge sẽ gây ra nhiều vấn đề khó hiểu.

Tổng kết

Tóm lại, merge luôn đủ dùng. Bạn không cần biết đến rebase cũng chẳng sao. Nhưng nếu muốn có một cây lịch sử git trông gọn gàng hơn thì hãy thử rebase. Quy tắc vàng là không bao giờ rebase feature vào develop (không bao giờ rebase trên nhánh dùng chung). Chỉ từ feature rebase develop, và ngược lại, từ develop merge feature.

Tài liệu tham khảo:

Cao cấp
Hello

Bí mật ngăn xếp của Blog

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, hãy bấm vào ngay!

Là một lập trình viên, bạn có tò mò về bí mật công nghệ hay những khoản nợ kỹ thuật về trang blog này? Tất cả bí mật sẽ được bật mí ngay bài viết dưới đây. Còn chờ đợi gì nữa, 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.

Bình luận (0)

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