Nhánh tính năng của bạn tụt lại so với main và bạn cần phần việc mới. Git merge vs rebase là lựa chọn giữa hai cách để có nó, và cả hai đều đúng. Chúng khác nhau ở chỗ lịch sử trông thế nào sau đó.

Chúng tôi dựng một kho nhỏ, chạy cả hai lệnh và dán đầu ra thực tế bên dưới, để bạn so sánh kết quả thay vì tưởng tượng. Mới dùng Git? Hãy bắt đầu với hướng dẫn Git cho người mới (tiếng Anh).

git merge và git rebase làm gì

git merge lấy đầu của hai nhánh và kết hợp chúng. Nếu cả hai có commit mới, Git tạo một commit merge có hai cha. Không có gì đã tồn tại bị thay đổi.

git rebase lấy các commit chỉ có ở nhánh của bạn, đặt sang một bên, chuyển nhánh của bạn đến đầu nhánh kia rồi phát lại từng commit. Các commit được phát lại là commit mới với hash mới, dù thay đổi bên trong giống nhau.

Git merge trong thực tế

Điểm xuất phát của chúng tôi: commit A trên main, hai commit (F1, F2) trên feature, và thêm một commit (M1) được thêm vào main sau đó. Bây giờ chúng tôi merge main vào feature.

git switch feature
git merge main
git log --oneline --graph

*   f507aab Merge main into feature
|\
| * 8842fb5 M1
* | 082cc6a F2
* | 5a71e3c F1
|/
* 8766865 A

Biểu đồ cho thấy câu chuyện thật: hai dòng công việc được nối lại. Các commit gốc F1 và F2 giữ nguyên hash. Cái giá là thêm một commit merge, và trong dự án sôi động, biểu đồ trở thành một mạng nhện.

Git rebase trong thực tế

Cùng điểm xuất phát, nhưng lần này chúng tôi rebase feature lên main.

git switch feature
git rebase main
git log --oneline --graph

* 1ff474b F2
* bf9149e F1
* 8842fb5 M1
* 8766865 A

Lịch sử là một đường thẳng, như thể bạn bắt đầu làm sau M1. Hãy nhìn các hash: F1 trước là 5a71e3c nay là bf9149e, còn F2 đổi từ 082cc6a sang 1ff474b. Git đã viết lại chúng, và đó là lý do rebase cần cẩn thận.

Merge và rebase song song

Quy tắc vàng của rebase

Đừng rebase các commit tồn tại bên ngoài kho của riêng bạn. Sau khi rebase, nhánh của bạn không còn khớp với bản sao trên máy chủ, nên việc push cần ép buộc. Nếu đồng nghiệp đã xây công việc trên các commit cũ, lịch sử của họ giờ mâu thuẫn với của bạn, và gỡ rối rất đau đầu.

Rebase nhánh tính năng riêng tư của bạn thì không sao. Rebase main hoặc bất kỳ nhánh nào người khác dùng thì không được.

Quy trình làm việc nhóm an toàn

Quy trình này giữ lịch sử sạch mà không làm ai bất ngờ. Đây cũng là cách đa số nhóm dùng trước pipeline CI của họ, như pipeline trong hướng dẫn GitHub Actions CI/CD (tiếng Anh) của chúng tôi.

git switch feature
git fetch origin
git rebase origin/main        # or: git pull --rebase
# fix conflicts, then: git add <file> && git rebase --continue
git push --force-with-lease   # only on your own branch

--force-with-lease từ chối ghi đè nhánh trên máy chủ nếu ai đó đã push kể từ lần fetch cuối của bạn, điều mà --force thường sẽ âm thầm phá hủy. Khi pull request được duyệt, hãy merge nó vào main.

Cách hoàn tác một rebase hỏng

Rebase trông có vẻ phá hoại, nhưng các commit cũ vẫn nằm trong reflog của Git một thời gian, nên bạn có thể quay lại.

git reflog                    # find the commit before the rebase
git reset --hard HEAD@{5}     # example position, check reflog first

Hãy tạo nhánh sao lưu bằng git branch backup trước bất kỳ rebase rủi ro nào, và việc khôi phục chỉ còn một lệnh. Đang chạy cơ sở dữ liệu hoặc công cụ trong container? Xem hướng dẫn Docker cho người mới (tiếng Anh) của chúng tôi.

Lời kết

Merge giữ sự thật, rebase giữ nó gọn gàng. Hãy dùng rebase để làm mới nhánh của riêng bạn, dùng merge để bàn giao, và đừng bao giờ viết lại lịch sử mà người khác phụ thuộc.

Câu hỏi thường gặp

Tiếp tục học (bài viết tiếng Anh)