Phép thuật Pull Requests

1. Từ merge tới đề xuất: tại sao cần Pull Requests?

Trong bài trước chúng ta đã học cách merge các nhánh trên máy cục bộ. Cách này ổn khi bạn làm một mình. Nhưng nếu cả một nhóm cùng làm trên dự án thì sao? Nếu ai cũng merge thay đổi trực tiếp vào nhánh chính main, sớm muộn sẽ thành hỗn loạn: có người vô tình thêm code lỗi, phá build hoặc xóa mất phần việc quan trọng của đồng nghiệp.

Để tránh điều đó, trong phát triển nhóm có một cách tiếp cận khác. Thay vì merge ngay lập tức, bạn tạo một đề xuất để merge. Đề xuất này gọi là Pull Request (gọi tắt là PR) hoặc trên một số nền tảng gọi là Merge Request.

Pull Request — là một yêu cầu chính thức: "Làm ơn pull các thay đổi của mình từ nhánh của mình và merge chúng vào nhánh chính". Nhưng đó không chỉ là yêu cầu, mà là một nền tảng để thảo luận, kiểm tra và cải thiện code trước khi nó vào main.

2. Quy trình làm việc tiêu chuẩn với Pull Request

Hãy đi qua từng bước để thấy quy trình điển hình khi tạo một tính năng mới.

Trước khi tạo nhánh cho task mới, đảm bảo bạn đã push tất cả commit hoàn chỉnh và cập nhật (Update Project) nhánh chính main.

Nếu không, tất cả commit "bị quên" trên máy của bạn trong main có thể vô tình rơi vào Pull Request mới, gây rối cho đồng đội.

Bước 1. Tạo nhánh cho task mới.

Như trước, mọi công việc mới đều bắt đầu bằng việc tạo nhánh riêng. Giả sử ta muốn thêm file hướng dẫn cho contributors. Tạo nhánh feature/add-contribution-guide.

Bước 2. Thay đổi và push nhánh lên GitHub.

Trong nhánh mới tạo file CONTRIBUTING.md (sau khi tạo nhấn Add) và viết lời nhắn cho các dev khác. Sau đó làm Commit and Push với message rõ ràng, ví dụ: docs: Add contribution guide.

Đây là bước then chốt! Pull Request được tạo dựa trên nhánh đã tồn tại trên remote. Vì vậy, trước khi tạo PR bạn phải push nhánh mới lên GitHub.

3. Tạo Pull Request từ IntelliJ IDEA

Bây giờ nhánh của bạn đã lên GitHub, có thể tạo Pull Request.

Bước 1. Mở tab Pull Requests.

Bên trái trong IDE có tab Pull Requests. Mở nó và nhấn biểu tượng + để tạo PR mới.

Bước 2. Điền thông tin cho PR.

IDE sẽ mở giao diện tiện lợi để tạo Pull Request. Nhiệm vụ của bạn là điền nó hợp lý. Hãy xem các trường chính:

1. Tiêu đề: IDE thường điền tên nhánh vào đây, nhưng đó là thói quen không tốt. Tiêu đề nên ngắn gọn, rõ ràng và phản ánh bản chất thay đổi, giống như một commit message tốt.
2. Mô tả: ở đây bạn giải thích cái gì và tại sao bạn làm.
3. Reviewers: chọn một hoặc vài đồng nghiệp sẽ review code bạn. Trong dự án học có thể bỏ qua, nhưng trong thực tế bước này bắt buộc.
4. Assignees: thường bạn ghi chính bạn. Điều này nghĩa là bạn là tác giả và chịu trách nhiệm chính cho task này và cho việc sửa theo review.

Sau khi điền xong các trường, nhấn Create Pull Request.

4. Code-review: kiểm tra và thảo luận

Sau khi tạo PR, bước quan trọng nhất bắt đầu — code-review (code review). Đồng nghiệp có thể mở PR của bạn, xem tất cả thay đổi và để lại comment.

Bạn có thể thấy mọi thảo luận ngay trong IDE ở tab Pull Requests. Nếu ai đó để lại comment, bạn sẽ nhận thông báo.

Phải làm gì khi được yêu cầu chỉnh sửa?

Rất đơn giản! Không cần tạo PR mới. Chỉ cần chỉnh code trong cùng nhánh, commit và push. Pull Request trên GitHub sẽ tự động cập nhật, thêm các commit mới của bạn.

5. Hoàn tất công việc: merge và xóa nhánh

Khi mọi comment đã được sửa và team đồng ý với thay đổi, Pull Request có thể được merge. Thường người senior hoặc chính bạn (nếu có quyền) sẽ thực hiện.

Bước 1. Merge

Merge thường diễn ra trên website GitHub. Ở PR sẽ có nút màu xanh lớn Merge pull request. Sau khi nhấn, code của bạn sẽ vào nhánh chính main.

Bước 2. Xóa nhánh.

Sau khi merge, nhánh `feature` của bạn không còn cần nữa, nên xóa để repository đỡ bừa. GitHub sẽ gợi ý bằng nút Delete branch.

Đừng quên xóa bản sao nhánh ở local trong IDE để giữ ngăn nắp. Có thể làm qua menu quản lý nhánh.

6. Ba quy tắc commit

Một commit tốt không chỉ là message đúng mà còn nội dung đúng. Để lịch sử thay đổi sạch, hữu ích và chuyên nghiệp, tuân theo ba quy tắc đơn giản.

Quy tắc 1: viết message rõ ràng theo chuẩn

Commit của bạn là thông điệp gửi tới team và chính bạn trong tương lai. Lịch sử đầy message như "fix" hoặc "update" vô nghĩa. Chuẩn phổ biến nhất là Conventional Commits. Nó đề xuất cấu trúc:

<type>: <short description>

Type — một từ ngắn mô tả loại thay đổi:

• feat: (feature) — cho tính năng mới.
• fix: — cho sửa lỗi.
• docs: — cho thay đổi tài liệu.
• style: — cho chỉnh format, không ảnh hưởng logic.
• refactor: — cho thay đổi code không thêm tính năng và không sửa lỗi.
• test: — cho thêm hoặc sửa tests.
• chore: — cho công việc thường nhật, không liên quan trực tiếp code (cập nhật dependency, cấu hình build).

Ví dụ:

• Tệ: fixed bug
• Tốt: fix: Correct user login validation

• Tệ: readme
• Tốt: docs: Update installation instructions

Quy tắc 2: một commit — một thay đổi logic (Tính nguyên tử)

Đừng cố nhồi sửa bug, thêm feature và refactor vào một commit. Commit như vậy khó review và hầu như không thể revert an toàn nếu có vấn đề.

Mỗi commit nên giải quyết đúng một công việc cụ thể.

• Tệ: một commit với message "Update user page", trong đó thêm field avatar, sửa lỗi validate tên và đổi màu nút.
• Tốt: ba commit riêng:
  1. feat: Add avatar upload to user profile
  2. fix: Correct username validation logic
  3. style: Update button colors on user page

Commits nhỏ, tập trung dễ hiểu và quản lý hơn nhiều.

Quy tắc 3: Commit không được phá vỡ project

Mỗi commit trên nhánh chính phải để project trong trạng thái chạy được. Trước khi commit bạn nên ít nhất chắc rằng code biên dịch được. Nhưng làm sao biết mình không vô tình phá phần khác của hệ thống? Chỉ tin vào kiểm tra thủ công là rủi ro.

Ở đây automation giúp ích. Trong khóa học này ta không cấu hình CI, nhưng bạn nên biết cách nó hoạt động trong dự án thật. Các team hiện nay dùng hệ thống Continuous Integration (CI) như GitHub Actions.

Nó hoạt động thế nào?

Bạn viết code và tests. Rồi cấu hình một workflow trên GitHub. Khi bạn push vào Pull Request, sẽ có "phép thuật":

1. GitHub Actions nhận sự kiện và chạy workflow.
2. Nó tự động "build" dự án và chạy tất cả tests.
3. Nếu tất cả tests pass, cạnh commit trên GitHub sẽ hiện dấu tích xanh. Đó là tín hiệu cho team rằng thay đổi an toàn.
4. Nếu ít nhất một test fail, bạn sẽ thấy dấu chéo đỏ. Merge PR như vậy vào nhánh chính là bị cấm.

            graph LR
            subgraph GitHub
            A[Developer] -- "push" --> B(Repository)
            B -- "Event: push" --> C{GitHub Actions}
            end

            subgraph Workflow
            C -- "Run" --> D[Run Test]
            D --> E[Uspeshno]
            D --> F[Neuspeshno]
            end

            subgraph Notifications
            F --> G((Email))
            G --> H[Developer]
            G --> I[Team]
            end

            style F fill:#f99,stroke:#333,stroke-width:2px
            style G fill:#ccf,stroke:#333,stroke-width:2px
        

Có thể cấu hình thông báo. Nếu tests fail, GitHub Actions có thể gửi email cho bạn hoặc cả team. Cách làm này tạo văn hóa nơi tests không phải thủ tục, mà là một phần không thể thiếu của phát triển, và ai cũng chịu trách nhiệm về chất lượng code của mình.