Tôi nên kiểm soát các phiên bản dự án của mình trên GitHub như thế nào

Tôi đang cố gắng dành nhiều thời gian nhất có thể cho GitHub hiện tại (thậm chí tôi là người duy nhất trong nhóm làm việc) để thực sự cảm thấy nó sẽ như thế nào đối với một ứng dụng công ty trong thế giới thực.

Một câu hỏi tôi đang có là kiểm soát phiên bản . Hãy nói rằng chúng tôi đã bắt đầu một dự án. Sau đó, các thành viên trong nhóm đã tạo ra một số chi nhánh và phát triển ở đó. Khi chúng tôi sẵn sàng cho việc sản xuất, chúng tôi đã hợp nhất tất cả các chi nhánh với masterchi nhánh. Cuối cùng, chúng tôi đi trực tiếp với phiên bản 1.0.

Bây giờ phiên bản đó 1.0đang hoạt động và chúng tôi có một số vấn đề được gửi cho phiên bản của phần mềm đó. Chúng tôi muốn bắt đầu phát triển phiên bản 1.1để khắc phục những vấn đề mà chúng tôi đã giới thiệu bằng cách gấp rút thực hiện dự án.

Bây giờ, câu hỏi là đây:

Làm thế nào chúng ta nên kiểm soát phiên bản ở đây?

Chúng ta có nên tạo một nhánh mới cho v1.0và giữ phiên bản 1.0phần mềm ở đó và phát triển trên một số nhánh (hoặc không), hợp nhất chúng với master, đi trực tiếp với phiên bản 1.1không?

Có quy ước ngoài kia cho những loại tình huống?

— kéo co
nguồn

Câu trả lời:

Tôi đã tìm thấy (và bắt đầu áp dụng) mô hình chi nhánh sau :

Hình ảnh từ nvie.com

^{(hình ảnh từ bài viết)}

Có rất nhiều thực tiễn tuyệt vời và các quy tắc nghiêm ngặt được mô tả trong bài viết đó, tôi đánh giá cao nó.

Điểm quan tâm:

Chi nhánh chính là nơi bạn gắn thẻ các phiên bản của mình. Không có sự phát triển xảy ra ở đây. Trong trường hợp có lỗi được triển khai trong sản xuất, bạn sửa lỗi trên nhánh hotfix, hợp nhất lại và gắn thẻ phiên bản mới.
Sự phát triển xảy ra trên các nhánh phát triển và tính năng. Cá nhân, tôi thực hiện sửa lỗi trên nhánh phát và các tính năng trên các nhánh tính năng.
Khi phần mềm bắt đầu đạt đến một bản phát hành, tôi rẽ nhánh để phát hành chi nhánh. Chi nhánh phát hành là nơi tôi thực hiện những bước cuối cùng. Số phiên bản Bump, thay đổi siêu dữ liệu, vv Và các lỗi nhỏ. Khi nó kết thúc, tôi hợp nhất nó thành chủ, gắn thẻ và gọi nó là một phiên bản.
Hai nhánh chính: chủ là "nhánh thánh"; Head của nó luôn là mã sản xuất mới nhất và phát triển là chi nhánh hàng đêm; Đầu của nó luôn phản ánh các bổ sung mới nhất (nhưng có thể không ổn định) vào mã.

Trong trường hợp cụ thể của bạn, các bước sẽ phụ thuộc vào mức độ vội vã của phiên bản đó. Nếu đó là các tính năng bị bỏ qua, tôi sẽ quay lại bản phát triển phát triển và làm lại toàn bộ. Nếu đó là lỗi trong phiên bản đã triển khai, tôi sẽ chuyển sang nhánh hotfix, sửa lỗi, hợp nhất lại và gắn thẻ v1.1. Nếu đó là cả hai, tôi sẽ sửa lỗi trước, sau đó thêm các tính năng thứ hai như được mô tả.

— Tamás Szelei
nguồn

Rất nhiều thông tin và chi tiết. Và cũng là một thực hành hoàn hảo. Nó cũng có rất nhiều ý nghĩa. Có chủ cho prod chỉ làm cho nó dễ dàng để duy trì. Tôi không quen với việc gắn thẻ một chi nhánh (hoặc cam kết?). Bạn có thể cho tôi một số chi tiết về điều đó? Làm thế nào chúng ta có thể làm theo mô hình trên?

— kéo co

Trong git, mục tiêu của việc gắn thẻ là một cam kết. Điều đó có nghĩa là bạn nói: "đây là cam kết này và tôi gọi nó là 'v1.3' kể từ bây giờ". Trong thực tế điều đó có nghĩa là bạn chuyển sang nhánh chính, hợp nhất trong nhánh phát triển (hiện đã ổn định), cam kết và gắn thẻ. Sau đó, bạn có thể liệt kê tất cả các thẻ, trở lại mã đó trong trường hợp bạn cần xem những gì đã được đưa vào sản xuất trong một bản phát hành trước đây. Có nhiều hơn một chút so với các thẻ đó (rất hữu ích cho phát triển phân tán quy mô lớn như kernel linux). Nếu bạn quan tâm, tôi đề nghị cuốn sách progit .

— Tamás Szelei

ProGit là một trong những cuốn sách mà tôi chắc chắn sẽ đọc từ đầu. Bây giờ tôi chỉ đọc những phần tôi quan tâm để hoàn thành công việc. Cho đến nay, chúng tôi đã phát triển trên nhánh chính và tôi nghĩ tôi nên duy trì điều đó. Nhưng tôi sẽ mở một nhánh khác được gọi productionvà sử dụng nó làm masternhánh theo mô hình trên.

— kéo co

Trong khi tôi đang thử mô hình này, một điều tôi đang vật lộn là: có một số nhánh hỗ trợ như được thảo luận tại bài viết, tính năng và các nhánh phát hành nhất định. có thể có nhiều chi nhánh trong tương lai. Ví dụ: FeedbackForm là một nhánh trong tương lai và ContactForm là một nhánh khác. Điều này là ok cho mô hình này, tôi đoán? Có nên có nhiều nhánh phát hành là tốt? và nếu vậy, tôi nên đặt tên cho chúng như thế nào?

— kéo co

Trước hết, bạn không cần phải tuân theo thư, chỉ cần thiết lập các quy tắc mà bạn giữ. Làm những gì tốt nhất cho bạn và phong cách của nhóm bạn. Thứ hai, vâng, nhiều tính năng và các nhánh phát hành là bình thường trừ khi bạn có dự án ngắn hạn với một tính năng và một bản phát hành :). Đặt tên, theo bài báo là phát hành- * và tính năng- *. Tôi đoán bạn đặt số phiên bản trong tương lai thay cho dấu hoa thị để phát hành và id trình theo dõi vấn đề trong trường hợp các nhánh tính năng.

— Tamás Szelei

Những gì tôi đã chứng kiến hầu hết thời gian là:

Sư phụ là cho bạn sản phẩm. Cuối cùng, tất cả phiên bản tương lai x.0 của bạn sẽ được cài đặt chính.
Bạn tạo một thẻ / chi nhánh cho mỗi phiên bản trong sản xuất để bạn vẫn có thể hỗ trợ chúng cho bất kỳ khách hàng nào yêu cầu.
Hợp nhất sửa chữa từ một hoặc khác là để giải quyết trên cơ sở từng trường hợp.

— xsace
nguồn

cảm ơn! Vì vậy, bạn nghĩ rằng việc giữ một nhánh có tên v1.0, v1.2 là hợp lý?

— kéo co

@tugberk miễn là phần mềm tương ứng tồn tại ở phiên bản đó, sẽ rất hợp lý khi giữ các nhánh xung quanh để bạn có thể nhanh chóng tắt chúng nếu bạn cần một nhánh hotfix cụ thể. Khi phần mềm không còn tồn tại ở phiên bản đó (không được hỗ trợ nữa nên không thể thực hiện thêm công việc nào nữa), có thể có ý nghĩa để thực hiện hợp nhất cuối cùng của chi nhánh và sau đó xóa nó. Bạn thậm chí có thể tạo một cam kết trống cuối cùng (tôi thường làm điều đó khi bắt đầu chi nhánh), chỉ cần nói "Đóng chi nhánh XXXX", nếu không bạn sẽ không giữ lịch sử chi nhánh (reflog có thể giúp một chút nhưng đây là cho mỗi kho lưu trữ)

— Patrick Mevzek