Đơ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
  • R1 chưa qua, R2 đã tới 😅

    Mặc dù mới đang đồn thổi thôi cơ mà chắc chỉ có Deepseek mới gây tiếng vang tương tự như OpenAI hoặc Anthropic. Mà thứ người dùng quan tâm là chất lượng & giá cả 😄

    Deepseek R2 will be releasing soon

    » Xem thêm
  • Opensource này giúp bạn tạo nhanh một trang cá nhân giới thiệu về bản thân (giống như CV á): self.so

    » Xem thêm
  • 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

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

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.

Bình luận (0)

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