Cơ bản về GitFlow, tại sao nó được sử dụng rộng rãi trong phát triển phần mềm

Cách sử dụng Gitflow

Ở bài trước chúng ta đã tìm hiểu về Git và các lệnh của Git, nhưng chưa rõ sẽ áp dụng Git như thế nào. Trong bài này chúng ta sẽ tìm hiểu về Gitflow, một quy trình làm việc dựa trên Git được rất nhiều công ty trên thế giới sử dụng.

GitFlow là gì?

Qua bài đầu tiên về GIT chúng ta đều hiểu, cần một hệ thống GIT để quản lý source code. Tuy nhiên, trong khi phát triển phần mềm, việc dùng chung một hệ thống sẽ không tránh khỏi việc xung đột. Từ đó Gitflow ra đời.

Gitflow là một quy trình làm việc phổ biến cho việc quản lý dự án phần mềm sử dụng hệ thống quản lý phiên bản Git. Được giới thiệu bởi Vincent Driessen vào năm 2010, Gitflow cung cấp một bộ các nhánh và quy tắc rõ ràng để phát triển phần mềm, giúp các nhóm phát triển tổ chức và quản lý mã nguồn một cách hiệu quả
Gitflow Workflow phù hợp với những mô hình phát triển phần mềm có thời gian release có chu kỳ như scrum. Workflow này không có thêm concepts hoặc commands mới nào ngoài những tính năng cho Feature Branch Workflow.

Thay vào đó chúng chỉ định vai trò cụ thể của các branches khác nhau và thời điểm mà chúng cần tương tác. Ngoài ra còn có các branches đặc biệt cho việc preparing, maintaining và release. Tất nhiên, bạn có thể tận dụng các lợi thế của Feature Branch Workflow để tăng tính hiệu quả.

Gitflow hoạt động như thế nào?

Về cơ bản Gitflow sẽ mô tả quá trình phân nhánh (branch) và cách làm việc trên các nhánh đó. Mỗi nhánh trên Gitflow sẽ có chức năng khác nhau, để giải quyết các công việc khác nhau trong phát triển phần mềm.

A diagram of a graph Description automatically generated

Các nhánh chính (Main Branches)

Main/Master: Đây là nhánh chính chứa mã nguồn của phiên bản sản phẩm đã phát hành. Mỗi commit trên nhánh này thường tương ứng với một phiên bản đã được phát hành. Chúng ta sẽ dùng thẻ Tag để đặt tên cho phiên bản trên nhánh này.

Develop/Development: Đây là nhánh chính dùng để phát triển. Được khởi tạo từ master branches để lưu lại tất cả lịch sử thay đổi của mã nguồn. Develop branchs là merge code của tất cả các branchs feature.

Các nhánh hỗ trợ (Supporting Branches)

Feature Branches: Dùng để phát triển các tính năng mới. Mỗi tính năng sẽ được phát triển trên một nhánh riêng biệt và khi hoàn thành, nó sẽ được hợp nhất (merger) vào nhánh develop.

  • Tên nhánh thường có dạng feature/<tên-tính-năng>.

Release Branches: Dùng để chuẩn bị cho một phiên bản phát hành. Nhánh này cho phép các nhóm thực hiện các bước chuẩn bị cuối cùng như kiểm tra và sửa lỗi trước khi hợp nhất vào main và tạo ra một phiên bản cho người dùng cuối

  • Tên nhánh thường có dạng release/<phiên-bản>.

Hotfix Branches: Dùng để sửa các lỗi khẩn cấp trên phiên bản đã phát hành. Nhánh này sẽ được tạo từ main và sau khi hoàn thành, nó sẽ được hợp nhất cả vào main và develop.

  • Tên nhánh thường có dạng hotfix/<sửa-lỗi>.

Ngoài ra còn một số branchs mà chúng ta thường tạo ra tùy vào yêu cầu của dự án:

Pre-pro môi trường chưa mã nguồi của bản buil chạy trên môi trường user test,

QC Môi trường chứa mã nguồn của bản build chạy trên môi trường test,

BugFix: để chứa mã nguồn khi thực hiện công việc fix bug.

Quy trình làm việc với GitFlow

Về cơ bản gitflow theo Vincent Driessen sẽ là như sau:

  • Branch khởi đầu sẽ là master. Khi bắt đầu phát triển tính năng sẽ checkout từ master ra develop.
  • Mỗi tính năng sẽ checkout tiếp từ develop ra các nhánh có prefix là feature/. (ví dụ tính năng login là feature/login, tính năng logout là feature/logout…) và phát triển độc lập với nhau. Sau khi hoàn thành thì merge feature vào develop.
  • Đến kì release sẽ merge develop vào release, nhánh release đóng vai trò như là môi trường stagging của dự án. Đó là môi trường gần giống với production nhất. Nhánh release lúc này chỉ gồm các commit fixbug mà không bao gồm commit thêm tính năng nào nữa. Nếu có fixbug phát sinh trên release thì merge lại vào develop.
  • Khi bug đã hết cũng là lúc tiến hành merge release vào master. Tại đây ta có thể đánh dấu tag cho commit đó để làm dấu hiệu phiên bản phát hành tiện lợi cho việc theo dõi và truy vết.
  • Khi chạy production không thể tránh khỏi lỗi phát sinh, khi đó chúng ta checkout từ master ra nhánh có tiền tố hotfix/ để fixbug. Sau khi sửa lỗi xong thì merge nhánh vừa tạo vào develop, từ develop kiểm tra thấy bản fix đã hoạt động thì tiếp tục merge hotfix vào master sau đó được gắn Tag thành 1 Version sửa lỗi (Patch Version).

Lưu ý khi làm việc với Git

Tạo Merger Request (Pull Request)

Nhiều người không có thói quen tạo merge request mà merge trực tiếp code vào branchs develop rồi push lên, điều này là không tốt.

  • Thứ nhất, tạo merge request để teamlead hoặc reviewer (FO,FA,Senior..) có thể review mã nguồi trước khi merge để đảm bảo tính toàn vẹn của mã nguồn, điều này là cực kì quan trọng khi phát triển phần mềm với một team nhiều người.
  • Thứ hai: người review sẽ comment trực tiếp cần thay đổi lên merge request để giảm thời gian trao đổi tăng tính hiệu quả khi làm việc nhóm.
  • Thứ ba, tạo merge request để lưu lại lịch sử thay đổi của mã nguồi.Khi có vấn đề về lỗi, chất lượng phần mềm…. chúng ta có thể xem lại tất cả những sự thay đổi trên từ dòng code ( việc này có thể kiếm tra bằng cách kiểm tra trên từng commit nhưng commit thì rất nhiều).

Ngoài ra, đây còn là nơi để lưu lại các comment của người review, các lỗi thông thường để các member sao không còn mắc lại lỗi cũ và là nơi để học hỏi code lẫn nhau thông qua việc xem lại sự thay đổi từng dòng code của member khác.

Cách tạo merger Request có thể tham khảo ở đây: https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html

Xử lý conflict

Conflict (xung đột) là chuyện thường xảy ra khi làm việc nhóm, nhất là những dự án đông người. Việc team member tuân theo các process đã được trainning là giải pháp tốt nhất. Ngoài ra, bản thân member có thể hạn chế conflict code bằng cách chia nhỏ code thành từ module độc lập và hạn chế viết quá nhiều code vào một file, thường xuyên merge code ở branchs về để đảm bảo code hiện tại là mới nhất, merge code của branchs trước và sau khi code nếu có conflict thì merge conflict trước khi tạo merge request.

Kết

Vậy là chúng ta đã tìm hiểu được Gitflow, quan trọng nhất trong Gitflow là các member trong team cần tuân thủ các nguyên tắc mà Gitflow đặt ra, từ đó giúp việc phát triển phần mềm trở nên có hệ thống và đơn giản hơn.

Rate this post

Để lại một bình luận

Email của bạn sẽ không được hiển thị công khai. Các trường bắt buộc được đánh dấu *