Blog

We’re glad you’re here!

Breathe deeply, grab your preferred coffee mug, and look through our blog.

Git merge và Git rebase trong quy trình quản lý mã nguồn

Huong Doan

February 12, 2026

Nhiều năm làm việc ở một số công ty phần mềm, cộng với việc thi thoảng tâm sự với một số anh em trong ngành ở các công ty khác, tôi nhận thấy có hai xu hướng trong quy trình quản lý mã nguồn ở các công ty phần mềm tại Việt Nam. Đó là Merging và Rebasing. Cả hai cách đều có những lợi ích và những giá trí phải đánh đổi. Liệu có thể kết hợp cả hai cách để không phải đánh đổi điều gì không?

Git merge và git rebase đều được thiết kế để kết hợp những thay đổi của một branch sang một branch khác, nhưng theo 2 cách rất khác nhau. Chúng ta sẽ cùng đi qua một ví dụ cụ thể để hiểu rõ sự khác biệt này. Đại khái ở ví dụ này, bạn tạo một số commit trong feature branch của bạn, và bạn được yêu cầu phải cập nhật code từ branch master về branch của bạn. Bởi vì sau một thời gian team bạn làm việc, develop branch đã có code của các thành viên khác và nó có thể sẽ ảnh hưởng đến code của bạn.

Code của master đã được merge feature2, yêu cầu sẽ là cập nhật code master vào feature1. Trong branch master sẽ có 4 commit như sau:

Tương ứng với feature1:

Và feature2:

Git merge:

Dựa vào log bên trên bạn có thể thấy tất cả các commit của feature2 sẽ được đặt lên trên của feature1 và master. Và bạn cũng có thể thấy các commit id không hề thay đổi so với ban đầu. Tuy nhiên khi thực hiện git merge, sẽ có thêm một commit tự động có tên là Merge branch xxx into yyy. Commit này là cần thiết đối với git merge, làm cho git merge trở nên an toàn hơn, tuy nhiên nhiều người đánh giá rằng commit này sẽ làm làm cho git history trở nên rối rắm, và không đẹp mắt.

Minh họa của git merge:

Git rebase:

Dựa vào log bên trên bạn có thể thấy commit của feature1 sẽ được đẩy lên lên so với commit của master. Và commit id của các commit của feature bị thay đổi. Rebase giúp cho git history của bạn tuyến tính, không có commit nào không liên quan làm rối git history. Tuy nhiên việc commit id bị thay đổi có thể dẫn đến việc bị conflicts không cần thiết, có thể dẫn đến mất code nếu như version cũ và version mới của commit được merge vào nhau. Điều này có thể được loại bỏ nếu như tuân thủ theo nguyên tắc vàng của git rebase:

Never use git rebase on public branches

Minh họa về git rebase:

Ngoài ra có một tính năng của git rebase được áp dụng ở nhiều công ty để có một git history gọn gàng, sạch sẽ hơn, đó là squash. Tính năng này cho phép bạn gộp 2 hoặc nhiều commit không cần thiết thành 1 commit, ví dụ:

Sau đó bạn sẽ thấy một text editor hiển thị danh sách các commit mà bạn muốn gộp. Pick 1 commit gốc, những commit còn lại bạn để là s như trong hình. Ấn nút Esc để ngừng sửa file, sau đó điền :wq + Enter. Một text editor khác hiện ra để bạn thiết lập commit message cho commit mới này.

Sau đó lại tiếp tục ấn Esc, điền :wq + Enter. Việc squash dã hoàn tất. Tuy nhiên có một vấn đề mà bạn phải đánh đổi khi sử dụng rebase, đó là khi bạn push trở lại remote repository, bạn sẽ cần phải thêm force push. Điều này tiềm ẩn nhiều rủi ro, đặc biệt là đối với những bạn developer mới, chưa có nhiều kinh nghiệm với Git.

Tóm lại, Git merge là một phương án an toàn, và dễ tiếp cận hơn so với Git rebase, nhưng lại làm cho git history trở nên rối rắm, trong khi đó, Git rebase sẽ giúp cho git history trở nên ngắn hơn và clean hơn. Việc sử dụng Git merge và Git rebase hoàn toàn phụ thuộc vào nhu cầu của từng dự án.