Là một developer hoặc một automation tester, thì có lẽ là bạn sẽ không quá xa lạ với khái niệm về những Pull Requests (PRs). Bạn sẽ thao tác với nó hằng ngày, cùng tương tác với những đồng đội của mình trên những PRs. Bạn có thể tự tạo PRs cho mình, hoặc có thể review những PRs của người khác. Nếu bạn nào chưa biết về khái niệm PRs là gì, thì ở bài này, mình sẽ giải thích nó cũng như những công việc mà lập trình viên cần phải làm từ khi bắt đầu implement code cho đến lúc kết thúc PRs. Nào, chúng ta cùng bắt đầu nhé.
Nội dung
1. Pull request (PR) là gì?
Để nói tới PR, chúng ta không thể không nhắc tới source code của chương trình. Thông thường, một phần mềm được tạo nên bởi nhiều lập trình viên, để có thể đảm bảo tính nhất quán về source code của dự án, chúng ta sẽ cần sử dụng tới những phần mềm quản lí source code, ví dụ như git hoặc svn. Trong số đó, nổi tiếng và quen thuộc nhất với cộng đồng lập trình viên hiện tại có lẽ là git và ứng dụng giúp chúng ta thực thi và tương tác với nó là GitHub.
Khi nhiều lập trình viên cùng làm việc trên cùng một tập source code (thuật ngữ chuyên ngành gọi là repository hay ngắn ngọn là repo), họ sẽ get source code từ repo gốc – được quản lí trên server github – về máy tính cá nhân. Ta gọi source ở máy tính cá nhân là local repo. Hình dung đơn giản bằng hình ảnh sau đây:
Thông thường, source code chính của project thường được để trong nhánh (thuật ngữ là branch) có tên gọi là main hoặc master. Khi phát triển một tính năng mới, nhưng lại tránh thay đổi source code đang có của nhánh master, lập trình viên sẽ tạo ra các nhánh con, ví dụ: nhánh feature_A, nhánh feature_B … Sau đó sẽ tạo thêm source code mới vào các nhánh con này, trong khi deveper làm tính năng mới thì nhánh master sẽ không bị thay đổi gì cả, vì thế mà trong lúc họ làm, phần mềm vẫn chạy bình thường. Minh họa bằng sơ đồ sau:
Khi lập trình viên viết code xong cho những feature mà mình phụ trách, họ sẽ tạo những Pull Request (minh họa ở trên là PR-1 và PR-2) với mục đích kĩ thuật là để gộp mã nguồn mới vào mã nguồn cũ (thuật ngữ chuyên môn gọi là merge source). Bên cạnh đó, PRs cũng để thông báo với đồng đội rằng: tôi đã làm xong và sẵn sàng gộp chung source code mới (của tính năng mới) vào phần mềm đang chạy, để bổ sung tính năng mới cho sản phẩm.
2. Quá trình các bước tạo Pull Request
Quá trình tạo Pull Request thường bao gồm các bước sau:
- Tạo một branch mới: Trước khi bắt đầu chỉnh sửa/ tạo mới source code, bạn nên tạo một branch mới để làm việc trên đó. Điều này đảm bảo rằng các thay đổi của bạn không ảnh hưởng đến source code chính của dự án.
- Chỉnh sửa/tạo mới source code: Tiếp theo, bạn sẽ chỉnh sửa/tạo mới source code trên branch mới của mình. Bạn có thể thêm, sửa đổi hoặc xóa bất kỳ file nào tùy ý, tùy theo mục đích của bạn.
- Commit thay đổi: Sau khi bạn hoàn thành, bạn sẽ phải commit các thay đổi vào branch mới của mình. Mỗi commit sẽ đại diện cho một bản sao của source code với các thay đổi mới của bạn.
- Tạo Pull Request: Khi các thay đổi của bạn đã được commit vào branch mới, bạn có thể tạo Pull Request để gộp các thay đổi của mình vào nhánh chính của dự án. Trong quá trình tạo Pull Request, bạn sẽ cung cấp thông tin về các thay đổi của mình và mô tả về mục đích của các thay đổi đó.
- Xem xét và thảo luận (Review): Các đồng đội khác trong team sẽ review các thay đổi của bạn trong Pull Request. Họ có thể đưa ra các ý kiến, đề xuất sửa đổi hoặc chỉnh sửa thêm để tăng tính ổn định và hiệu quả của mã nguồn.
- Merge Pull Request: Cuối cùng, sau khi các thay đổi đã được xem xét và chấp nhận, bạn có thể merge Pull Request vào nhánh chính của dự án. Khi Pull Request được merge, các thay đổi của bạn sẽ được merge vào nhánh chính và được phát hành trong phiên bản tiếp theo của dự án.
3. Tạo pull request trong GitHub
Sau khi code xong, chúng ta sẽ push code lên branch của mình trên remote repository. Lúc này, chúng ta cần phải tạo pull request để leader của mình có thể review mà merge code vào nhánh chính master.
Giả sử ở đây mình đang làm việc trên branch với name là branch1. Bây giờ, mình sẽ open branch này trên GitHub. Trên GitHub UI, các bạn hãy click vào button Compare & pull request
Ở bước tiếp theo, bạn hãy input description cho lần pull request này.
Cũng trong page này, các bạn sẽ xem được những thay đổi mà mình đã push lên. Ở đây, do mình chỉ add file mà không input nội dung gì, nên đoạn text “Empty file.” sẽ hiển thị ở đây.
Tiếp theo, bạn hãy click vào button Create pull request.
Lúc này, leader hoặc đồng đội của bạn sẽ review những thay đổi của bạn. Nếu mọi thứ OK, họ sẽ tiến hành merge code của bạn vào nhánh chính master bằng cách click vào button Merge pull request -> Confirm merge. Còn nếu có vấn đề gì đó, ví dụ như bạn code sai, hoặc nó chưa đúng logic lắm, thì lúc này bạn phải update và thực hiện pull request lại 1 lần nữa.
4. Những tác dụng của Pull Requests
Như đã giải thích ở trên, các PRs là các khái niệm hoàn toàn mang tính kĩ thuật: giúp ta gộp chung code mới vào code cũ. Với một khái niệm hoàn toàn mang tính kĩ thuật như vậy, chúng ta liệu có học hỏi được nhiều bài học từ nó? Nếu bạn còn thắc mắc như vậy thì để mình nói cho bạn nghe thêm vài tác dụng khác của PRs nhé.
4.1. Nhờ người khác kiểm tra lại source code (review)
Khi bạn tạo ra một PR để yêu cầu merge code, bạn chỉ mới thực hiện được một nửa quá trình, PR còn cần phải được “xác nhận” lại lần cuối trước khi được merge vào nhánh chính.
Ở bước “xác nhận” này, bạn có thể nhờ một người khác trong nhóm của bạn – người có thể có nhiều kinh nghiệm – kiểm tra lại PR đó xem coi những đoạn mã lệnh bạn viết trong tính năng mới có ổn hay không, có thực thi đúng chức năng và nhiệm vụ không, có đạt hiệu suất cao hay không, có bảo mật hay không, … Khi những tiêu chí về chất lượng code được kiểm tra và đảm bảo, tính năng mới, thì mới chính thức được merge vào sản phẩm. Công việc kiểm tra này được gọi bằng thuật ngữ là review.
Từ cái nhìn trên, có thể hiểu PR là một thứ thể hiện cho kiến thức và kĩ năng của bạn, việc nhờ người khác nhận xét và kiểm tra, bạn sẽ hạn chế được lỗi (nếu có) phát sinh trong quá trình viết code, cũng như sẽ rút ra được nhiều bài học mới và vấn đề mới cần cải thiện.
4.2. Lưu lại lịch sử phát triển của sản phẩm
Sau khi PRs được merge vào nhánh chính của project, thông tin về nó sẽ không bị mất đi. Phần mềm quản lí source code sẽ tiếp tục lưu lại thông tin về những PRs trong dữ liệu của nó, những thông tin thay đổi về source code chi tiết tới từng dòng đều được lưu lại để thực hiện truy vấn lại sau này. Nói một cách khác, quá trình phát triển của sản phẩm được ghi lại một cách rõ ràng và chi tiết thông qua những PRs.
4.3. Là cơ hội giúp bạn học hỏi từ người khác
Bạn vẫn luôn được những lập trình viên có kinh nghiệm khuyên rằng: cách tốt nhất để phát triển kĩ năng của mình là phải làm thật nhiều. Sự thật là vậy, bạn càng viết code nhiều, luyện tập thiết kế cách tính năng khác nhau thì sẽ càng mau giỏi. Nhưng vấn đề là, khi bạn còn chưa có nhiều kinh nghiệm, leader hoặc cấp trên của bạn nào dám đưa cho bạn phụ trách những tính năng lớn, những tính năng phức tạp.
Khi bạn không được trao vai trò chính trong việc phát triển và trở thành người tạo ra những PR, bạn vẫn có thể học hỏi từ nó, bằng cách đóng góp những commits nhỏ trong PR, trở thành người kiểm tra Pull Request (gọi là reviewer), hay đơn thuần chỉ là người đọc qua những sự thay đổi của mã nguồn từ những PRs.
Khi làm việc với những nhóm lớn, sẽ có rất nhiều PRs được tạo ra trong quá trình phát triển sản phẩm, những PRs chứa đựng giải pháp cho những điều bạn có thể chưa biết, tham khảo những PRs này cũng sẽ giúp bạn học thêm được rất nhiều điều mới mẻ và có ích cho sự phát triển của bạn.
5. Lời kết
Như vậy, Pull Request không chỉ giúp quản lý các thay đổi trên dự án một cách chặt chẽ hơn mà còn tạo ra một môi trường làm việc phù hợp cho các nhà phát triển. Từ đó, giúp tăng tính hiệu quả và đảm bảo chất lượng của sản phẩm cuối cùng. Nếu bạn đang tham gia vào các dự án phần mềm và chưa sử dụng Pull Request, hãy thử sử dụng công cụ này để cải thiện quá trình làm việc của mình và tối ưu hóa quá trình phát triển sản phẩm.
Nguồn:
https://topdev.vn/blog/chuyen-nhung-pull-requests-trong-lap-trinh/