Forking Workflow: Bí kíp “sinh tồn” khi code team lớn và Open Source – ITFROMZERO

Table of Contents

2 giờ sáng và cơn ác mộng mang tên ‘Merge Conflict’

Mình vẫn nhớ như in cái đêm đó. Cả team đang gồng mình chuẩn bị cho đợt release lớn vào sáng hôm sau. Một bạn dev mới, do chưa quen quy trình, đã lỡ tay push thẳng code lỗi vào nhánh chính của repo trung tâm. Kết quả là pipeline đỏ rực, server sập hoàn toàn. Mình mất trắng 4 tiếng đồng hồ chỉ để mò mẫm dọn dẹp bãi chiến trường đó giữa đêm khuya.

Sau cú sốc ấy, mình rút ra bài học đắt giá. Với team từ 10-15 người hoặc các dự án Open Source có hàng trăm người đóng góp, dùng chung một repo (Centralized Workflow) là tự sát. Bạn cần Forking Workflow. Nếu không muốn thức trắng đêm fix những lỗi ngớ ngẩn từ trên trời rơi xuống, đây chính là quy trình dành cho bạn.

Triển khai Forking Workflow trong 5 phút

Quy trình này không cần công cụ gì phức tạp vì nó dựa trên cơ chế phân quyền sẵn có của Git. Giả sử dự án gốc của công ty bạn đặt tại company/core-app.

Fork repo: Click nút Fork trên GitHub để copy toàn bộ dự án về tài khoản cá nhân (ví dụ: your-name/core-app).

Clone về máy:

git clone https://github.com/your-name/core-app.git
cd core-app

Cấu hình Upstream: Đây là bước then chốt để đồng bộ code sau này.
```
git remote add upstream https://github.com/company/core-app.git
```
Tạo nhánh mới: Tuyệt đối không bao giờ code trực tiếp trên nhánh main.
```
git checkout -b feature/optimize-database
```
Đẩy code và tạo Pull Request (PR):
```
git add .
git commit -m "feat: optimize user query performance"
git push origin feature/optimize-database
```
Cuối cùng, bạn lên giao diện web và nhấn Create Pull Request để gửi yêu cầu trộn code sang repo gốc.

Tại sao các dự án nghìn sao lại ‘cuồng’ Forking Workflow?

Sự khác biệt lớn nhất nằm ở chỗ mỗi developer sở hữu một server riêng biệt. Bạn có toàn quyền kiểm soát không gian làm việc của mình.

Lớp giáp bảo vệ tuyệt đối

Trong mô hình này, chỉ Maintainer (người quản trị) mới có quyền ghi vào repo gốc. Bạn có lỡ tay “phá nát” repo cá nhân cũng chẳng sao. Nó không ảnh hưởng đến dự án chung. Code chỉ được trộn vào nhánh chính sau khi các senior đã soi từng dòng và chạy thử test kỹ càng.

Phân biệt Upstream và Origin

Nhiều bạn mới làm quen hay bị lú chỗ này. Hãy nhớ quy tắc đơn giản này:
– Origin: Là “nhà riêng” của bạn trên cloud (cái repo bạn đã fork). Bạn thích làm gì ở đây cũng được.
– Upstream: Là “nhà chung” (repo gốc của công ty). Bạn chỉ có quyền lấy code về (fetch/pull) chứ không được phép đẩy trực tiếp lên.

Kỹ thuật đồng bộ code không gây xung đột

Ở các dự án lớn, việc 50 người cùng sửa một file là chuyện thường ngày. Nếu bạn fork repo từ tháng trước, code ở Upstream có khi đã chạy xa hàng nghìn commit rồi. Nếu push PR ngay lúc này, tỉ lệ ăn Conflict đỏ lòm là 99%.

Ưu tiên Rebase thay vì Merge

Hồi đầu mình hay dùng git pull upstream main, nhưng nó tạo ra một đống Merge commit rác làm rối loạn lịch sử dự án. Giờ mình luôn dùng Rebase để giữ lịch sử code đẹp và phẳng lỳ:

# Cập nhật code mới nhất từ nhà chung về máy
git checkout main
git fetch upstream
git rebase upstream/main

# Áp code mới vào nhánh đang làm việc
git checkout feature/optimize-database
git rebase main

Cách làm này giúp nhánh của bạn trông như vừa được tách ra từ bản mới nhất của dự án. Người review sẽ cực kỳ cảm kích vì code rất dễ đọc.

Tai nạn 2 giờ sáng với Force Push

Một lần nọ, sau khi rebase xong, mình dùng git push --force để cập nhật PR. Do quá mệt, mình gõ nhầm thế nào lại force push đè vào nhánh develop chung của cả team. Kết quả? Mình xóa sạch công sức của 3 người khác vừa merge vào trước đó.

Kể từ đó, mình rút ra hai kinh nghiệm sống còn:

Luôn dùng git push --force-with-lease. Lệnh này thông minh hơn vì nó sẽ từ chối nếu có ai đó đã cập nhật code trên server mà bạn chưa biết.
Dù là Admin có quyền tối cao, mình vẫn dùng Forking Workflow để tự bảo vệ mình khỏi những phút giây lú lẫn.

Mẹo thực chiến cho dự án chuyên nghiệp

Đặt tên nhánh có tâm: Thay vì đặt fix-bug chung chung, hãy dùng fix/issue-502-bad-gateway.
Squash commit: Đừng bắt đồng nghiệp đọc 20 cái commit kiểu ‘fix typo’, ‘update lại’. Hãy gộp chúng thành một commit duy nhất chứa trọn vẹn tính năng.
PR nhỏ thôi: Một PR sửa 100 file là thảm họa cho người review. Hãy chia nhỏ PR ra, mỗi cái chỉ giải quyết đúng một vấn đề.

Mới đầu, Forking Workflow nhìn có vẻ cồng kềnh vì phải quản lý hai, ba cái remote cùng lúc. Nhưng tin mình đi, khi dự án phình to, đây là cách duy nhất để giữ source code không thành bãi rác. Hy vọng những chia sẻ này giúp bạn tự tin hơn khi gia nhập các dự án lớn hoặc đóng góp cho cộng đồng Open Source.