Các phương pháp tốt nhất để quản lý phiên bản

Đây là cải tiến đơn giản nhất mà bạn có thể thực hiện cho quy trình làm việc của mình, nhưng lại là điều mà một số nhà phát triển gặp khó khăn nhất. Khi sử dụng các công cụ quản lý dự án khác, có thể bạn đã chia nhỏ công việc thành các nhiệm vụ nhỏ, dễ quản lý. Các commit cũng cần được xử lý theo cách tương tự.

Một lần commit chỉ nên liên quan đến một nhiệm vụ hoặc một ticket, trừ khi một dòng mã duy nhất có thể tự động sửa chữa nhiều lỗi cùng lúc. Nếu bạn đang làm việc với một tính năng lớn, hãy chia nhỏ nó thành các nhiệm vụ nhỏ hơn và tạo các commit cho mỗi nhiệm vụ.

Ưu điểm lớn nhất của việc sử dụng các commit nhỏ là, nếu có sự cố xảy ra, bạn có thể phát hiện và hoàn tác các thay đổi không mong muốn dễ dàng hơn nhiều.

Thông điệp commit mô tả lịch sử của dự án. Tóm lại, sẽ dễ dàng hơn nhiều nếu bạn tìm thấy thay đổi đã thêm bảng điểm cao vào trò chơi của mình, nếu thông báo commit ghi là “đã thêm bảng điểm cao vào menu” thay vì “cá cược xem bạn có thể đánh bại điểm số của tôi trên những bảng mới này không!”

Khi làm việc với hệ thống quản lý tác vụ như Jira hoặc GitLab, việc thêm số hiệu tác vụ vào commit của bạn thậm chí còn tốt hơn. Nhiều hệ thống có thể được thiết lập để hoạt động cùng với các commit thông minh, cho phép bạn tham chiếu đến các ticket và thay đổi trạng thái của chúng từ thông điệp commit của mình.

Ví dụ, một lệnh commit có nội dung “JRA-123 #close #comment task completed” sẽ đặt trạng thái của ticket JRA-123 thành đã đóng, đồng thời giữ nguyên bình luận “task completed” trên ticket đó.

Để biết thêm chi tiết về cách thiết lập quy trình làm việc này, hãy xem tài liệu trong Jira hoặc dịch vụ Pivotal Tracker trong GitLab.

Lệnh “commit -a” (lệnh Git dùng để “commit tất cả các thay đổi”) hoặc bất kỳ lệnh tương tự nào của nó chỉ nên được sử dụng trong lần commit đầu tiên của một dự án. Thông thường, đây là trường hợp duy nhất tệp tin trong dự án là README.md.

Một commit chỉ nên bao gồm các tệp có liên quan đến thay đổi mà bạn đang commit vào kho lưu trữ. Bạn cần đặc biệt cẩn thận khi làm việc với các dự án Unity vì một số thay đổi có thể dẫn đến việc nhiều tệp được đánh dấu là đã thay đổi, chẳng hạn như các cảnh, Prefab hoặc Sprite Atlas, ngay cả khi bạn không có ý định thực hiện bất kỳ thay đổi nào đối với chúng.

Ví dụ, nếu bạn vô tình lưu thay đổi vào một cảnh mà người khác đang làm việc, điều này có thể gây rắc rối cho họ khi họ muốn lưu các thay đổi của mình và thấy rằng họ cần phải hợp nhất các thay đổi của bạn trước.

Đây là một trong những lỗi phổ biến nhất mà những người mới làm quen với hệ thống quản lý phiên bản thường mắc phải. Điều quan trọng cần hiểu là bạn chỉ nên lưu những thay đổi của riêng mình vào dự án. Để tìm hiểu thêm, hãy xem bài đăng trên blog này về cách tăng tốc quy trình làm việc của bạn.

Hãy cập nhật những thay đổi mới nhất từ ​​kho lưu trữ vào bản sao làm việc của bạn bất cứ khi nào có thể. Làm việc độc lập không phải là một ý hay, vì điều này chỉ làm tăng khả năng xảy ra xung đột khi hợp nhất. Xem bảng trên để hình dung quy trình làm việc hàng ngày điển hình cho mỗi hệ thống.

Quy trình quản lý chuỗi cung ứng nhựa (SCM) có một chút khác biệt vì bạn có thể làm việc theo cấu hình tập trung, phân tán hoặc đa địa điểm.

Cấu hình đa điểm có thể khá độc đáo, với mỗi người dùng làm việc trong một quy trình tập trung hoặc phân tán.

Hãy xem xét ví dụ sau:

• Hai đội
• Mỗi đội đều có một máy chủ tại chỗ.
• Các thành viên nhóm có thể đăng nhập cục bộ hoặc phân tán tại mỗi địa điểm, nhưng đều được hưởng lợi từ tốc độ của máy chủ tại chỗ gần đó.
• Các máy chủ tương tác và truyền dữ liệu qua lại với nhau để duy trì trạng thái đồng bộ hoàn toàn hoặc một phần.

Bất kể nhóm của bạn chọn hệ thống quản lý phiên bản (VCS) nào để làm việc, hãy đảm bảo rằng mọi người đều cảm thấy thoải mái khi sử dụng nó và hiểu rõ các công cụ mà họ có sẵn.

Nếu bạn đang làm việc với Git, không phải ai cũng cần sử dụng cùng một giao diện đồ họa (GUI) . Nhưng hãy ưu tiên đảm bảo mọi người đều cảm thấy thoải mái với quy trình commit > pull > push . Nói cách khác, họ cần có kiến ​​thức để chỉ sao chép những tập tin cần thiết.

Nếu bạn đang làm việc với Plastic SCM, hãy khuyến khích các nghệ sĩ trong nhóm của bạn làm quen với Gluon , một GUI) thân thiện giúp đơn giản hóa quy trình làm việc của họ. Gluon cho phép bạn lựa chọn các tệp tin mà bạn muốn làm việc, loại bỏ nhu cầu tải xuống và quản lý toàn bộ dự án. Nó cũng cho phép bạn khóa các tập tin, ngăn người khác chỉnh sửa chúng. Sau khi hoàn thành, hãy gửi lại các tệp vào kho lưu trữ và mở khóa chúng lại nếu cần.

Khi làm việc trên một dự án dài hạn với nhiều chu kỳ phát hành, việc phân nhánh tính năng sẽ mang lại lợi ích rất lớn cho quy trình làm việc của bạn. Thông thường, các nhóm làm việc trên cùng một nhánh của kho lưu trữ, thường được gọi là trunk, master hoặc main.

Khi bạn làm như vậy, toàn bộ dự án của bạn sẽ tiến triển theo cùng một tiến độ. Tuy nhiên, việc chia nhỏ công việc thành nhiều nhánh có thể giúp cộng tác hiệu quả hơn trong nhóm.

Trong Git, một quy trình làm việc cụ thể gọi là Git Flow tập trung vào việc sử dụng các nhánh khác nhau cho việc phát triển tính năng, sửa lỗi và phát hành phiên bản mới.

Vì vậy, nếu một nhà phát triển bắt đầu làm việc trên một tính năng mới trong một nhánh riêng biệt, nó sẽ được hợp nhất trở lại nhánh chính sau khi họ hoàn thành. Trong khi đó, một thành viên khác trong nhóm có thể thực hiện bản vá lỗi khẩn cấp cho phiên bản trước đó, hoặc sửa lỗi, và phát hành phiên bản mới một cách an toàn, mà không cần bao gồm bất kỳ tính năng nào vẫn đang trong quá trình phát triển.

Plastic SCM cũng có các nhánh tác vụ . Với phương pháp này, bạn tạo một nhánh mới cho mỗi nhiệm vụ mà bạn theo dõi. Trong Git Flow, chúng ta sử dụng các nhánh tính năng để phát triển các tính năng hoàn chỉnh, đôi khi là các tính năng lớn. Các nhánh nhiệm vụ trong Quản lý chuỗi cung ứng nhựa (Plastic SCM) được thiết kế để có thời gian tồn tại ngắn. Nếu một nhiệm vụ cần nhiều hơn một vài lần commit để thực hiện, rất có thể nó có thể được chia nhỏ thành các nhiệm vụ nhỏ hơn.

Perforce Helix Core sử dụng một hệ thống gọi là Streams để hỗ trợ kiểu quy trình làm việc này. Khi tạo kho lưu trữ để làm việc, bạn cần thiết lập nó theo loại kho lưu trữ luồng . Sau đó, bạn có thể sử dụng chế độ xem Biểu đồ luồng để tạo các luồng mới. Mỗi luồng (ngoại trừ luồng chính) đều cần có một luồng cha, để các thay đổi có thể được sao chép ngược trở lại luồng chính.

Có nhiều loại dòng suối khác nhau phục vụ cho các mục đích khác nhau. Khi bạn chuyển đổi giữa các luồng dữ liệu trên máy trạm cục bộ hoặc sao chép các thay đổi ngược trở lại nguồn, chỉ có siêu dữ liệu của các tệp đã thay đổi được hợp nhất, giúp quá trình thay đổi ngữ cảnh diễn ra nhanh hơn.

Sau khi hoàn thành công việc trên một nhánh tính năng, việc sử dụng pull request để đưa các thay đổi của bạn trở lại nhánh chính của kho lưu trữ là một thực hành tốt. Yêu cầu kéo (pull request) được tạo bởi các nhà phát triển của tính năng hoặc tác vụ đó. Thông thường, việc xem xét các thay đổi trước khi chấp nhận chúng vào nhánh chính là trách nhiệm của một lập trình viên cấp cao hoặc DevOps .

Cả Plastic SCM và Perforce đều có các công cụ tự động giúp quản lý việc hợp nhất các nhánh trở lại nhánh chính. Plastic SCM thực hiện điều này với sự trợ giúp của Mergebot , công cụ tự động hợp nhất các nhánh của kho lưu trữ sau khi chúng đã được xem xét và vượt qua quá trình xác thực. Perforce có một nền tảng khác, Helix Swarm , được sử dụng để quản lý việc xem xét mã nguồn và cũng có thể được thiết lập để kiểm thử tự động.

Ngay cả khi bạn đang thực hiện một dự án cá nhân, các nguyên tắc về tổ chức và kiểm soát phiên bản vẫn rất hữu ích.

Khi làm việc nhóm, việc ưu tiên giao tiếp rõ ràng là vô cùng quan trọng. Cả nhóm cần thống nhất các nguyên tắc: cấu trúc dự án như thế nào, sử dụng hệ thống quản lý phiên bản nào và quy trình làm việc trong hệ thống đó sẽ ra sao.

Bằng cách này, khi bạn bắt đầu tích hợp các công cụ khác như Jira, GitLab, công cụ xây dựng hoặc kiểm thử tự động, những công việc bạn đã làm để cấu trúc dự án và quy trình làm việc sẽ phát huy tác dụng.