Tạo Pull request đúng cách

Yêu cầu pull, thông thường gọi tắt là PR, là gì?

Thuật ngữ này đã trở nên quen thuộc với các nhà phát triển như chúng ta khi sử dụng nó hàng ngày, thậm chí chỉ trong vài phút một lần, chúng ta có thể nghe câu như “Anh ơiiii, review giúp em cái pull request XXX đi”. Tuy nhiên, dù chúng ta sử dụng nó thường xuyên như vậy, bạn có thật sự hiểu về nó, mục đích tạo PR, cách tạo PR để nhanh và đúng cách nhất. Trong bài viết này, mình sẽ chia sẻ một số kiến thức của mình về PR dựa trên kinh nghiệm thực tế. Sau khi đọc xong bài viết, hãy chia sẻ kinh nghiệm của bạn với PR với mình nhé. Bắt đầu thôi!

PR không liên quan đến logic của source code và thường được quan tâm sau khi các nhà phát triển đã hoàn thành việc code và sẵn sàng cho review. Tuy nhiên, đây là bước quan trọng không kém để đưa source code của từng nhà phát triển lại gần hơn với team và khách hàng. Đối với các dự án mà khách hàng trực tiếp review source code, việc bạn không gửi PR đúng theo quy định đã được định nghĩa theo quy tắc sẽ dẫn đến việc khách hàng từ chối kết hợp source code của bạn vào codebase chung.

Tại sao mình lại nói “đưa source code của từng nhà phát triển lại gần hơn với team và khách hàng”?

Vì trong thực tế khi làm việc trong một team, việc gọi mọi người đến máy tính của bạn và xem từng dòng code của bạn là không khả thi. Bạn cũng không thể gửi từng file source code cho người review tải về và xem – đó là không chuyên nghiệp và tốn thời gian. Và đương nhiên, khi khách hàng (ở một nơi xa bạn rất rất xa) muốn tham gia vào việc review code của bạn, việc này càng trở nên khó khăn hơn. Đó là khi bạn cần tới yêu cầu pull.

Yêu cầu pull được tạo ra để gửi file source code của bạn lên một trang web nơi mọi người có thể truy cập và cùng nhau review, và để lại nhận xét trực tiếp trên các file source code đó. Khi này, thời gian và vị trí review source code không còn là vấn đề – đó cũng chính là mục đích tạo ra yêu cầu pull!

Chuẩn bị PR, hoặc chính xác hơn là chuẩn bị nhánh để tạo yêu cầu pull. Chuẩn bị một nhánh tốt giúp mọi thứ trở nên dễ dàng hơn. Nếu bạn quên tạo nhánh mới để cập nhật source trên nhánh cần kết hợp, đừng lo, Git cung cấp chức năng stash để chuyển những thay đổi sang một nhánh mới. Nếu bạn không biết gì về stash, bạn có thể xem thêm tại đây.

Như thế nào là một nhánh tốt?

Trước tiên, quan trọng nhất là việc đặt tên. Tên nhánh phải phản ánh mục đích của việc cập nhật. Tên mô tả tất cả, nó sẽ giúp người xem có thể nhanh chóng hiểu bạn đang làm gì. Thông thường, mình sẽ đặt tên theo mẫu sau:

<loại>_<id vấn đề>_<phiên bản vấn đề>

Trong đó:

  • Loại: mô tả mục tiêu của nhánh. Loại có thể là Tính năng, Sửa lỗi, Tích hợp lại, Kiểm tra…
  • id vấn đề (hoặc id nhiệm vụ, id câu chuyện…) đã được xác định trên Git hoặc trên các công cụ quản lý dự án như Redmine, Trello… Bằng cách biết id vấn đề này, bạn có thể xác định các yêu cầu và từ đó nắm bắt được những gì cần được xem xét.
  • Phiên bản vấn đề: mô tả ngắn gọn mục đích của vấn đề. Nhìn vào id vấn đề, không thể biết bạn đang làm gì, nhưng chỉ cần xem thêm tên vấn đề, sẽ dễ dàng hiểu cơ bản công việc của bạn.
Có Thể Bạn Quan Tâm :   Nước Rửa Tay Diệt Khuẩn Không Mùi Hand Soap H-1

Ví dụ: Tích_hợp_ B223_Chỉnh_sửa_CSV_Download: từ cái tên này, có thể đoán rằng đây là nhánh để sửa lỗi 223 về việc tải xuống file csv sai ngày.

Nếu bạn đặt tên nhánh không đúng cách, đừng lo, việc đổi tên nhánh rất dễ dàng với 2 lệnh sau:

  • Nếu đang ở trên nhánh mà bạn muốn đổi tên: git branch -m tênMới
  • Nếu bạn đang ở trên một nhánh khác: git branch -m tênCũ tênMới

Thứ hai, đảm bảo rằng nhánh của bạn được cập nhật dựa trên phiên bản gốc của nhánh cần kết hợp. Điều này giúp tránh những xung đột không cần thiết. Đôi khi, nhiệm vụ mà bạn làm mất vài ngày để hoàn thành, trong khoảng thời gian đó có hàng chục phiên sổ đã được kết hợp. Bạn có đảm bảo không gây xung đột với ai không? Chính vì vậy, việc phát triển nguồn dựa trên phiên bản gốc của nhánh là điều cần thiết. Để làm điều này, bạn cần thực hiện rebase trên nguồn dựa thường xuyên. Không nhất thiết phải rebase mỗi khi có một phiên sổ mới, nhưng bạn phải chắc chắn không để quá nhiều phiên sổ lỡ. Mặc dù việc này có thể gây rắc rối, nhưng lợi ích mà nó mang lại là rất đáng giá:

  • Phát hiện và giải quyết xung đột ngay lập tức. Điều này giúp tiết kiệm thời gian vì chỉ cần giải quyết dựa trên ít phiên sổ.
  • Tăng tính khả dụng của mã nguồn, mã của bạn có thể hoạt động ngay lập tức sau khi được kết hợp.

Để thực hiện việc rebase nguồn dựa, rất đơn giản, làm theo các bước dưới đây:

  • Commit mã nguồn trên nhánh của bạn
  • Chuyển đến nhánh chính bằng git checkout <nhánh>, fetch (git fetch) và rút nguồn mới nhất (git pull)
  • Quay trở lại nhánh của bạn
  • Thực hiện lệnh sau git rebase <nhánh-gốc>
  • Giải quyết xung đột nếu có

Thứ ba, đây cũng là bước cuối cùng trong việc chuẩn bị PR, đó là squash commit. Việc bạn đẩy commit lên nhánh của bạn là một điều bình thường, mỗi khi bạn hoàn thành việc code bất cứ điều gì, bạn lại đẩy nó lên nhánh. Tuy nhiên, nhìn lại nhánh, hàng tá commit như thế có thể khiến mọi thứ trở nên rối rắm. Khi được kết hợp vào nhánh chính, nó sẽ hợp nhất từng commit của bạn. Càng nhiều commit, khả năng xung đột giữa các commit càng cao. Sau khi kết hợp, nhìn vào lịch sử trên Git, oh không, nó đẹp thế nào đây.

Ví dụ: Bạn thích cái nào hơn khi xem lịch sử trên nhánh phát triển

1256556316… Kết hợp yêu cầu pull #423 từ jrandom/add-slideshows
7hgf8978g9… Thêm tính năng trình chiếu mới, JIRA # 848394839
85493g2458… Sửa lỗi hiển thị trình diễn trong ie
gh354354gh… wip, hoàn thành cho tuần
789fdfffdf… Sửa lỗi căn chỉnh nhỏ
56556316ad… Kết hợp yêu cầu pull #324 từ ahacker/fix-android-display
787g8fgf78… Sửa lỗi hiển thị cho android
f56556316e… Kết hợp yêu cầu pull #28 từ somwhere/select-lang-popup
9080gf6567… Thêm cửa sổ xuất hiện để chọn ngôn ngữ
gh34839843… Sửa lỗi nhỏ (lỗi chính tả) cho bài kiểm tra thứ 3

Rất hay.

Hay.

1256556316… Kết hợp yêu cầu pull #423 từ jrandom/add-slideshows
787g8fgf78… Kết hợp yêu cầu pull #324 từ ahacker/fix-android-display
f56556316e… Kết hợp yêu cầu pull #28 từ somwhere/select-lang-popup

Việc squash commit từ nhiều commit thành ít commit hơn hoặc thành 1 commit không chỉ giúp lịch sử trở nên đẹp hơn, mà còn giúp dễ dàng xác định nguyên nhân gây lỗi. Để squash commit, bạn có thể tham khảo thêm tại đây.

Có Thể Bạn Quan Tâm :   Cách chọn sim 6868 đẹp và ý nghĩa.

Sau khi chuẩn bị nhánh cần kết hợp, tiếp theo chúng ta sẽ tạo yêu cầu pull. Giai đoạn chuẩn bị là giai đoạn mất nhiều công sức nhất và vất vả nhất. Nhưng một khi chuẩn bị tốt, các giai đoạn tiếp theo sẽ dễ dàng hơn rất nhiều. Đối với việc tạo yêu cầu pull, bạn chỉ cần chú ý các vấn đề sau:

Tiêu đề commit

Khi tạo yêu cầu pull, bạn cần kiểm tra lại các commit của mình. Như đã đề cập trong giai đoạn chuẩn bị, lúc này bạn chỉ có 1 commit duy nhất sau khi squash các commit. Lúc này, bạn muốn thể hiện các thay đổi trong mã nguồn của mình thông qua thông tin trong commit. Mặc dù tên nhánh phản ánh mục đích của việc thay đổi, nhưng để làm được mục đích đó, cần có commit message. Điều này giúp người đánh giá hoàn toàn hình dung được các thay đổi mà bạn đã thực hiện thông qua những thông tin được viết trong commit message. Khi tạo yêu cầu pull, các thông tin trong commit message cũng sẽ tự động điền vào phần mô tả, bạn không cần phải viết thêm thông tin vì điều đó là đủ.

Để viết commit message một cách rõ ràng, bạn nên tham khảo thêm tại đây

Đánh giá các thay đổi trên mã nguồn

Dù đã được đánh giá trong giai đoạn chuẩn bị, khi tạo yêu cầu pull, bạn cũng cần xem xét lại các thay đổi của mình với mã nguồn hiện tại. Hãy xem xét kỹ lưỡng vì có thể bạn phát hiện ra những lỗi mà trước đây bạn đã bỏ qua.

Thêm người xem

Và cuối cùng trước khi tạo yêu cầu pull, hãy xác định người xem. Việc thêm họ vào yêu cầu pull giúp người xem nhanh chóng nhận được thông báo liên quan đến yêu cầu pull. Tuy nhiên, đừng quên chia sẻ yêu cầu pull với những nhà phát triển khác để họ có thể nắm được các thay đổi nhằm tránh xung đột và họ hoàn toàn có thể trở thành người xem để cải thiện yêu cầu pull của bạn.

Trong thực tế, đôi khi chúng ta cần xem xét vài yêu cầu pull để trở nên tốt hơn. Vậy xem xét yêu cầu pull là xem xét điều gì? Và xem xét yêu cầu pull như thế nào cho đúng?

Đầu tiên, chúng ta thường xem xét mã nguồn. Nói chung, đối với các mã nguồn được cập nhật, tôi thường chú ý các điểm sau:

  • Coding conventions, đảm bảo các tên và định dạng phải tuân thủ các quy định đã đặt ra trước.
  • Kiểm tra xem trong mã có mã dư thừa như comment pseudo code, debugger hay các khối lệnh bị comment out không.
  • Kiểm tra một số vấn đề về clean code: mã xử lý trùng lặp, logic phức tạp, xử lý ngoại lệ không tốt … dựa trên các nguyên tắc như SOLID, DRY, KISS …
  • Đặc biệt, chú ý đến việc kiểm tra các bài kiểm tra. Đối với tôi, mọi dòng mã cần được kiểm tra. Điều này giúp bản thân nhà phát triển chịu trách nhiệm hơn với chất lượng mã nguồn của mình.

Thứ hai, đó là xem xét xem yêu cầu có đáp ứng yêu cầu hay không. Mã tốt không tương đương với việc mã chạy đúng. Điều này đòi hỏi bạn có khả năng đọc mã nguồn tốt, từ đó nắm bắt được logic và thuật toán xử lý. Và tất nhiên, để đảm bảo nó có đúng hay không, bạn phải kiểm tra trên local dựa trên yêu cầu của khách hàng.

Cuối cùng, kiểm tra xem liệu nó có ảnh hưởng đến các phần khác không? Việc này yêu cầu sự xem xét kết hợp từ các bên liên quan và cuối cùng là kiểm thử tích hợp để đảm bảo các thay đổi liên quan đến PR sẽ hoạt động tốt.

Có Thể Bạn Quan Tâm :   RSM (Regional Sales Manager) là gì? 5 phút tìm hiểu từ A-Z về công việc này

Tuy nhiên, hiện nay thì người xem thường không có thời gian để kiểm tra. Thậm chí việc xem xét mã và logic đã lấy hết thời gian. Đó là lý do tạo ra các bài kiểm tra tích hợp, tự động hóa là yêu cầu bắt buộc. Từ đó, chúng ta có thể giao cho hệ thống CI xây dựng và chạy bài kiểm tra để tiết kiệm thời gian hơn trong giai đoạn xem xét PR. Chúng ta chỉ cần dành thời gian xem xét mã và các bài kiểm tra của các bài kiểm tra đơn vị, tích hợp…

Sau tất cả, nút nhấn “hoàn thành PR”. Công việc này có vẻ đơn giản trong khi thực tế lại không như vậy chút nào. Trước hết, bạn cần giải quyết tất cả các ý kiến ​​của người xem để PR được phê duyệt. Việc cập nhật nhất định sẽ tạo ra những cập nhật mới và cần được xem xét. Vì vậy, chúng ta cũng nên thực hiện tất cả các thao tác đã đề cập ở trên để đảm bảo PR của bạn luôn sẵn sàng hoạt động và tất nhiên, hoạt động tốt hơn. Cho đến khi tất cả các ý kiến ​​được giải quyết, bạn quyết định cách sáp nhập nhánh của bạn để hoàn thành PR. Điều này không dễ. Nó đòi hỏi bạn phải hiểu sự khác biệt giữa các cách merge PR. Dù tất cả đều là merge, nhưng mở rộng merge là khác nhau và hiển thị trên lịch sử cũng khác nhau. Tất cả chúng ta đều thích một cái lịch sử đẹp và dễ quản lý, vì vậy việc lựa chọn cách merge phù hợp là một vấn đề quan trọng.

Để biết thêm về các cách merge PR, bạn có thể tham khảo tại đây

Sau khi merge PR, nhánh của bạn đã bị xóa. Tuy nhiên, trên máy tính cá nhân vẫn còn, vì vậy hãy lưu ý xóa nó. Nếu cẩn thận, bạn có thể tạo bản backup trước khi xóa, nhưng khoảng thời gian dự trữ hoàn toàn là không cần thiết. Mặc dù nhánh của bạn đã bị xóa, nó vẫn được lưu lại dưới dạng commit trên nhánh chính của bạn và bạn hoàn toàn có thể lùi lại các thay đổi trong commit đó nếu có sự cố và sau đó thực hiện cherry pick các commit quan trọng trong quá trình sửa lỗi.

Và điều cuối cùng mà tôi muốn nói là dù bạn đã hoàn thành PR, nhánh của bạn đã bị xóa không có nghĩa là bạn đã xong. Hãy kiểm tra sau khi kết hợp và thậm chí sau khi triển khai sản phẩm. Luôn chú ý các lỗi xảy ra sau khi bạn đã kết hợp mã vì có thể liên quan đến PR của bạn. PR đã xong, nhưng bạn thì chưa. Hãy nhớ điều này.

Đối với một số người, có thể nghĩ “yêu cầu pull chỉ là hình thức, quan trọng là logic và mã nguồn chất lượng”. Tuy nhiên, đối với chính mình, tôi nghĩ rằng giúp đồng đội hoàn thành công việc của nhau một cách trôi chảy là điều quan trọng nhất. Tạo yêu cầu pull “chất lượng” sẽ giúp làm việc với team trở nên nhanh chóng và hiệu quả hơn.

Đó là một số hiểu biết thực tế của tôi về yêu cầu pull, và bạn thì sao? Bạn đã có những kinh nghiệm và gợi ý gì khi làm việc với yêu cầu pull chưa? Hãy để lại bình luận để tôi học hỏi thêm nhé!

https://help.github.com/en/articles/about-pull-requests

Back to top button