Đơ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ý?

Những mẩu tin ngắn hàng ngày dành cho bạn
  • Một phần mềm giúp chuyển đổi văn bản thành giọng nói do một lập trình viên người Việt làm ra - J2TEAM - Text to Speech (Free). Bạn có thể chuyển đổi hàng chục ngôn ngữ sang hàng chục giọng đọc tự nhiên khác nhau. Điều đặc biệt là nó miễn phí.

    Đánh giá sơ bộ thì chuyển đổi văn bản dài hoặc văn bản bằng tiếng Việt thuần thì rất tốt. Còn dính thêm các từ tiếng Anh thì nó đọc hơi buồn cười 😅

    » Xem thêm
  • Quá ghê ghớm, Codeium - vốn được biết đến như một đối thủ của Github Copilot, khi nó cho người dùng dùng miễn phí không giới hạn. Mới đây họ giới thiệu thêm Windsurf Editor - không chỉ còn là VSCode Extentions nữa mà là một trình Editor luôn - cạnh tranh trực tiếp với Cursor. Và điểm chính là nó... hoàn toàn miễn phí 🫣.

    » Xem thêm
  • Tin vui đầu này, Github Copilot đã chính thức có bản Free cho tất cả mọi người.

    Github Copilot là một trợ lý AI code cùng chúng ta, nó có thể tự động hoàn thành mã, trò chuyện hoặc sửa lỗi. Hiện đang hỗ trợ nhiều trình soạn thảo, IDE phổ biến như VSCode, JetBrains, XCode...

    Phiên bản miễn phí đang bị giới hạn 2000 Suggestions, và khoảng 50 requests đến tính năng Chat hàng tháng. Sau đó bạn có thể nâng cấp lên các phiên bản cao cấp hơn với giá từ 10$.

    Theo đánh giá của mình thì Copilot rất tốt và xứng đáng trong tầm giá, đang dùng hàng ngày 😄

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