Pull request và merge request là gì

Khi làm việc với phần mềm quản lý code chắc chắn bạn sẽ phải làm việc với Pull Request, nhất là khi triển khai dự án lớn với nhiều người tham gia.

Pull Request là gì? Công dụng của nó ra sao? Pull Request đem lại lợi ích gì? Tất cả những điều này sẽ được giải đáp bằng bài viết của Bizfly Cloud ngay dưới đây.

Pull request là gì?

Không thể không nhắc tới source code [mã nguồn] của chương trình khi nói về Pull request. Trong thực tế, một phần mềm sẽ được viết bởi nhiều lập trình viên nên để đảm bảo tính đồng nhất của code, phải sử dụng đến các phần mềm quản lý mã nguồn như GitLab, CodeBase… Nhưng nổi tiếng và được nhiều lập trình viên sử dụng nhất là Github.

Mã nguồn chính của sản phẩm được để trong một nhánh chính. Khi phát triển một tính năng mới mà không làm ảnh hưởng tới nhánh chính, coder sẽ tạo ra những nhánh con. Những tính năng mới sẽ được thêm vào nhánh con này. Minh họa bằng sơ đồ sau:

Khi các tính năng mới hoàn thành, người lập trình sẽ tạo Pull request để gộp code mới vào trong mã nguồn cũ [merge source]. Đây cũng là một thông báo cho những người làm chung là bạn đã hoàn thành phần việc của mình sẵn sàng để bổ sung tính năng mới vào sản phẩm.

Cách thức hoạt động của Pull request

Sau khi biết Pull request là gì? Tiếp theo hãy cùng tìm hiểu về cách hoạt động của nó. Pull Request là một đặc trưng của Branch Workflow có cách hoạt động chung như sau:

  • Một lập trình viên sẽ phải tạo một tính năng và họ sẽ tải branch về local repository của họ.
  • Sau khi hoàn thành xong phần việc của mình, họ sẽ phải thực hiện kết nối local repository với repository của team.
  • Lập trình viên sẽ phải tạo ra một Pull Request thông qua phần mềm quản lý code mà nhóm sử dụng.
  • Tất cả thành viên trong nhóm sẽ cùng tranh luận để sửa đổi mã sao cho phù hợp.
  • Sau khi hoàn tất, người leader team sẽ đưa những tính năng và tích hợp chúng vào kho lưu trữ chính và đóng tất cả các Pull request lại.

Lập trình viên sẽ phải tạo ra một Pull Request thông qua phần mềm quản lý code

Lý do nên sử dụng Pull request

Một dự án bất động sản nên cần có số lượng nhân sự rất nhiều nếu xảy ra sự cố về nhân sự, cần phải bổ sung sửa chữa càng nhanh càng tốt. Với lực lượng đông như vậy, chắc chắn sẽ có những người không biết hoặc kiến thức về lập trình còn kém. Từ vấn đề này có những yếu tố sau cần phải xử lý:

  • Thành viên mới chưa hiểu được yêu cầu và kỷ luật của công việc.
  • Nguồn nhân lực không có kinh nghiệm và kỹ năng về lập trình.
  • Nhiều người kém khả năng giao tiếp, trao đổi.

Vì thế, lúc này sẽ cần mang giải pháp để xử lý những vấn đề này như: những buổi training chia sẻ kiến thức và kỹ năng về lập trình, cũng như bàn luận vấn đề gặp trong dự án… Nhưng Pull request có thể gộp hết những giải pháp này thành một phương án duy nhất.

Một số lợi ích của Pull request

Pull request đem lại lợi ích gì và tác dụng ra sao trong các dự án. Sau đây là những điều mà nó mang lại:

  • Nâng cấp source code của dự án phần mềm.
  • Tất cả các thành viên trong team có thể để lại những nhận xét và đóng góp ý kiến cá nhân cho một Pull request của người khác.
  • Chất lượng code sẽ được cải thiện bằng những người có kinh nghiệm để đem lại hiệu quả cao nhất.
  • Với những ý kiến đóng góp của tất cả mọi người giúp những thành viên mới nâng cao kỹ năng lập trình.
  • Cải thiện, nâng cao khả năng trao đổi, tranh luận, giao tiếp và làm việc nhóm.
  • Nó còn có thể lưu lại lịch sử chỉnh sửa để có thể sử dụng lại những tính năng cũ đã bị loại bỏ ở bản mới.
  • Tất cả những thông tin code sẽ được lưu lại khi đóng Pull request.

Pull request nâng cấp source code của dự án phần mềm

Những câu hỏi về Pull request

Sự khác nhau giữa commits của trang compare và Pull request là gì?

Commits tại trang compare thể hiện những sự khác biệt giữa phần đầu reference và branch master tại thời điểm hiện tại. Ở trang Pull request, commits lại thể hiện sự khác nhau giữa phần đầu của reference đầu với branch master của head và base reference tại thời điểm tạo Pull request.

Tài liệu nào nói về cách Pull Request hoạt động?

Để tìm hiểu Pull request là gì hay cách hoạt động của nó, bạn có thể tham khảo nội dung Making a Pull Request của Atlassian Corporation Plc – đây là công ty đã nghiên cứu và phát triển ứng dụng quản trị source code Bitbucket. Người viết tài liệu này đã đưa ra một cách giải thích về các vấn đề đơn giản nhất, cho bất kỳ ai kể cả người không có kiến thức về lập trình cũng có thể hiểu được.

Có những phần mềm quản lý mã nguồn hiệu quả nào ngoài Github?

Github là phần mềm nổi tiếng được nhiều người sử dụng nhất. Tuy nhiên trên thị trường có những ứng dụng để quản lý mã nguồn khác cũng cực kỳ tốt như: Bitbucket, CodeBase, Gitlab…

Có nên sử dụng Bitbucket hay ko?

Trong khi GitHub đi kèm với rất nhiều tính năng và cho phép bạn tạo quy trình làm việc của riêng mình, Bitbucket được cho là có tích hợp sẵn nên sẽ linh hoạt hơn. Bitbucket hoàn toàn miễn phí cho tối đa năm người dùng.

Điều này bao gồm các kho lưu trữ riêng tư không giới hạn và bạn cũng có thể có các kho lưu trữ công khai không giới hạn, nên hầu như không có gì ngạc nhiên khi có một số dự án mã nguồn mở lớn trên nền tảng này. Bitbucket cũng cung cấp kho lưu trữ riêng không giới hạn và hoàn toàn miễn phí cho giáo viên và sinh viên.

Bitbucket còn được tích hợp Jira. Đây là một tính năng được xây dựng như một công cụ theo dõi lỗi, nhưng bây giờ nó được sử dụng rất linh hoạt cho các tác vụ như theo dõi sự cố, phân phối bàn dịch vụ và quản lý dự án.

Qua những thông tin được đề cập ở phía trên chắc bạn đã hiểu Pull request là gì rồi đúng ko nào. Khi mới vào nghề chắc hẳn những công cụ quản trị mã nguồn như Bitbucket hay Github đã khiến bạn tốn kha khá thời gian để làm quen với những tính năng Repository, Pull request… Mong rằng những kiến thức này sẽ giúp bạn tiến xa hơn trên con đường trở thành lập trình viên chuyên nghiệp.

BizFly Cloud là nhà cung cấp dịch vụ điện toán đám mây với chi phí thấp, được vận hành bởi VCCorp.

BizFly Cloud là một trong 4 doanh nghiệp nòng cốt trong "Chiến dịch thúc đẩy chuyển đổi số bằng công nghệ điện toán đám mây Việt Nam" của Bộ TT&TT; đáp ứng đầy đủ toàn bộ tiêu chí, chỉ tiêu kỹ thuật của nền tảng điện toán đám mây phục vụ Chính phủ điện tử/chính quyền điện tử.

Độc giả quan tâm đến các giải pháp của BizFly Cloud có thể truy cập tại đây.

DÙNG THỬ MIỄN PHÍ và NHẬN ƯU ĐÃI 3 THÁNG tại: Manage.bizflycloud

GitLab 12.1 [July 2019] introduces a difference:

"Merge Requests for Confidential Issues"

When discussing, planning and resolving confidential issues, such as security vulnerabilities, it can be particularly challenging for open source projects to remain efficient since the Git repository is public.

As of 12.1, it is now possible for confidential issues in a public project to be resolved within a streamlined workflow using the Create confidential merge request button, which helps you create a merge request in a private fork of the project.

See "Confidential issues" from issue 58583.

A similar feature exists in GitHub, but involves the creation of a special private fork, called "maintainer security advisory".

GitLab 13.5 [Oct. 2020] will add reviewers, which was already available for GitHub before.

Nếu bạn đã trở thành một lập trình viên, làm việc theo team, hoặc bạn đã từng sử dụng qua những công cụ quản lí mã nguồn [git, svn, …], có lẽ bạn sẽ không quá xa lạ với khái niệm về những Pull Requests [PRs]. Bạn làm việc với nó hằng ngày, cùng tương tác với những đồng nghiệp của mình trên những PRs, bạn tự tạo những PRs cho mình hoặc kiểm tra những PRs của người khác, … nhưng bạn có hiểu hết hoặc tận dụng hết những ý nghĩa mà nó mang lại cho bạn?

Nếu bạn chưa biết PRs là gì, thì cũng đừng quá lo lắng, mình sẽ giải thích lại khái niệm đó, cũng như những công việc lập trình viên cần phải làm từ khi tạo ra cho tới khi kết thúc PRs ngay sau đây.

Để nói tới PR, chúng ta không thể không nhắc tới mã nguồn [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 sản phẩm, chúng ta sẽ cần sử dụng tới những phần mềm quản lí mã nguồn, 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 mã nguồn [thuật ngữ chuyên ngành gọi là repository hay ngắn ngọn là repo], họ thực hiện sao chép repo gốc – được quản lí trên server github – về máy tính cá nhân, ta gọi mã nguồn ở 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, mã nguồn chính của sản phẩm thường được để trong nhánh [thuật ngữ là branch] có tên gọi là master. Khi phát triển một tính năng mới, nhưng lại tránh thay đổi gì mã nguồn đ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ẽ thêm mã nguồn mới vào các nhánh con này, trong khi họ 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 tính năng 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 những người làm chung rằng: tôi đã làm xong và sẵn sàng gộp chung mã nguồn 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.

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 mã nguồn mới vào mã nguồn 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é.

Khi bạn tạo ra một PR để yêu cầu có một sự merge source, bạn 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 lệnh merge được chính thức kích hoạt bởi phần mềm quản lí mã nguồn git. Trong github, việc “xác nhận” này được thực hiện bằng việc nhấn vào nút MERGE trên PR.

Ở 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 mã nguồn được kiểm tra và đảm bảo, tính năng mới [hay mã nguồn mới] 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.

Sau khi PRs được merge vào nhánh chính của sản phẩm, thông tin về nó sẽ không bị mất đi. Phần mềm quản lí mã nguồn 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ề mã nguồn 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.

Tất cả mọi người lớn đều đã từng là những đứa trẻ, tương tự như thế, tất cả những phầm mềm dù lớn tới và phức tạp tới đâu cũng từng được tạo nên từ những thứ đơn giản ban đầu. Mỗi PR giống như một bài học bạn học được trong quá trình lớn lên và trưởng thành vậy. Bạn có thể học được rất nhiều bài học về phát triển phần mềm từ những PRs trong quá khứ.

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.

Bạn có thể thấy, PR thực chất là một khái niệm mang tính kĩ thuật của những phần mềm quản lí mã nguồn, nó giúp ta gộp những mã nguồn mới vào mã nguồn cũ để phát triển sản phẩm, nhưng không vì thế mà nó không chứa nhiều điều cho chúng ta học hỏi.

Kĩ thuật tách nhánh vào tạo những PRs giúp chúng ta tách biệt trách nhiệm của từng người, phân chia công việc lớn thành những thứ nhỏ hơn để nhiều người cùng có thể phát triển sản phẩm mà không dẫm chân lên nhau. Hãy luôn nhớ một điều là: phát triển phần mềm là công việc của cả một tập thể, bạn luôn luôn có cơ hội để học hỏi từ những người khác, ngay cả khi bạn không làm việc trực tiếp với họ. Những Pull Requests chính là thứ giúp chúng ta thực hiện điều này.

TopDev via Những dòng code vui

Video liên quan

Chủ Đề