Các chiến lược sử dụng Git trong dự án phần mềm
Git cung cấp các công cụ để quản lý source code dự án trong quá trình phát triển phần mềm. Tuy nhiên để làm việc với Git hiệu quả ta không thể tùy biến vô tội va, mà thực sự cần các chuẩn mực trong quá trình phát triển để đạt được các mục đích tối ưu về mặt hiệu năng làm việc, cũng như khả năng đối phó với các tình huống khẩn cấp.
Bài viết này đi sâu vào khai thác các cách triển khai chiến lược sử dụng Git. Người mới bắt buộc phải nắm rõ và thành thạo để có thể hòa nhập sớm với team SWE và bắt đầu deliver được tính năng đầu tiên.
Các khái niệm Merge Request (MR), Pull Request (PR)
MR, PR là các khái niệm tương đồng nhau. Cả 2 đều đề cập đến việc Merge các thay đổi từ 1 Git Branch vào một Git Branch khác.
Tính năng MR, PR được các Git Platform (GitHub, GitLab, Bitbucket) cung cấp để giúp Lập trình viên giải quyết các vấn đề liên quan đến Code Review
| Lịch sử thay đổi | Khi tạo một MR, PR trên Remote Repository. Các thành viên của dự án trên Git Platform có thể cùng tham gia và kiểm tra các thay đổi này mà không cần phải kéo code về máy của mình. |
| Bình luận trên các thay đổi | Khi nhận thấy các thay đổi chưa hợp lý, hoặc cần thêm context để hiểu về mục đích thay đổi. Các thành viên của dự án có thể thêm các comments trong MR để cùng nhau thảo luận. Hãy tưởng tượng nó cũng như 1 post trên Facebook, hoặc Reddit vậy. Rất dễ sử dụng. |
| Gợi ý chỉnh sửa ngay trên MR, PR | Nếu bạn đủ master về dự án, bạn có thể thêm ngay 1 đoạn code để gợi ý chủ MR chỉnh sửa cho phù hợp. Đây là 1 tính năng tuyệt vời của các Git Platform cho phép bạn tự thêm các changes vào MR, PR. |
| Tự động báo Git conflict | Trong trường hợp giữa các Git Branch có conflict. MR, PR sẽ báo trước để bạn nắm thông tin mà không cần phải merge ở Local mới nhận ra. |
| Dễ dàng setup thêm các tích hợp liên quan đến CI | Trong thực tế dự án phần mềm, trước và sau khi Merge 2 branch ta sẽ cần chạy qua 1 số thủ tục cần thiết có thể liệt kê ra ở đây: Unit Test, Build Bundle, Upload Artifact, … MR, PR của các Git Platform sẽ hỗ trợ bạn setup các công đoạn này dễ dàng. Kiến thức này cũng sẽ được học trong khóa Git Mastery |
| Tự động merge khi đầy đủ điều kiện | Khi các điều kiện check đã đầy đủ, bạn có thể chủ động thực thi việc merge MR, PR đó. Hoặc có thể setup cho chúng tự động Merge. Sau khi merge xong, bạn chỉ cần git pull trên branch gốc là có code mới. Tiếp tục chuyển sang phát triển các tính năng tiếp theo. |
Git Flow
Git Flow là một mô hình phân nhánh được sử dụng phổ biến trong việc phát triển dự án phần mềm.
Git Flow phân chia dự án làm 2 loại nhánh:
| Nhánh chính | main (hoặc master): Đây là nhánh chính của dự án. Các đoạn code ổn định nhất, chất lượng nhất, được chạy qua tất cả các Test sẽ được lưu trữ ở đây. develop: Nhánh phát triển. Nơi dùng để tách và merge các tính năng mới vào. |
| Nhánh hỗ trợ | feature: Nhánh dùng để phát triển một tính năng cụ thể. Được tạo ra từ develop, merge vào develop release: Nhánh để chuẩn bị cho một phần release. Được tạo ra từ develop và merge vào main (master) hotfix: Nhánh để fix các vấn đề lỗi trong quá trình phát triển sản phẩm. Được tạo ra từ branch main (master) và merge vào main (master), đồng thời cũng merge vào develop |
Trên đây là kiến thức cơ bản về Git Flow mà mỗi lập trình viên đều cần phải nắm. Trong thực tế phát triển phần mềm, một số dự án sẽ có cách thiết kế branch khác để phù hợp với cách hoạt động của Team. Hãy hiểu các kiến thức cốt lõi của Git và vận dụng chúng linh hoạt để đạt được mục tiêu công việc của bạn.
Trunk-based Development
Trunk-based Development là một cách tiếp cận khác so với Git Flow. Nếu ở Git Flow các lập trình viên chỉ merge các thay đổi vào nhánh develop, và đến 1 khoảng thời gian nhất định mới merge develop vào nhánh main (master) thì ở Trunk-based Development chúng ta lược bỏ đi nhánh develop. Tất cả các thay đổi đều được đẩy vào nhánh chính main (master).
Thay đổi này mang lại lợi ích: việc đồng bộ logic giữa các team sẽ diễn ra nhanh hơn. Các conflict cũng được xử lý nhanh nếu có xảy ra.
Tuy nhiên chúng mang lại một sự STRESS không hề nhẹ, khi mà tất cả những code của lập trình viên làm ra đều được đẩy lên main branch ngay trong ngày. Điều này khiến cho việc Testing là một thử thách lớn của Team Engineer.
Trunk-based Development yêu cầu team có một kế hoạch testing tốt (thường là automation test) để có thể phát hiện sớm các thay đổi làm break các logic của dự án.
Lựa chọn chiến lược với Git phù hợp cho dự án
Theo kinh nghiệm của mình các dự án với quy mô lớn (Tầm hơn 100 triệu active user 1 tháng) nên sử dụng Git Flow để đảm bảo chất lượng sản phẩm là tốt nhất có thể. Với các dự án nhỏ hơn, và team Engineer tốt thì nên sử dụng Trunk-based Development để tiết kiệm thời gian phát triển nhằm tăng tốc độ release sản phẩm, nhanh chóng mang các tính năng mới đến cho người dùng.
Dù theo Git Flow hay Trunk-based Development, mỗi Software Engineer đều có trách nhiệm tạo ra những dòng code chất lượng cao, được trau chuốt tỉ mỉ và kiểm thử kỹ lưỡng. Đó không chỉ là yêu cầu của quy trình làm việc mà còn là sự thể hiện của tinh thần trách nhiệm và sự chuyên nghiệp.
Liệu bạn có tự tin với từng dòng code mình viết ra?
You may also like
Các Lệnh Git Nâng Cao
