Đơ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ốn sách nào đến cuối cùng cũng nên có cái kết viên mãn, hoặc chí ít sự ra đi của nhân vật nào đó mang lại bình yên cho những người còn lại. Mình đã tin vào điều đó cho đến khi đọc cuốn "Tuổi thơ dữ dội" của nhà văn Phùng Quán.

    Hội tụ đủ yếu tố để hình thành nên các mảnh đời có tuổi thơ dữ dội. Từ hái lá chữa bệnh cho mẹ, vô tình nghe một bản nhạc, hay xuất thân từ gia đình có truyền thống cách mạng... nhưng trái tim cùng chung một chí hướng: Thà chết chứ không làm nô lệ.

    Đọc mới thấy những khó khăn nhọc nhằn, thiếu thốn nhưng các trinh sát không hề nao núng. Tinh thần sắt đá, kiên cường sẵn sàng hy sinh để hoàn thành nhiệm vụ được giao. Những trận đánh nảy lửa, sự hy sinh mất mát, buổi tra tấn tàn bạo và những lần vượt ngục được kể lại rất sống động và hồi hộp từng phút. Cả những kẻ nhẫn tâm bán rẻ đồng bào để đổi lại vinh hoa phú quý. Có những hiểu lầm mà chỉ đến khi chết mới rửa sạch. Có lẽ cái chết không đáng sợ, mà đáng sợ nhất là mang tiếng kẻ bán nước.

    Cuốn sách này hay quá, đọc đến cuối mà hai bọng nước căng lên trên khoé mắt. Tại sao phải cố giữ lại giọt nước mắt mà đáng ra nó nên được giải thoát bởi sự thăng hoa của cảm xúc 🥹?

    » Xem thêm
  • Khi nghiên cứu về một vấn đề gì đó mọi người thường có cách ghi chép lại như thế nào? Kiểu như là tài liệu đã tìm thấy, hình ảnh, liên kết, ghi chú...

    Mình thì rất hay nghiên cứu về một chủ đề nào đó. Ví dụ gặp cái ảnh nào hay thì lưu lại vào máy, tài liệu thì cũng tương tự, liên kết thì lưu vào Bookmarks của trình duyệt... Cơ mà lúc tìm lại thì chẳng biết mọi thứ trước đó lưu ở đâu, tìm thế nào. Thậm chí có khi còn quên hết những gì đã làm trước đó, lục lại thì như mới toanh 😃.

    Nên mình đang ấp ủ kế hoạch xây dựng nên một nơi lưu trữ những gì mà mình tìm hiểu, không chỉ dành riêng cho bản thân mà còn mang hy vọng chia sẻ nó đến với mọi người. Đây như là một nơi chứa các chủ đề nghiên cứu, mỗi chủ đề gồm rất nhiều ghi chú có móc nối đến nhau tạo nên một sổ tay hoàn chỉnh. Dễ dàng theo dõi, dễ dàng viết và dễ tra cứu...

    Mình viết blog, cái khó của viết là lối hành văn và nội dung muốn truyền tải. Hành văn mà dở thì cản trở người đọc, nội dung lắt léo thì coi như mất linh hồn của bài viết. Nhiều người viết rất muốn chèn thêm thông tin ngoài lề vào để củng cố kiến thức nhưng điều đó vô tình lại làm bài viết trở nên dài ngoằng, lan man, không tập trung vào nội dung chính.

    Sổ ghi chú (Notebooks) tạo ra để khắc phục tình trạng này. Không cần phải quá trau chuốt vào viết mà quan tâm nhiều đến quá trình nghiên cứu, thể hiện qua nhiều bài viết ngắn có liên kết với nhau. Ngoài ra còn có thể lưu lại cả tài liệu có liên quan nữa.

    Đấy là dự kiến, mình biết nhiều bạn có cách ghi chép riêng. Vì vậy rất mong nhận được chia sẻ từ mọi người. Cảm ơn.

    » Xem thêm
  • altcha-org/altcha là một dự án mã nguồn mở thay thế giải pháp reCaptcha hay hCaptcha.

    Nghiên cứu mấy dự án này cũng hay ho phết, vì coi như tìm hiểu luôn cách nó hoạt động và ngăn chặn hành vi "spam" ra sao 🤓

    » 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

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!

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!

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