Đơ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
  • Có 2 phần mềm tiện ích cho Mac mà mỗi khi dùng máy Mac Mini hoặc Macbook có cắm thêm màn hình rời, thêm bàn phím với chuột nữa là BetterDisplayMac Mouse Fix. Đi qua từng cái nhé!

    BetterDisplay giúp tinh chỉnh kích thước của màn hình rời để đạt độ phân giải HiDPI. Như bạn biết Mac khá kén màn hình và tuỳ chọn độ phân giải trong cài đặt mặc định rất ít ỏi, nên BetterDisplay cung cấp nhiều lựa chọn phù hợp hơn.

    Cái thứ hai là Mac Mouse Fix, nếu dùng chuột ngoài bạn sẽ thấy nó cuộn không giống với Trackpad của Macbook cho lắm. Điều kì diệu xảy ra khi cài phần mềm này vào. Nó thêm hiệu ứng "smooth" và giúp cuộn chuột y như cuộn bằng Trackpad luôn. Thật thần kỳ.

    » Xem thêm
  • Mọi người còn nhớ grep.app không? Trang cho phép tìm kiếm mọi thứ trên Github chỉ cần đoạn mã xuất hiện trong cụm từ tìm kiếm. Sơ qua thì trang này đang lưu lại dữ liệu từ Github hay làm thế nào đó rồi mới tìm kiếm được, do đó không phải 100% kho lưu trữ công khai đều xuất hiện trên này.

    Mình phát hiện ra Github cũng có trang tương tự, hơi chậm tí thôi cơ mà tìm kiếm 100% luôn nha 😆. Github Search. Mọi người nhớ bấm vào Code ở mục Filter By bên trái để nó tìm chính xác hơn nhé.

    » Xem thêm
  • Vừa gia hạn tên miền cho 2coffee.dev. Vậy là em nó đã 3 tuổi rồi đó mọi người. Sẵn đây nói luôn...

    Mọi người chắc cũng biết về ý nghĩa của cái tên rồi đúng không. Ấy thế mà nó lại đang dính vào "lời nguyền cà phê" bởi vì tên miền có chứa từ khoá "coffee" rất "hot", làm nhiều người hoặc công cụ tìm kiếm đánh giá sai lệch về nội dung của trang web 🥲. Nhiều lúc mình muốn tìm cách để "khai tử" cái tên này đi, thay bằng tên khác thì con đường bớt chông gai hơn.

    Tiền thân của 2coffee.dev là estacks.icu, ấy thế mà sao lại bỏ được cái tên cũ không chút đắn đo? Là vì 2coffee.dev đánh dấu sự trưởng thành trong tư duy làm sản phẩm của mình, ý là nghiêm túc hơn á. Còn stacks.icu vẫn mãi mãi là tiền thân của "Xin chào, một tách cà phê dành cho mấy ông lập trình viên đâ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

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