Thực hành: Rebase vs Merge Workflow

🎯 Mục tiêu

🎯 Sau bài thực hành này, bạn sẽ:

• Hiểu sự khác biệt giữa rebase và merge
• Nắm vững Golden Rule of Rebase
• Dùng interactive rebase để dọn lịch sử trước khi merge

Phần 1: Trắc nghiệm

🧠 Quiz

Câu 1: "Golden Rule of Rebase" là gì?

• [ ] A) Luôn rebase trước khi merge để có lịch sử sạch
• [ ] B) Chỉ rebase trên branch main để giữ lịch sử tuyến tính
• [x] C) Không bao giờ rebase branch đã được push và người khác đang dùng
• [ ] D) Rebase tối đa 3 commit một lần để tránh conflict

💡 Giải thích: Rebase viết lại lịch sử — tạo commit mới với SHA khác. Nếu branch đã được share, người khác đang làm việc dựa trên các commit cũ. Rebase sẽ gây ra divergent history, buộc team phải force pull — rất dễ mất code.

🧠 Quiz

Câu 2: git rebase -i HEAD~3 cho phép bạn làm gì?

• [ ] A) Rebase 3 branch gần nhất lên HEAD
• [ ] B) Quay lại 3 commit trước và xóa hết thay đổi
• [x] C) Mở editor để sắp xếp lại, gộp, sửa hoặc bỏ 3 commit gần nhất
• [ ] D) Tạo 3 branch mới từ HEAD

💡 Giải thích: Interactive rebase (-i) mở editor với danh sách commit. Mỗi commit có action: pick (giữ), squash (gộp vào commit trước), reword (sửa message), edit (dừng để sửa code), drop (xóa). Đây là công cụ mạnh để dọn lịch sử trước khi tạo Pull Request.

🧠 Quiz

Câu 3: Khi nào nên chọn merge thay vì rebase?

• [ ] A) Khi muốn lịch sử commit sạch và tuyến tính
• [x] B) Khi muốn giữ nguyên ngữ cảnh lịch sử phát triển và merge commit là điểm hội tụ rõ ràng
• [ ] C) Khi branch chỉ có 1 commit
• [ ] D) Khi làm việc một mình trên dự án cá nhân

💡 Giải thích: Merge giữ nguyên lịch sử thật — bạn thấy rõ khi nào feature branch được tạo, phát triển ra sao, và merge lúc nào. Phù hợp cho shared branches, release tracking, và khi audit trail quan trọng. Rebase phù hợp cho local cleanup trước khi push.

Phần 2: Sắp xếp thứ tự lệnh

🧩 Parsons Problem

Bài 1: Rebase feature branch lên main trước khi tạo Pull Request

Sắp xếp các bước đúng thứ tự:

1. git checkout feature/search — chuyển sang feature branch
2. git fetch origin — lấy thay đổi mới nhất từ remote
3. git rebase origin/main — đặt lại base của feature lên main mới nhất
4. Giải quyết conflict nếu có, rồi git rebase --continue
5. git rebase -i HEAD~4 — gộp các commit WIP thành commit có ý nghĩa
6. git push --force-with-lease — push lịch sử đã rewrite lên remote
7. Tạo Pull Request trên GitHub

Phần 3: Bài tập tình huống

Scenario: Chọn chiến lược đúng cho team

Bối cảnh: Team 4 developers, e-commerce app. 3 tình huống cần quyết định rebase hay merge:

Tình huống A: Feature branch feature/cart chưa push. main có 5 commit mới. Muốn cập nhật.

Đáp án: Dùng rebase — branch chưa push, chỉ bạn làm việc. Lịch sử sạch hơn.

Tình huống B: Branch release/v2.0 đã được push và 3 người đang develop trên đó. Branch main có hotfix quan trọng cần đưa vào release.

Đáp án: Dùng merge — branch đã shared. Rebase viết lại lịch sử gây xung đột cho cả team.

Tình huống C: 6 commit trên feature branch (3 "WIP", 2 "fix typo", 1 thật sự). Sắp tạo PR.

Đáp án: Dùng interactive rebase gộp 6 commit thành 1-2 commit có ý nghĩa. git rebase -i HEAD~6 + squash.

Tổng kết quy tắc

Tình huống	Chiến lược	Lý do
Branch local chưa push	Rebase	Lịch sử sạch, không ảnh hưởng ai
Branch đã share với team	Merge	Không viết lại lịch sử chung
Dọn commit trước PR	Interactive rebase	Commit có ý nghĩa, dễ review
Merge feature vào main	Squash merge	Giữ trace điểm hội tụ

TIP

Nhiều team dùng squash merge khi merge PR — lịch sử main sạch, feature branch giữ chi tiết.