Làm việc theo nhóm mà không nhầm lẫn: Tìm hiểu các chiến lược phân nhánh trong Git

Giới thiệu

Git đã trở thành tiêu chuẩn công nghiệp trên thực tế để kiểm soát phiên bản trong quá trình tạo phần mềm. Để tìm hiểu git là gì và cách bắt đầu, trước tiên hãy đọc bài viết của tôi về nó. Bạn đọc nó xong chưa? Tuyệt vời, chúng ta hãy tiếp tục! Dù muốn hay không, nhạc cụ mà Linus Towalds tạo ra sẽ không ngừng hoạt động. Do đó, sẽ rất hợp lý khi nói về cách các nhóm phân tán hoạt động trong git và chiến lược phân nhánh nào cần chọn cho việc này. Và đây hoàn toàn không phải là một câu hỏi vu vơ. Thông thường, trong tình huống tập hợp một nhóm nhà phát triển mới chưa cộng tác với nhau, chiến lược phân nhánh là một trong những điều đầu tiên cần được quyết định. Và sẽ có người sùi bọt mép để chứng minh rằng chiến lược này tốt hơn chiến lược khác. Vì vậy, tôi muốn truyền đạt cho bạn thông tin về những gì chúng nói chung.

Chiến lược phân nhánh có cần thiết không?

Nhưng chúng cần thiết, và chúng vẫn cần thiết. Bởi vì nếu bạn không thống nhất được điều gì đó trong nhóm thì hóa ra mọi người sẽ làm theo ý mình:

• làm việc trong chi nhánh mà anh ấy muốn;
• sáp nhập vào các chi nhánh khác mà anh ta muốn;
• xóa một số nhánh;
• tạo cái mới;
• v.v.—mỗi thành viên trong nhóm đều ở trong một dòng chảy không kiểm soát được.

Vì vậy, dưới đây là ba chiến lược. Đi!

Chiến lược luồng GitHub

Chiến lược phân nhánh, dù có kỳ lạ đến đâu, vẫn được ưu tiên trong GitHub :) Kèm theo đó là một bộ quy tắc cần phải tuân theo:

1. Mã trong nhánh chính phải không bị gián đoạn và sẵn sàng triển khai bất kỳ lúc nào (nghĩa là bạn không thể đặt mã ở đó để ngăn cản việc xây dựng dự án và triển khai nó trên máy chủ).
2. Khi bạn dự định làm việc trên chức năng mới, bạn cần tạo một nhánh mới (nhánh tính năng) dựa trên nhánh chính và đặt cho nó một cái tên có ý nghĩa. Cam kết mã của bạn cục bộ và thường xuyên đẩy các thay đổi của bạn đến cùng một nhánh trong kho lưu trữ từ xa.
3. Mở Yêu cầu kéo (bạn có thể đọc yêu cầu kéo là gì tại đây ) khi có cảm giác rõ ràng rằng công việc đã sẵn sàng và có thể được hợp nhất vào nhánh chính (hoặc nếu bạn không chắc chắn nhưng muốn nhận phản hồi về xong việc).
4. Sau khi một tính năng mới trong yêu cầu kéo đã được phê duyệt, nó có thể được hợp nhất vào nhánh chính.
5. Khi các thay đổi được hợp nhất vào nhánh chính, chúng cần được triển khai ngay lập tức đến máy chủ.

Theo GitHub Flow, hóa ra là trước khi bạn bắt đầu làm việc với một thứ gì đó mới, dù là bản sửa lỗi hay tính năng mới, bạn cần tạo một nhánh mới dựa trên nhánh chính và đặt cho nó một cái tên phù hợp. Tiếp theo, công việc bắt đầu thực hiện. Bạn cần liên tục đẩy các cam kết đến một máy chủ từ xa có cùng tên. Khi bạn hiểu rằng mọi thứ đã sẵn sàng, bạn cần tạo yêu cầu kéo trong nhánh chính. Sau đó, ít nhất một hoặc tốt hơn là hai người nên xem mã này và nhấp vào Phê duyệt. Thông thường, trưởng nhóm dự án và người khác phải xem xét nó, sau đó bạn có thể hoàn thành yêu cầu kéo. GitHub Flow cũng được biết đến với việc thúc đẩy Phân phối liên tục (CD) trong một dự án. Bởi vì khi thay đổi được thực hiện trên nhánh chính, chúng phải được triển khai ngay lập tức lên máy chủ.

Chiến lược GitFlow

Chiến lược trước đó (GitHub Flow) về cơ bản không phức tạp lắm. Có hai loại nhánh: nhánh chính và nhánh đặc trưng. Nhưng GitFlow nghiêm túc hơn. Ít nhất bạn có thể hiểu điều này từ hình trên) Vậy chiến lược này hoạt động như thế nào? Nói chung, GitFlow bao gồm hai nhánh cố định và một số loại nhánh tạm thời (Trong bối cảnh của GitHub Flow, nhánh chính là vĩnh viễn và các nhánh khác là tạm thời). Các nhánh cố định:

• thầy: không ai được chạm vào cành này hay đẩy bất cứ thứ gì ở đó. Trong chiến lược này, bản gốc hiển thị phiên bản ổn định mới nhất được sử dụng trong sản xuất (nghĩa là trên máy chủ thực);
• phát triển là nhánh của sự phát triển. Nó có thể không ổn định.

Việc phát triển được thực hiện bằng cách sử dụng ba nhánh tạm thời phụ trợ :

1. Các nhánh tính năng - để phát triển chức năng mới.
2. Nhánh phát hành - để chuẩn bị cho việc phát hành phiên bản mới của dự án.
3. Các nhánh hotfix là một giải pháp nhanh chóng cho một lỗi đã được người dùng thực tìm thấy trên máy chủ thực.

Các nhánh đặc trưng

Các nhánh tính năng được các nhà phát triển tạo ra cho chức năng mới. Chúng phải luôn dựa trên nhánh phát triển. Sau khi hoàn thành công việc về chức năng mới, bạn cần tạo yêu cầu kéo trong nhánh phát triển. Rõ ràng là trong các nhóm lớn có thể có nhiều nhánh tính năng cùng một lúc. Một lần nữa, hãy chú ý đến hình ảnh ở đầu phần mô tả chiến lược GitFlow.

Nhánh phát hành

Khi số lượng tính năng mới cần thiết đã được chuẩn bị trong nhánh phát triển, bạn có thể chuẩn bị phát hành phiên bản mới của sản phẩm. Nhánh phát hành sẽ giúp chúng tôi việc này. được tạo ra dựa trên nhánh phát triển. Trong khi làm việc với nhánh phát hành, bạn cần tìm và sửa tất cả các lỗi. Bất kỳ thay đổi mới nào được yêu cầu để ổn định nhánh phát hành cũng phải được hợp nhất trở lại quá trình phát triển. Việc này nhằm mục đích ổn định và phát triển chi nhánh. Khi người kiểm tra nói rằng nhánh đủ ổn định cho bản phát hành mới, nó sẽ được sáp nhập vào nhánh chính. Tiếp theo, một thẻ được tạo trên cam kết này (thẻ: bạn có thể đọc thêm về thẻ này tại đây ), thẻ này được gán số phiên bản. Ví dụ: bạn có thể xem hình ảnh ở phần đầu của chiến lược. Vì vậy, Thẻ 1.0 chỉ là nhãn cho biết phiên bản 1.0 của dự án. Và điều cuối cùng là một hotfix chi nhánh.

Chi nhánh sửa lỗi nóng

Các nhánh hotfix cũng nhằm mục đích phát hành phiên bản mới trong bản gốc. Sự khác biệt duy nhất là việc phát hành này không được lên kế hoạch. Có những tình huống khi lỗi được phát hành và đã được phát hiện trong quá trình sản xuất. Ví dụ: iOS: ngay khi họ phát hành phiên bản mới, bạn sẽ ngay lập tức nhận được một loạt bản cập nhật kèm theo các bản sửa lỗi cho các lỗi được phát hiện sau khi phát hành. Về vấn đề này, cần phải nhanh chóng khắc phục lỗi này và phát hành phiên bản mới. Trong hình ảnh của chúng tôi, điều này tương ứng với phiên bản 1.0.1. Ý tưởng là công việc phát triển chức năng mới có thể không dừng lại ở những thời điểm bạn cần sửa một lỗi trên máy chủ thực (như chúng tôi nói, “đang sản xuất”: một lần nữa, một bản sao của quá trình sản xuất từ ​​tiếng Anh). Nhánh hotfix phải được tạo từ nhánh chính vì nó đại diện cho trạng thái hoạt động trong sản xuất. Ngay sau khi giải pháp cho lỗi đã sẵn sàng, nó sẽ được hợp nhất thành nhãn chính và nhãn mới được tạo. Cũng giống như việc chuẩn bị một nhánh phát hành, một nhánh hotfix nên hợp nhất giải pháp của nó vào nhánh phát triển.

Chiến lược Forking Workflow

Là một phần của chiến lược Forking Workflow, việc phát triển được thực hiện theo cách có hai kho lưu trữ:

1. Kho lưu trữ ban đầu nơi tất cả các thay đổi sẽ được hợp nhất.
2. Kho lưu trữ phân nhánh (đây là bản sao của kho lưu trữ ban đầu thuộc quyền sở hữu của một nhà phát triển khác muốn thực hiện các thay đổi so với kho lưu trữ gốc).

Nghe có vẻ hơi lạ cho đến nay phải không? Đối với những người đã từng gặp phải sự phát triển nguồn mở, cách tiếp cận này đã quen thuộc. Chiến lược này mang lại lợi thế sau: việc phát triển có thể được thực hiện trong kho lưu trữ nhánh mà không cấp quyền phát triển chung trong kho lưu trữ ban đầu. Tất nhiên, chủ sở hữu kho lưu trữ ban đầu có quyền từ chối những thay đổi được đề xuất. Hoặc đồng ý và giết họ. Điều này thuận tiện cho cả chủ sở hữu kho lưu trữ ban đầu và nhà phát triển muốn tham gia vào việc tạo ra một số sản phẩm. Ví dụ: bạn có thể đề xuất các thay đổi đối với nhân Linux . Nếu Linus cho rằng chúng hợp lý thì những thay đổi sẽ được thêm vào (!!!).

Ví dụ về quy trình làm việc Forking

Luồng phân nhánh được sử dụng trên GitHub khi có một số thư viện mà bạn muốn sử dụng. Nó có một khiếm khuyết khiến nó không thể được sử dụng đầy đủ. Giả sử bạn đã đào sâu đủ vào vấn đề và biết giải pháp. Bằng cách sử dụng chiến lược The Forking Workflow, bạn có thể giải quyết vấn đề này mà không cần cấp quyền làm việc trong kho lưu trữ thư viện gốc. Để bắt đầu, bạn cần chọn một kho lưu trữ, ví dụ như lõi Spring Framework ... Tìm nút Fork ở góc trên bên phải và nhấp vào nó: Quá trình này sẽ mất một chút thời gian, sau đó một bản sao của kho lưu trữ gốc này sẽ xuất hiện trong thư mục của bạn. tài khoản cá nhân, điều này sẽ cho biết rằng đó là một nhánh: Sau đó, bạn có thể làm việc với kho lưu trữ này như bình thường, thêm các thay đổi vào nhánh chính và khi mọi thứ đã sẵn sàng, hãy tạo Yêu cầu Kéo vào kho lưu trữ ban đầu. Để thực hiện việc này, hãy nhấp vào nút Yêu cầu kéo mới :

Lựa chọn chiến lược nào

Git là một công cụ linh hoạt và mạnh mẽ cho phép bạn làm việc bằng nhiều quy trình và chiến lược khác nhau. Nhưng càng có nhiều sự lựa chọn thì càng khó quyết định nên chọn chiến lược nào bây giờ. Rõ ràng, không có câu trả lời chung cho tất cả. Tất cả phụ thuộc vào tình hình. Tuy nhiên, có một số khuyến nghị có thể giúp ích cho việc này:

1. Tốt hơn là nên chọn chiến lược đơn giản nhất trước tiên. Chỉ chuyển sang các chiến lược phức tạp hơn khi cần thiết.
2. Hãy xem xét các chiến lược có càng ít loại nhánh nhà phát triển càng tốt.
3. Hãy xem xét ưu và nhược điểm của các chiến lược khác nhau và tùy theo dự án, hãy chọn chiến lược phù hợp.

Đó là tất cả những gì tôi muốn nói với bạn về chiến lược phân nhánh trong git. Cảm ơn bạn đã quan tâm :) Đăng ký tài khoản GitHub của tôi , tôi thường đăng tác phẩm của mình lên đó bằng nhiều công nghệ và công cụ khác nhau mà tôi sử dụng trong công việc của mình

Liên kết hữu ích

• Luồng GitHub: cách tốt nhất để sử dụng Git và GitHub
• Kéo yêu cầu trên GitHub hoặc Làm cách nào tôi có thể thực hiện thay đổi đối với dự án của người khác
• GitHub: Giới thiệu về yêu cầu kéo
• Tích hợp liên tục, phân phối và triển khai khác biệt
• Khái niệm cơ bản về Git: Làm việc với Thẻ
• Habr: Mô hình phân nhánh thành công cho Git