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.

Professional Engineering Standards | © 2025 HPN Corporation