Pull request là gì

     

Thuật ngữ này sẽ quá rất gần gũi với những người làm dev như họ khi mà chúng ta sử dụng nó sát như hằng ngày hằng giờ thậm chí là là vài phút một lần cũng hoàn toàn có thể nghe hầu như câu đại loại như "Anh êiiiii, nhận xét giúp em mẫu pull request XXX điiiiiii". Tuy nhiên mặc dù là dùng quá liên tiếp như vậy nhưng bạn có thiệt sự hiểu hết về nó, mục tiêu tạo PR, sinh sản PR ra làm sao cho thiệt xịn hay đánh giá PR ra sao là cấp tốc và đúng cách dán nhất. Hôm nay, qua nội dung bài viết này bản thân xin được chia sẻ một số sự hiểu của chính mình về PR nhưng mà mình từng có thông qua những trải nghiệm thực tế trong dự án mình từng làm. Phần nhiều người sau thời điểm đọc xong bài viết này hãy cùng share những tay nghề với quảng bá với mình và nhé. Bắt đầu thôi nào!

Mục đích sinh sản pull request

Pull request giỏi PR là khái niệm không liên quan đến súc tích source code cùng thường được quan lại tâm cuối cùng khi dev đã hoàn tất vấn đề code và sẵn sàng chuyển tiếp sang bước để mọi fan review, mặc dù "Last but not least" - đây gần như là bước cuối cùng quan trọng ko kém để lấy source code của từng dev họ đến gần với team với người tiêu dùng vì cùng với những dự án có quý khách hàng trực tiếp đánh giá source code thì dù logic và code của doanh nghiệp có xịn đến mấy nhưng chúng ta không nhờ cất hộ PR đúng đắn đã được define theo rule thì khách hàng hàng cũng trở nên sẵn sàng reject ngay không cho merge vào source code chung đâu nhé nhé

*

Vì sao mình lại cần sử dụng câu "đưa source code của từng dev bọn họ đến sát với team với khách hàng" ?

Vì thực tế khi chúng ta làm việc trong team có tương đối nhiều người, từng một chức năng bạn xong xuôi code và rất cần được team review, chúng ta không thể gọi mọi fan đến vật dụng tính của khách hàng và ngồi đấy reviews từng loại code cho bạn đâu nhỉ. Bạn cũng cần thiết gởi từng file source code cho những người review để họ tải về về đồ vật và đánh giá được - vượt tốn thời gian và thiệt sự không siêng nghiệp. Và tất nhiên khi quý khách hàng (đang ở một ở đâu đấy vô cùng rất xa bạn) ao ước tham gia nhận xét code của người sử dụng thì chuyện này càng trở ngại hơn. Đó là lúc bắt buộc dùng đến Pull request.

Bạn đang xem: Pull request là gì

Pull request được tạo ra ra để đưa những tệp tin source code của công ty lên 1 host chung nơi mọi người có quyền truy cập sẽ truy vấn vào và thuộc review, để lại comment trên những file source code đó. Bây giờ thời gian nhận xét và địa điểm đánh giá source code không hề là vụ việc - đó cũng đó là mục đích tạo nên pull request!

Chuẩn bị pull request như thế nào

Chuẩn bị PR tốt nói đúng đắn hơn là sẵn sàng branch để thực hiện pull request. Việc sẵn sàng một branch xuất sắc giúp cho phần lớn thứ trở nên dễ dãi hơn. Nếu khách hàng lỡ có quên chế tác branch new mà update source bên trên branch đề nghị merge thì hãy yên tâm, Git tất cả sẵn công dụng để giúp cho bạn chuyển những chuyển đổi này sang trọng branch mới, sẽ là stash. Trường hợp bạn chưa chắc chắn gì về stash thì hoàn toàn có thể xem trên đây

Vậy ra sao là một branch tốt?

Thứ nhất, chắc chắn rằng là naming. Tên branch yêu cầu thể hiện mục đích của việc update. Cái thương hiệu nói lên vớ cả, nó để giúp cho reviewer hoàn toàn có thể nắm bắt nhanh chóng bạn đang làm cho gì. Thông thường mình sẽ tạo nên tên format sau:

__

Trong đó:

Type: thể hiện mục tiêu của branch. Type có thể là Feature, Fix, Refactor, Test…issue id (hoặc task id, story id…) đã được define bên trên git tốt trên các trình làm chủ project như redmine, trello... Chỉ nên biết issue id là hoàn toàn có thể xác định được các yêu cầu, từ bỏ đó có thể nắm được cần đánh giá cái gìtên issue: thể hiện ngắn gọn mục đích của issue. Do nhìn vào issue ID cần yếu biết ngay chúng ta đang làm gì nhưng chỉ cần nhìn thêm thương hiệu issue hẳn người nào cũng nắm được cơ bản công câu hỏi của bạn

Ví dụ nhưFix_B223_ CSV_Download_Wrong_Date: nhìn vào cũng đoán được đó là branch nhằm fix bug 223 về lỗi tệp tin csv tải về nhầm ngày.

Nếu bạn có lỡ đặt tên branch sai bí quyết thì chớ lo việc thay tên branch rất dễ dãi với 2 command sau:

# nếu như ở trên branch mong muốn đổi têngit branch -m newName# nếu đang ở branch khácgit branch -m oldName newNameThứ hai, bảo vệ rằng branch của công ty phải update dựa trên lastest source của branch nên merge. Việc này sẽ giúp đỡ tránh phần đa conflict không buộc phải thiết. Đôi khi task bạn đang làm mất vài ngày mới kết thúc thì vào khoảng thời gian đó gồm tới hàng trăm commit đã có được merge. Bạn có đảm bảo rằng sẽ không người nào conflict với bạn không. Bởi vì thế việc cải tiến và phát triển source code dựa trên lastest source là điều cần thiết. Để làm cho được điều này, bạn cần thiết phải rebase source code thường xuyên xuyên. Không duy nhất thiết yêu cầu rebase mỗi lúc có một commit new nhưng các bạn phải chắn cứng cáp mình ko được để lỡ quá nhiều commit. Tuy nhiên việc này tương đối là phiền phức nhưng công dụng của nó đem đến cao rộng nhiều:

phát hiện conflict với resolve nó tức thì lập tức. Câu hỏi này góp tiết kiệm không hề ít thời gian bởi chỉ resolve dựa vào số không nhiều commit.tăng tính khả dụng của source code, code của bạn có thể hoạt rượu cồn ngay mau lẹ khi được merge

Và nhằm rebase source code, rất đơn giản, làm theo các bước bên dưới nhé

commit source code ở branch của bạndi chuyển sang branch chính bằng git checkout , fetch (git fetch) cùng pull lastest source về (git pull)di chuyển về branch của bạnthực hiện nay lệnh sau git rebase Resolve conflict giả dụ có

Thứ ba, đây cũng là bước sau cuối của việc chuẩn bị PR, đó đó là squash commit. Bài toán bạn push commit lên branch của người tiêu dùng là điều rất là bình thường, như mình cứ mỗi lần code xong cái gì mình lại push lên branch, bài toán này tránh bị mất code giả dụ như bao gồm sự thay gì xảy ra. Tuy vậy khi tiến hành xong, quan sát lại branch, thì mặt hàng tá commit như thế có thể khiến đầy đủ thứ trở đề nghị rối tung lên. Vị khi merge vào branch chính thì nó sẽ merge từng commit của bạn. Càng các commit thì kĩ năng phát sinh conflict giữa những commit càng cao. Sau khoản thời gian merge, nhìn vào graph trên Git thì ôi thôi cái đống gì nỗ lực này.

Chẳng hạn mình thích cái làm sao hơn khi xem history bên trên branch develop

1256556316... Merge pull request #423 from jrandom/add-slideshows7hgf8978g9... Added new slideshow feature56556316ad... Merge pull request #324 from ahacker/fix-android-display787g8fgf78... Hotfix for game android display issuef56556316e... Merge pull request #28 from somwhere/select-lang-popup9080gf6567... Implemented pop-up lớn select languagehay

1256556316... Merge pull request #423 from jrandom/add-slideshows56556316ad... Merge pull request #324 from ahacker/fix-android-displayf56556316e... Merge pull request #28 from somwhere/select-lang-popupViệc squash commit từ nhiều commit thành không nhiều commit rộng hoặc thành 1 commit chẳng đa số giúp graph trở cần đẹp hơn nhưng còn có thể giúp phát hiện nay lỗi dễ dành hơn chính vì càng không nhiều commit càng dễ xác định được đâu là nguyên nhân gây lỗi.Về giải pháp squash commit, chúng ta cũng có thể tham khảo trên đây.

Tạo pull request cần chăm chú những gì

Sau khi chuẩn bị branch buộc phải merge thì tiếp theo chúng ta sẽ sản xuất một PR. Giai đoạn sẵn sàng cũng là giai đoạn tốn nhiều công sức nhất với vất vả nhất. Và một khi chuẩn bị tốt những giai đoạn tiếp sau sẽ đơn giản dễ dàng hơn cực kỳ nhiều. Như sản xuất PR, các bạn chỉ cần chăm chú đến những vấn đề sau.

Commit message

Khi tạo nên PR, trước tiên bạn cần check lại những commit của mình. Như khâu chuẩn bị đã kể ở trên, thì hôm nay bạn chỉ có 1 commit duy nhất sau thời điểm squash các commit. Thời điểm này, bạn muốn thể hiện nay sự thay đổi trong source code ở commit đấy thì chỉ hoàn toàn có thể thông qua commit message. Tuy nhiên tên branch biểu lộ được mục đích của việc đổi khác nhưng việc làm sao để đã có được mục đích thì nó phải phải đến commit message. Điều này hỗ trợ cho reviewer trọn vẹn hình dung được chúng ta thực hiện thay đổi như vậy nào thông qua các thông tin được viết trong commit message. Khi sản xuất pull request, những tin tức ở commit message cũng sẽ tự động hóa fill vào phần mô tả tìm kiếm nên bạn không đề xuất tốn thời gian để viết thêm thông tin bởi vì như vắt là thừa đủ.

Để viết commit message một cách rõ ràng thì các bạn nên tìm hiểu thêm tại đây

Review các biến hóa trên source

Mặc cho dù đã review ở bước sẵn sàng nhưng khi tạo thành pull request, bạn cũng cần được xem các chuyển đổi của bản thân với source hiện tại. Hãy xem xét lại một biện pháp kĩ lưỡng vì bao gồm thể bạn sẽ nhận ra đa số lỗi mà trước đây mình lại vứt qua.

Add reviewer

Và quy trình cuối cùng trước khi tạo pull request kia là xác định reviewer. Việc thêm bọn họ vào pull request giúp cho reviewer nhanh chóng nhận được các thông báo liên quan cho pull request. Mặc dù nhiên nhớ rằng share PR cho những dev khác nhằm họ hoàn toàn có thể nắm được các đổi khác nhằm tránh các conflict vạc sinh cùng họ hoàn toàn hoàn toàn có thể trở thành reviewer giúp cho PR của bạn trở nên giỏi hơn.

Xem thêm: Floating Point Là Gì - Một Vài Dấu Phẩy Động Bất Thường Là Gì

Review pull request

Cuộc đời dev đâu chỉ có lúc nào cũng căm khía cạnh code rồi sinh sản PR. Đôi lúc chúng ta cũng phải reviews vài chiếc PR để trở bắt buộc xịn xò. Vậy review PR là review cái gì? Và nhận xét như vậy nào mang lại đúng?

Đầu tiên dĩ nhiên chắng là đánh giá code rồi. Nhìn chung thì đối với updated source code, mình thường chăm chú các điểm sau:

Coding convenstion, đảm bảo an toàn việc naming, format đề nghị đúng với điều khoản đã đề ra từ trước.Kiểm tra trong code gồm còn xót những xử lý dư thừa như phản hồi pseudo code, debugger tuyệt là phần nhiều khối lệnh bị comment outCheck một số trong những vấn đề về clean code: code cách xử trí trùng lặp, lô ghích phức tạp, xử trí exception ko tốt... Dựa trên những principle như SOLID, DRY, KISS...Đặc biệt cần chú ý đến unit test. Với mình thì phần đa dòng code rất cần được được test. Điều kia giúp phiên bản thân dev gồm tránh nhiệm rộng với quality code của mình.

Thứ hai, kia là tất cả đúng requiment xuất xắc không. Code ngon nhưng chạy ko đúng thì hẳn là một trong những chuyện gì đấy rất xàm. Việc này yên cầu bạn có tác dụng đọc code tốt, từ bỏ đó núm được xúc tích và ngắn gọn và thuật toán xử lý. Và tất yếu là để bảo đảm nó có đúng hay không thì bạn phải checkout branch kia về và thực hiện run test những kiểu trên local dựa vào requiment của khách hàng.

Cuối cùng là kiểm soát nó có tác động đến những thành phần khác xuất xắc không? việc này yên cầu phải gồm sự reviews kết hợp của không ít bên liên quan và trước tiên là khối hệ thống integration kiểm tra để bảo đảm mọi thứ tương quan đến update trong PR đang vẫn vận động tốt.

Tuy nhiên, bây chừ thì reviewer hầu như đều không có thời gian cho câu hỏi test. Thậm chí việc nhận xét code và logic xử lý cũng đã lấy hết thời hạn rồi. Cho nên việc tạo unit chạy thử và integration kiểm tra hay automation test biến chuyển yêu cầu bắt buộc. Trường đoản cú đó họ có thế giao phó cho hệ thống CI build với run demo để tiết kiệm thời gian hơn vào khâu reviews PR. Họ chỉ yêu cầu dành thời gian cho việc đánh giá code và những testcase của unit test, integration test...

Hoàn thành pull request

Yeah, sau vớ cả đó là complete PR. Và vấn đề này tưởng chừng đơn giản và dễ dàng như thực tiễn lại ko hề dễ dàng chút nào. Trước hết bạn cần phải resolve toàn bộ phản hồi của reviewer nhằm PR được approve merge. Việc update chắc chắn rằng sẽ tạo thành những commit mới và rất cần được được review. Bởi vì thế họ cũng buộc phải thực hiện toàn cục cái làm việc đề cập nghỉ ngơi trên để đảm bảo PR của chúng ta luôn trong tinh thần sẳn sàng vận động và tất yếu là vận động tốt là đằng khác. Cho đến khi vớ cả comment đều được giải quyết ổn thỏa thì hôm nay là lúc mà chúng ta quyết định phương thức merge branch của doanh nghiệp để xong xuôi PR. Đây là điều không dễ. Nó yên cầu bạn phải nắm rõ sự khác biệt giữa những cách merge PR. Tuy tất cả đều là merge nhưng thực chất merge là không giống nhau và vấn đề hiển thị bên trên graph cũng khác nhau. Ai trong chúng ta cũng hầu như thích một graph rất đẹp và dễ dãi quản lí, nên việc lựa chọn lựa cách nào để merge sao cho phù hợp là vấn đề lớn.

Về các cách merge PR các bạn tham khảo tại đây

Sau khi merge quảng cáo thì hôm nay branch của người sử dụng đã được xóa. Mặc dù trên local vẫn tồn tại nên hãy để ý là xóa cả nó luôn luôn nhé. Giả dụ cẩn thận chúng ta cũng có thể tạo phiên bản backup trước lúc xóa tuy vậy thì câu hỏi backup trọn vẹn thừ thải. Tuy vậy branch của doanh nghiệp đã được xóa mặc dù nó vẫn được lưu giữ thành một commit bên trên branch chủ yếu và chúng ta hoàn toàn hoàn toàn có thể revert những biến hóa trong commit kia nếu gồm lỗi xẩy ra và rất có thể thực hiện nay cherry pick gần như commit quan trọng đặc biệt trong quy trình sửa lỗi sau đó.

Và điều cuối cùng bạn thích nói là dù cho bạn đã hoàn thành PR của mình, branch của bạn đã được xóa thì không tức là bạn hết trách nhiệm với nó. Hãy test sau khi merge và thậm chí cả lúc lên product. Luôn chú ý đến các bug gây ra sau khi bạn merge source bởi vì rất hoàn toàn có thể nó tương quan đến truyền bá của bạn. PR xong xuôi nhưng các bạn thì chưa xong. Nhớ vấn đề này nhé.

Xem thêm: Thuốc Bôi Muỗi Đốt Cho Bé Tốt Nhất Mùa Hè 2021

Lời kết

Thật sự so với một số bạn có thể nghĩ "pull request ấy mà, chỉ là hình thức thôi, đặc biệt quan trọng là xúc tích là code xịn". Tuy nhiên, với bạn dạng thân mình, bản thân nghĩ khi thao tác cùng team thì vấn đề giúp cho các bước của nhau xong xuôi trôi chảy mới là thứ đặc biệt quan trọng nhất. Việc tạo ra 1 pull request "xịn" sẽ đóng góp thêm phần giúp mang đến việc thao tác với team trở nên gấp rút và thướt tha hơn đấy.

Trên đó là những gọi biết thực tế của bản thân mình về pull request, còn các bạn thì sao, chúng ta có những kinh nghiệm và tip gì khi thao tác làm việc với pull request không, hãy comment cho mình học tập thêm nhé!