Làm việc theo nhóm mà không nhầm lẫn: 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ế cho các hệ thống kiểm soát phiên bản trong phát triển phần mềm. Trước tiên, bạn nên đọc bài viết của tôi về Git là gì và cách bắt đầu. Bạn đọc nó xong chưa? Tuyệt vời, chúng ta hãy đi! Dù muốn hay không, công cụ này do Linus Tovalds tạo ra sẽ không ngừng hoạt động. Vì vậy, thật hợp lý khi nói về cách các nhóm phân tán làm việc với Git và chiến lược phân nhánh nào họ nên chọn cho việc này. Đây không phải là một câu hỏi tầm thường. Khi tập hợp một nhóm phát triển mới chưa từng làm việc cùng nhau trước đó, chiến lược phân nhánh thường là một trong những điều đầu tiên cần quyết định. Và một số người sẽ 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 một số thông tin chung về họ.

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

Chúng thực sự cần thiết. Rất cần thiết. Bởi vì nếu nhóm không đồng ý về điều gì đó, thì mỗi thành viên trong nhóm sẽ làm theo ý mình:

• làm việc ở bất cứ ngành nào
• sáp nhập vào các chi nhánh khác tùy ý
• xóa một số chi nhánh
• tạo ra những cái mới
• và do đó, mỗi thành viên trong nhóm sẽ hành động trong một luồng không được quản lý.

Đó là lý do tại sao chúng tôi có ba chiến lược để xem xét dưới đây. Đi nào!

Luồng GitHub

Chiến lược phân nhánh này, thật kỳ lạ, được ưa thích trên GitHub :) Nó đi kèm với một bộ quy tắc :

1. Mã trong nhánh chính không được bị hỏng. Nó phải sẵn sàng để được triển khai bất cứ lúc nào. Nghĩa là, bạn không được đặt mã ở đó sẽ ngăn bạn xây dựng dự án và triển khai nó lên máy chủ.
2. Khi bạn dự định làm việc với chức năng mới, bạn cần tạo một nhánh tính năng mới 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 về yêu cầu kéo tại đây ) khi bạn nghĩ 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ề công việc đã hoàn thành).
4. Sau khi 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 sẽ được triển khai đến máy chủ ngay lập tức.

Theo GitHub Flow, trước khi bạn bắt đầu làm việc với một cái gì đó mới, có thể là một bản sửa lỗi hoặc một tính năng mới, bạn cần tạo một nhánh mới dựa trên master và đặt cho nó một cái tên phù hợp. Tiếp theo, công việc triển khai bắt đầu. Bạn nên liên tục gửi các cam kết đến máy chủ từ xa có cùng tên. Khi bạn kết luận rằng mọi thứ đã sẵn sàng, bạn cần tạo một yêu cầu kéo tới 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 trước khi nhấp vào "Chấp thuận". Thông thường, trưởng nhóm của dự án và người thứ hai chắc chắn nên xem qua. 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 các dự án. Điều này là do khi các thay đổi đi vào nhánh chính, chúng sẽ được triển khai đến máy chủ ngay lập tức.

GitFlow

Chiến lược trước đó (GitHub Flow) cốt lõi không quá phức tạp. 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, hình ảnh trên sẽ làm rõ điều đó :) 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 liên tục và một số loại nhánh tạm thời. Trong ngữ cảnh của GitHub Flow, nhánh chính là liên tục và các nhánh khác là tạm thời. chi nhánh liên tục

• sư phụ: Không ai được chạm hay đẩy bất cứ thứ gì vào nhánh này. Trong chiến lược này, bản chính đại diện cho 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: Nhánh phát triển. Nó có thể không ổn định.

Quá trình phát triển xảy ra 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ị phát hành phiên bản mới của dự án.
3. Nhánh hotfix — để nhanh chóng sửa lỗi do người dùng thực tìm thấy trên máy chủ thực.

chi nhánh tính năng

Các nhánh tính năng được tạo bởi các nhà phát triển cho chức năng mới. Chúng phải luôn được tạo 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 một yêu cầu kéo đến nhánh phát triển. Rõ ràng, các nhóm lớn có thể có nhiều nhánh tính năng cùng một lúc. Hãy xem lại hình ảnh ở đầu phần mô tả chiến lược GitFlow.

Chi nhánh phát hành

Khi bộ tính năng mới cần thiết đã sẵn sàng trong nhánh phát triển, bạn có thể chuẩn bị cho việc phát hành phiên bản mới của sản phẩm. Nhánh phát hành, được tạo dựa trên nhánh phát triển, sẽ giúp chúng tôi thực hiện việc này. 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 nhánh phát triển. Điều này được thực hiện để ổn định nhánh phát triển. Khi những người kiểm tra nói rằng nhánh đủ ổn định cho một bản phát hành mới, nó sẽ được hợp nhất vào nhánh chính. Sau đó, một thẻ, được gán một số phiên bản, được tạo cho cam kết này. Để xem một ví dụ, hãy nhìn vào hình ảnh ở phần đầu của chiến lược. Ở đó bạn sẽ thấy Thẻ 1.0— đây chỉ là một thẻ cho biết phiên bản 1.0 của dự án. Và cuối cùng, chúng ta có nhánh hotfix.

chi nhánh hotfix

Nhánh sửa lỗi nóng cũng có nghĩa là phát hành phiên bản mới cho nhánh chính. Sự khác biệt duy nhất là những bản phát hành đó không được lên kế hoạch. Có những tình huống khi lỗi xâm nhập vào phiên bản đã phát hành và được phát hiện trong môi trường sản xuất. Hãy dùng iOS: ngay sau khi phiên bản mới được phát hành, bạn sẽ ngay lập tức nhận được một loạt các bản cập nhật với các bản sửa lỗi được tìm thấy sau khi phát hành. Theo đó, chúng ta cần nhanh chóng sửa lỗi và phát hành phiên bản mới. Trong hì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 trên chức năng mới không phải dừng lại khi cần sửa lỗi trên máy chủ thực (hay như chúng tôi nói, "đang sản xuất" hoặc "đang sản xuất"). Nhánh hotfix nên được tạo từ nhánh chính, vì nó đại diện cho những gì hiện đang chạy trong sản xuất. Ngay sau khi bản sửa lỗi sẵn sàng, nó được hợp nhất thành chủ và một thẻ mới được tạo. Cũng giống như chuẩn bị một nhánh phát hành, một nhánh hotfix cũng nên hợp nhất bản sửa lỗi của nó trở lại nhánh phát triển.

quy trình làm việc rẽ nhánh

Trong quy trình forking, quá trình phát triển bao gồm hai kho lưu trữ:

1. Kho lưu trữ ban đầu, trong đó tất cả các thay đổi sẽ được hợp nhất.
2. Một kho lưu trữ ngã ba. Đây là bản sao của kho lưu trữ gốc, thuộc sở hữu của một nhà phát triển khác muốn thực hiện các thay đổi đối với bản gốc.

Âm thanh hơi kỳ lạ cho đến nay, phải không? Bất kỳ ai đã gặp phải sự phát triển nguồn mở đều đã quen thuộc với cách tiếp cận này. Chiến lược này mang lại lợi thế sau: quá trình phát triển có thể xảy ra trong kho lưu trữ rẽ nhánh mà không cần cấp quyền để phát triển chung trong nhánh ban đầu. Đương nhiên, chủ sở hữu của kho lưu trữ ban đầu có quyền từ chối các thay đổi được đề xuất. Hoặc để chấp nhận và hợp nhất chúng. Điều này thuận tiện cho cả chủ sở hữu của kho lưu trữ ban đầu và nhà phát triển muốn giúp tạo ra 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 quyết định rằng chúng hợp lý, những thay đổi sẽ được thêm vào (!!!).

Một ví dụ về quy trình làm việc forking

Quy trình forking được áp dụng trên GitHub khi có một thư viện mà bạn muốn sử dụng. Nó có một lỗi khiến bạn không thể sử dụng nó đầy đủ. Giả sử bạn đi sâu vào vấn đề và biết giải pháp. Sử dụng quy trình phân nhánh, bạn có thể khắc phục sự cố không có quyền làm việc trong kho lưu trữ ban đầu của thư viện. Để bắt đầu, bạn cần chọn một kho lưu trữ nào đó, chẳng hạn như Spring Framework . Tìm và nhấp vào nút "Fork" ở góc trên bên phải: 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ữ ban đầu sẽ xuất hiện trong tài khoản cá nhân của bạn, điều này sẽ cho biết rằng đó là một bản phân nhánh:Bây giờ 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, bạn có thể tạo một yêu cầu kéo tới 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 :

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 bạn càng có nhiều lựa chọn thì càng khó quyết định nên chọn chiến lược nào. Rõ ràng là không có câu trả lời duy nhất cho tất cả mọi người. Tất cả mọi thứ phụ thuộc vào tình hình. Điều đó nói rằng, có một số hướng dẫn có thể giúp với điều này:

1. Tốt nhất là chọn chiến lược đơn giản nhất trước. Chỉ chuyển sang các chiến lược phức tạp hơn khi cần thiết.
2. Cân nhắc các chiến lược có càng ít loại nhánh càng tốt cho nhà phát triển.
3. Xem xét ưu và nhược điểm của các chiến lược khác nhau, sau đó chọn chiến lược bạn cần cho dự án của mình.

Đó là tất cả những gì tôi muốn nói về chiến lược phân nhánh trong Git. Cảm ơn sự quan tâm của bạn :) Theo dõi tôi trên GitHub , nơi tôi thường đăng các sáng tạo của mình liên quan đến các 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.