Kiểm soát phiên bản với phát triển trò chơi - Khi nào tôi nên phân nhánh?

Gần đây tôi đã bắt đầu sử dụng Kiểm soát phiên bản với các dự án của mình (mặc dù tôi đang làm việc một mình với chúng). Tôi thấy rằng nó mang lại một cách hay để giữ lịch sử của toàn bộ quá trình phát triển (có theo dõi vấn đề) và cho phép tôi giữ các bản sao lưu cho các dự án của mình trên đường đi.

Khi tôi dần dần khám phá các tính năng và lợi thế của việc sử dụng kiểm soát phiên bản, tôi bị mắc kẹt xung quanh ý tưởng phân nhánh. Khi nào tôi nên làm điều đó?

Có nên mỗi lần tôi đi và phát triển một tính năng mới, hoặc chỉ thỉnh thoảng khi tôi đạt được một cột mốc nhất định?

Rõ ràng, việc phân nhánh khá vô dụng khi làm việc một mình, nhưng tôi muốn từ bỏ thói quen tốt bây giờ và làm quen với nó.

Khi tôi đang đọc cuốn sách Hoàn thành mã hóa trò chơi của Mike McShaffry (đây là một cuốn sách tuyệt vời), tôi đã hoàn toàn lạc lối khi tác giả đề nghị giữ ba nhánh, một cái gì đó dọc theo dòng:

• Chính : Chi nhánh phát triển chính nơi thay đổi thường xuyên được thực hiện.
• Vàng : Chi nhánh vàng nơi giữ cột mốc cuối cùng đạt được.
• Nghiên cứu : Chi nhánh để thử nghiệm các công cụ có thể tác động xấu đến Chi nhánh chính (sửa đổi các thành phần quan trọng của công cụ trò chơi, v.v.).

Có phải đó là cách nó được cho là? Làm thế nào nó thực sự hoạt động trong thế giới phát triển trò chơi với các nhóm phát triển lớn?

Về cơ bản: Khi nào một người thường phân nhánh (và hợp nhất) trong phát triển trò chơi?

Sự phân nhánh phụ thuộc một chút vào sự hỗ trợ của VCS cho tính năng này (tức là: liệu VCS làm cho nó dễ hay khó).

Nhưng ở mức tối thiểu, bạn muốn có một nhánh cho mỗi bản phát hành được hỗ trợ độc lập cho dự án của bạn. Đó là, nếu bạn có "Trò chơi 2" và "Mở rộng trò chơi 2 +" là các sản phẩm riêng biệt được xây dựng từ cùng một cơ sở mã, và bạn cần có thể vá và phát hành các bản cập nhật, thì bạn muốn có mỗi tồn tại trong nhánh riêng của họ khỏi cơ sở mã chính, do đó, việc sửa lỗi cho cơ sở mã lõi có thể được hợp nhất vào từng sản phẩm này một cách độc lập. (Thông thường, các nhánh này được tạo khi mỗi sản phẩm được phát hành, hoặc có thể vài ngày / tuần trước, nếu bạn có người làm việc với các thứ trong cơ sở mã mà bạn không muốn ra ngoài với bản phát hành ban đầu)

Khi làm việc với một VCS khiến việc sử dụng các nhánh trở nên khó khăn hoặc đau đớn (SourceSafe, svn, v.v.), thì có lẽ bạn sẽ hạnh phúc nhất khi duy trì một nhánh "phát hành" cho mỗi sản phẩm được phát hành và thực hiện phát triển chính của bạn trong "thân cây", hợp nhất các thay đổi từ "thân cây" vào các nhánh "phát hành" nếu và khi bạn cần phát hành hotfix cho các bản phát hành đó.

Mặt khác, nếu bạn đang làm việc với một trong những hệ thống VCS mới hơn được xây dựng xung quanh việc phân nhánh và hợp nhất (git, Bazaar, Mercurial, v.v.), thì có lẽ bạn sẽ hạnh phúc nhất khi phát triển trong thời gian ngắn chi nhánh "sống". Ví dụ: nếu bạn đang làm việc trên đường dẫn AI, bạn có thể tạo một nhánh "tìm đường" và triển khai mã trong đó. Khi bạn hoàn thành, bạn hợp nhất nhánh đó trở lại vào nhánh phát triển chính của bạn và (tùy chọn) xóa nhánh bạn đang làm việc. Lợi ích của phương pháp này là cho phép bạn làm việc trên nhiều nhiệm vụ cùng lúc, thay vì phải hoàn thành một nhiệm vụ nhiệm vụ trước khi bắt đầu vào việc tiếp theo.

Trong dự án nhà hiện tại của tôi (sử dụng git), tôi có năm nhánh tính năng khác nhau đang hoạt động, hoạt động trên nhiều tính năng khác nhau. Hai trong số chúng là các cách tiếp cận thay thế để làm điều tương tự (để định hình), hai là các ý tưởng cơ học trò chơi thử nghiệm và một là một công cụ tái cấu trúc lớn cho các hệ thống AI của tôi và thực sự bị phá vỡ theo cách mà mã không được biên dịch đúng hiện nay. Nhưng nó được cam kết trong nhánh tính năng của nó để tham khảo và sao lưu, và nó bị hỏng không ngăn tôi làm việc với các tính năng khác; Các nhánh tính năng khác (và cả thân phát triển chính) vẫn biên dịch và chạy chính xác.

Theo kinh nghiệm của tôi về phát triển trò chơi chuyên nghiệp đội lớn, chúng tôi vẫn chủ yếu bị mắc kẹt với các hệ thống kiểm soát phiên bản cũ hơn (và được hỗ trợ thương mại). Perforce có lẽ được sử dụng phổ biến nhất, tiếp theo là Subversion. Ở mọi nơi tôi đã làm việc, chúng tôi đã có một chi nhánh 'thân cây', và sau đó là một chi nhánh 'phát hành' riêng biệt cho mỗi lần giao hàng (cột mốc / bản demo / phát hành / vv). Thỉnh thoảng ai đó sẽ tạo một nhánh cá nhân cho một số thay đổi lớn mà họ đang thực hiện hoặc thử nghiệm, nhưng điều này cực kỳ hiếm và thường dành cho những việc như "chuyển đổi trò chơi để chạy với thư viện vật lý khác nhau" này có thể không thực sự chuyển sang phát hành sản phẩm.

Đã có một câu trả lời xuất sắc ở trên nhưng một điều cần lưu ý là khi bạn muốn phân nhánh và khi bạn muốn gắn thẻ.

Hầu hết các vcs sẽ cho phép bạn gắn thẻ (đôi khi họ gọi nó là ghi nhãn). Bạn nên áp dụng thẻ mỗi khi bạn tạo bản dựng chính (cho bản phát hành, hoặc bản thử nghiệm beta hoặc cho một tính năng đang hoạt động). Nếu bạn đang sử dụng một số loại Tích hợp liên tục (và bạn nên) thì hệ thống CI sẽ gắn thẻ các bản dựng thành công. Về cơ bản bất cứ khi nào bạn làm điều gì đó mà bạn có thể muốn quay lại (để tạo chi nhánh hoặc kiểm tra lại cách bạn đã làm một cái gì đó trong phiên bản đó), hãy tạo một thẻ / nhãn. Chúng thường có chi phí thấp và đơn giản để thêm.

Một điều khác tôi rất muốn khuyên là hãy giữ tài sản và mã của bạn trong cùng một hệ thống phiên bản. Có một nhánh (hoặc thẻ) mã là hoàn toàn vô dụng nếu bạn không thể so khớp (và sau đó là nhánh) các tài sản. Đây là một trong những lý do chính khiến các công ty trò chơi yêu thích Perforce - việc lưu trữ các tệp nghệ thuật nhị phân cũng rất vui vì nó đang lưu trữ mã và (không giống như git) có thể hiểu được với các loại phi kỹ thuật!

Ồ và bất cứ lúc nào bạn cảm thấy muốn kiểm tra các tệp đã biên dịch vào điểm dừng VCS của mình và suy nghĩ về cách bạn có thể tránh làm như vậy. Theo kinh nghiệm của tôi, nó hầu như luôn dẫn đến dữ liệu không khớp, thiếu nguồn (ví dụ, kết cấu DDS đã nén được kiểm tra nhưng không phải là png nguồn) và hỗn loạn xuống dòng. Nếu bạn có một đường dẫn tài sản được phục vụ tốt hơn bởi các tệp được xuất được lưu vào bộ nhớ cache ở đâu đó (vì vậy mọi người sẽ không tạo lại cùng một tập tin) bằng mọi cách có một quy trình xây dựng tài sản nguồn trong VCS của bạn và đặt các tệp đã xuất vào bộ đệm (hoặc ổ đĩa chung hoặc thậm chí là một VCS riêng). Nhưng đừng kiểm tra các tệp được xuất bằng tay - nó sẽ cắn bạn (đặc biệt nếu bạn đang làm việc trong một nhóm).

Tôi yêu cuốn sách đó, và tôi giới thiệu nó cho mọi người có sở thích liên quan. Đối với các dự án độc lập của một người đàn ông, không có nhu cầu thực sự để phân nhánh trừ khi bạn cần hoặc muốn tạo các phiên bản riêng biệt; như một cho Android và một cho PC, hoặc một cái gì đó dọc theo những dòng đó.

Như bạn đã nói, nếu bạn muốn từ bỏ những thói quen tốt, tôi sẽ đi theo cách tiếp cận của Mike. Nó rất có ý nghĩa và đó là cách tiếp cận tôi sử dụng trong hai dự án độc lập của mình.

Bất cứ điều gì bạn cần để có thể quay trở lại và làm thêm công việc trên, nên branchable (nhưng không nhất thiết phải phân nhánh ... chưa).

Lý do cho điều này là đơn giản. Bạn cần có khả năng phát hành một phiên bản cố định của mã đó, không phải bất kỳ mã nào khác, vì vậy tại thời điểm đó bạn cần phải làm việc trên một nhánh.

Các VCS khác nhau. Một số - như git - rất dễ dàng phân nhánh từ bất kỳ cam kết nào vào bất kỳ lúc nào, những người khác - như CVS - rất cồng kềnh để làm việc sau này.

Có lẽ bạn muốn mở một câu hỏi trên stackoverflow, hỏi làm thế nào để hoạt động tốt nhất với hệ thống kiểm soát phiên bản bạn đã chọn? Nếu bạn chưa thực sự bắt đầu với nhiều lịch sử, bạn có thể muốn mở một câu hỏi mô tả cách bạn làm việc và yêu cầu đề xuất hệ thống kiểm soát phiên bản tốt nhất cho bạn?