Chào mọi người, chắc hẳn đã có quá nhiều bài viết chia sẻ về cách hợp nhất branch trong quá trình làm việc với Git workflow thông qua 2 phương thức phổ biến là Merge và Rebase. Tuy nhiên, với phương thức Rebasing hôm nay mình xin chia sẻ bài viết dưới dạng best practice thực chiến về kinh nghiệm cá nhân trong quá trình làm việc với Rebasing.

Vì để phù hợp với nội dung bài blog ngắn gọn và dễ hiểu, mình chỉ xin cắt một phần nội dung chia sẻ về kinh nghiệm thực chiến. Do đó, để có kiến thức cơ bản về Rebasing, các bạn có thể đọc qua bài viết so sánh để có cái nhìn về kiến thức nền tảng trước khi đọc bài viết bên dưới. [https://www.anhkolamgidauanhthe.blog/blog/git-rebase]

Cre: Bytebytego

Nếu chúng ta đã hiểu cách rebase viết lại lịch sử trong khi việc hợp nhất vẫn bảo tồn nó. Nhưng điều này thực sự có ý nghĩa gì theo nghĩa rộng hơn. Và hoạt động này có những khả năng vô hạn và cũng tồn tại nhiều hạn chế tiềm tàng. Vì thế chúng ta cần phải cực kỳ lưu ý và nắm rõ quy trình làm việc cần tuân thủ khi làm việc với Git Rebase.

1. Local cleanup

Trong quá trình phát triển một tính năng trên branch riêng, các lập trình viên có thể có nhiều commit. Để cây Git được clean và gọn hơn, chúng ta cần tiến hành squash commit thông qua tính năng tự rebase trên chính nhánh feature.

Ví dụ bạn có 3 commits liên tục cần gộp lại 1 commit, thực hiện lệnh sau:

git switch feature
git rebase -i HEAD~3

Màn hình hiển thị một tệp editor hiển thị lịch sử commits, chúng ta tiến hành cỉnh sửa file theo syntax. Các options bao gồm:

p: pick - giữ lại commit
r: reword - giữ lại commit và sửa message
s: squash - bỏ qua commit nhưng tích hợp log vào commit liền trước
f: fixup - bỏ qua commit và xoá hoàn toàn log commit

pick 1fc6c95 Patch A
pick 6b2481b Patch B
pick dd1475d something I want to split
pick c619268 A fix for Patch B
pick fa39187 something to add to patch A
pick 4ca2acc i cant' typ goods
pick 7b36971 something to move before patch B # Rebase 41a72e6..7b36971 onto 41a72e6
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# If you remove a line here THAT COMMIT WILL BE LOST.
# However, if you remove everything, the rebase will be aborted.
#

Tiến hành giữ lại commit đầu tiền và squash toàn bộ các commits liền sau bằng cách thay thế pick thành squash. Lưu file :wq và thoát.

2. Rebasing from main

Tiếp theo, sau khi đã gom tất cả các commit của mình làm một chúng ta bắt đầu tiến hành rebase so với branch main. Lưu ý, trước đó ta cần nhảy sang nhánh main và tiến hành pull code từ remote để cập nhật các thay đổi mới nhất trên main.

git switch main
git pull origin main
git switch feature
git rebase -i main feature

3. Push force to feature

Sau khi đã xử lý các conflicts liên quan và squash các commit mong muốn, lúc này các commits trên main đã được cắt nối tuyến tính vào ngay đầu commit trên feature. Khi đó, chúng ta sẵn sàng push lên remote và sẵn sàng tạo Merge/Pull request

git push origin feature --force

Lưu ý:

Sau khi rebase, lịch sử commit local trên nhánh feature đã thay đổi và conflict so với nhánh feature trên remote, vì thế ta cần push force để ghi đè toàn bộ cây Git trên branch featue.

4. Create merge/pull request

Lưu ý:

Trong quá trình tạo PR/MR, quá trình approve cần được diễn ra lần lượt có thứ tự và các PR/MR còn lại cần lập tức rebase ngay khi 1 PR/MR đã được merge vào main.

Tổng kết

Cả hai phương pháp đều giúp đạt được mục tiêu hợp nhất các thay đổi từ một nhánh vào nhánh chính trong quy trình làm việc cần thống nhất code giữa các lập trình viên. Thông qua bài viết hi vọng là chúng ta đã có thể hiểu rõ nguyên lý hoạt động khác nhau và cân nhắc sự lựa chọn phù hợp tuỳ theo nhu cầu dự án.

Nếu chúng ta cần ưu tiên một cây Git sạch sẽ, gọn gàng và “tuyến tính” dễ dàng theo dõi theo tiến độ dự án và không có sự dư thừa những commit merge thì Git rebase là một lựa chọn tối ưu và thông minh.

Ngược lại, nếu chúng ta cần ưu tiên bảo toàn lịch sử đầy đủ của dự án và tránh những nguy cơ mất mát dữ liệu và không ngại các hình dạng “diamond hell” rối mắt trên cây Git khi merge chéo qua lại giữa các branch thì Git merge là một lựa chọn đơn giản và hiệu quả.

Bài viết được đồng đăng tải bởi chính tác giả tại nền tảng 200lab.io. Xem thêm tại https://200lab.io/blog/git-rebase-vs-git-merge/.