Gitflow là gì và bạn có cần biết đến nó?

Gitflow là gì và bạn có cần biết đến nó?

Tin ngắn hàng ngày dành cho bạn
  • Bắt đầu kỳ nghỉ tết rồi nên mình cũng không đăng bài nữa. Hẹn gặp lại các bạn qua tết nha 😁

    » Xem thêm
  • Tiếp tục về jj. Đang thắc mắc là nó mới thế liệu có ai làm mấy phần mềm dạng GUI cho dễ nhìn chưa. Kiểu giống như git thì có quá nhiều rồi không đếm xuể.

    May quá, tác giả tổng hợp lại luôn rồi Community-built tools around Jujutsu 🥳

    » Xem thêm
  • Turso thông báo rằng họ đang viết lại SQLite bằng Rust. Thế là lại có thêm một bằng chứng nữa cũng cố cho câu nói Rust đang "tái định nghĩa" lại nhiều thứ.

    Nhưng nguyên nhân sâu xa mới thú vị. Tại sao họ lại làm vậy? Ai cũng biết SQLite là nguồn mở, ai cũng có thể tạo bản sao (fork) để chỉnh sửa lại theo ý mình. Lẽ nào nhóm của Turso không thích hoặc không tin vào C - vốn là ngôn ngữ dùng để cấu thành SQLite.

    Mình xin kể chuyện một chút. Turso là một bên cung cấp dịch vụ máy chủ cơ sở dữ liệu dựa trên SQLite, họ đã thực hiện một vài tùy chỉnh trên bản sao của SQLite để phục vụ cho mục đích của mình, gọi nó là libSQL. Họ "hào phóng" cho cộng đồng đóng góp thoải mái.

    Quay trở lại SQLite là mã nguồn mở chứ không phải là đóng góp mở. Chỉ có một nhóm người đứng đằng sau duy trì mã nguồn này, và họ không tiếp nhận yêu cầu kéo (pull request) từ những người khác. Đồng nghĩa mọi thay đổi hoặc tính năng đều là của nhóm người này tạo ra. Có vẻ như SQLite rất phổ biến nhưng cộng đồng không thể làm điều mà họ muốn là đóng góp cho sự phát triển của nó.

    Chúng ta biết rằng hầu hết ứng dụng mã nguồn mở thường đi kèm với một thư mục "tests" với các bài kiểm tra rất nghiêm ngặt. Điều đó giúp cho sự cộng tác trong phát triển trở nên dễ dàng hơn. Nếu muốn chỉnh sửa hoặc thêm một tính năng mới, trước hết bạn cần phải đảm bảo sự thay đổi vượt qua được tất cả bài kiểm tra. Nhiều thông tin cho rằng SQLite không công khai bộ kiểm tra này. Điều này vô tình gây khó khăn cho những ai muốn chỉnh sửa mã nguồn. Vì họ không chắc chắn rằng liệu triển khai mới của mình có phù hợp với những tính năng cũ hay không.

    tursodatabase/limbo là dự án viết lại SQLite bằng Rust đã nhắc đến ở đầu bài. Họ nói rằng nó hoàn toàn tương thích với SQLite và nguồn mở hoàn toàn. limbo đang trong giai đoạn hoàn thiện. Chúng ta hãy chờ xem kết quả trong tương lai thế nào nhé. Bài viết chi tiết tại Introducing Limbo: A complete rewrite of SQLite in Rust.

    » Xem thêm

Vấn đề

Hàng này công việc của chúng ta thường xuyên tiếp xúc với git, thế nên chắc hẳn mọi người đều biết trong git có các khái niệm về nhánh (branch) cùng các lệnh xử lý nhánh như checkout, merge, rebase hay là revert...

Khi phát triển thêm một tính năng mới, chúng ta thường checkout từ nhánh hiện tại sang một nhánh khác để làm việc. Môi trường làm việc nhóm sẽ có nhiều người phát triển nhiều tính năng, mỗi tính năng nằm trên mỗi nhánh, chúng có thể phát triển độc lập và song song với nhau. Mọi thứ sẽ thật hoàn hảo nếu như một ngày đẹp trời khi tiến hành merge các nhánh lại với nhau mà không hề xuất hiện bất cứ xung đột (conflic) nào.

Gitflow được sinh ra để quy định những nguyên tắc trong phân nhánh và phát triển tính năng cũng như phát hành sản phẩm. Đó là một quy trình làm việc với git sao cho thuận tiện nhất cho những người phát triển.

Gitflow là gì?

Gitflow là khái niệm chỉ cách phân nhánh và phối hợp phát triển (development), phát hành (release) tính năng bằng cách sử dụng git.

Gitflow được biến tấu theo từng nhóm phát triển, tuỳ vào môi trường và điều kiện thì người quản lý có thể đặt ra những quy tắc về luồng phát triển ứng dụng. Có thể là tự nghĩ ra hoặc là dựa trên một flow đã có từ trước.

Thực tế có rất nhiều mô hình gitflow được giới thiệu, tuy nhiên nổi tiếng nhất là flow dựa trên mô hình phân nhánh của Vincent Driessen.

Gitflow theo mô hình phân nhánh Vincent Driessen

gitflow Vincent Driessen

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/feature-name. (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/fix-name để 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 và kết thúc phiên sửa lỗi.

Như bạn có thể thấy với mô hình gitflow trên chúng ta cần có ít nhất 3 môi trường để chạy mã là production, stagging và develop tương ứng với 3 nhánh master, release và develop. Tuy nhiên trong thực tế không nhất thiết phải có đầy đủ cả 3 mà tuỳ vào dự án chúng ta sẽ chỉnh sửa lại gitflow cho phù hợp và tối ưu nhất.

Gitflow theo Vincent Driessen khá là phức tạp và có thể làm chậm quy trình phát triển hay số lượng xung đột mã (conflic) cao do số lượng nhánh của nó. Bù lại mọi công việc đều rõ ràng, cách nhánh có nhiệm vụ riêng của nó và dễ dàng thiết lập nhiều môi trường (develop, stagging, production).

Ví dụ chỉ cần môi trường develop và production, nhưng vẫn đảm bảo tính năng được phát triển ở nhánh feature được checkout từ develop, sau khi hoàn thành tính năng merge develop vào master rồi "go production".

Vậy thì ngoài các flow đã nêu trên thì còn flow nào nữa không? Tất nhiên là có rồi :D, Github và cả Gitlab đều đề xuất một gitflow khi làm việc trên nền tảng của họ. Nếu có thời gian tôi sẽ thêm bài viết nói về gitflow của hai ông lớn trong nghề git này.

Tổng kết

Bài viết trên tôi vừa trình bày về khái niệm của gitflow cùng với mô hình gitflow theo biểu đồ phân nhánh của Vincent Driessen. Gitflow được sinh ra để giải quyết vấn đề làm việc nhóm một cách thuận tiện và ít bị conflic nhất, đồng thời gitflow cũng là đặc trưng của một đội phát triển phần mềm. Còn bạn hiện đang áp dụng gitflow nào hãy chia sẻ cho mọi người biết nhé!

Cao cấp
Hello

5 bài học sâu sắc

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Mỗi sản phẩm đi kèm với những câu chuyện. Thành công của người khác là nguồn cảm hứng cho nhiều người theo sau. 5 bài học rút ra được đã thay đổi con người tôi mãi mãi. Còn bạn? Hãy bấm vào ngay!

Xem tất cả

Đăng ký nhận thông báo bài viết mới

hoặc
* Bản tin tổng hợp được gửi mỗi 1-2 tuần, huỷ bất cứ lúc nào.

Bình luận (1)

Nội dung bình luận...
Avatar
Nguyễn Văn Nhật2 năm trước
Gitflow trên khá rắc rối mà tôi làm ở các công ty thường sẽ có gitflow rút gọn hơn, vấn đề là việc áp dụng mô hình trên khá phức tạp và mọi người có xu hướng làm việc không nghiêm túc hay chỉ thời gian đầu
Trả lời
Avatar
Nguyễn Văn Nhật2 năm trước
Đúng thế như cty mình flow tuỳ dự án bởi không phải maintain nhiều version cùng lúc
Avatar
Tùng Nguyễn2 năm trước
Các cty thường sẽ rút ngắn luồng này xuống
Bấm hoặc cuộn mạnh để sang bài mới