PENALGO

Giao diện

2. Merge vs Rebase ​

IMPORTANT

THE GREAT DEBATE: Đây là chủ đề gây tranh cãi nhất trong giới lập trình. Tại PENALGO, chúng ta có quy tắc rõ ràng.

2.1 Visual Concepts (Prof. Tom) ​

Merge (Hợp nhất) ​

Tạo ra một "Diamond Shape" (Hình thoi). Nó giữ lại sự thật lịch sử là "tôi đã tách ra ở đây và gộp lại ở kia".

Ưu điểm: Trung thực. Nhược điểm: Rối rắm nếu team có 20 người cùng merge.

Rebase (Tái cấu trúc) ​

Tạo ra một "Straight Line" (Đường thẳng). Nó viết lại lịch sử như thể bạn chưa bao giờ tách nhánh, mà đợi code mới nhất về rồi mới bắt đầu làm (dù thực tế bạn làm song song).

(Tất cả nằm trên một đường thẳng tắp)

Ưu điểm: Lịch sử sạch sẽ, dễ revert, dễ debug. Nhược điểm: Nguy hiểm nếu dùng sai (làm mất commit của người khác).

2.2 HPN's Law: Khi nào dùng cái gì? ​

CAUTION

GOLDEN RULE: Không bao giờ Rebase trên Public Branch (như main, develop). Chỉ Rebase trên branch cá nhân của bạn (feature/...).

Quy trình chuẩn tại Enterprise:

  1. Trên máy cá nhân (Local): Dùng Rebase. Mục đích: Để dọn dẹp code của bạn, update code mới nhất từ main về branch của bạn mà không tạo ra các "merge commit" thừa thãi.

    bash
    git checkout feature/login
git pull --rebase origin main

  2. Khi gộp vào nhánh chính (Shared): Dùng Merge (thường là qua Pull Request/Merge Request trên giao diện Web). Mục đích: Để đánh dấu mốc "Tính năng này đã hoàn thành và được gộp vào".

Summary ​

Hành độngLệnh khuyên dùngTại sao?
Update code mới từ server về branch mìnhgit pull --rebaseGiữ lịch sử thẳng.
Gộp code của mình vào mainPull Request (Merge)Giữ dấu vết tích hợp.

2.3 Large Team Workflow ​

Khi làm việc trong team lớn, việc review code trước khi merge là bắt buộc. Đôi khi bạn muốn Lead review code trên máy của họ trước khi bạn push lên server.

HPN's Tip: Dùng Penrift Tunnel để expose local server hoặc share git patch nhanh chóng cho đồng nghiệp review mà không cần push commit rác lên remote.

🧠 Quiz

Câu 1: "Golden Rule" của Git Rebase là gì? ​

  • [ ] A) Luôn rebase trước khi merge
  • [ ] B) Chỉ rebase trên branch main
  • [x] C) Không bao giờ rebase trên public/shared branch, chỉ rebase trên branch cá nhân
  • [ ] D) Luôn dùng --force sau khi rebase

💡 Giải thích: Rebase viết lại lịch sử commit (thay đổi SHA). Nếu rebase trên shared branch (main, develop), sẽ gây conflict cho tất cả người đã pull branch đó. Chỉ rebase trên branch cá nhân (feature/...).

Câu 2: Quy trình chuẩn Enterprise khi cập nhật feature branch với code mới từ main là gì? ​

  • [ ] A) git merge main vào feature branch
  • [x] B) git pull --rebase origin main trên feature branch
  • [ ] C) Xóa feature branch và tạo lại từ main
  • [ ] D) git reset --hard origin/main

💡 Giải thích: Dùng git pull --rebase origin main để đặt commits của bạn lên trên code mới nhất từ main, giữ lịch sử tuyến tính. Khi gộp vào main thì dùng Pull Request (Merge) để giữ dấu vết tích hợp.

Câu 3: Sự khác biệt chính giữa Merge và Rebase về mặt lịch sử commit? ​

  • [ ] A) Merge nhanh hơn Rebase
  • [ ] B) Rebase giữ lại tất cả merge commit
  • [x] C) Merge tạo merge commit (non-linear), Rebase tạo lịch sử tuyến tính (linear)
  • [ ] D) Không có sự khác biệt về lịch sử

💡 Giải thích: Merge tạo một merge commit mới kết nối hai nhánh (lịch sử non-linear dạng diamond). Rebase "replay" commits lên đầu target branch, tạo ra lịch sử tuyến tính sạch đẹp nhưng viết lại SHA của commits.

📚 Bài liên quan

Professional Engineering Standards | © 2025 HPN Corporation