Lưu ý: Câu hỏi của tôi tập trung vào vấn đề cụ thể của tôi (liên quan đến Liferay) nhưng tôi hy vọng nó có thể hữu ích cho bất kỳ ai cần duy trì các phiên bản khác nhau của cùng một dự án trên git.

Tôi làm việc cho một công ty viết rất nhiều plugin cho Liferay Portal . Các plugin này (portlets, theme, v.v.) thường có thể tái sử dụng và tất nhiên, nên được cập nhật cho các phiên bản mới của cổng thông tin.

Tuy nhiên, thông thường phải di chuyển, giả sử, một portlet sang phiên bản mới của Liferay và để duy trì phiên bản trước đó. Ngoài ra, thường xuyên, chúng tôi phải tạo các tùy chỉnh rất cụ thể cho một số khách hàng, điều này không có nghĩa là được thêm vào "phiên bản chính".

Những điều cần thiết làm phức tạp công việc của chúng tôi, nhưng may mắn thay, chúng tôi có thể giả định một số đơn giản hóa. Ví dụ, các plugin được cập nhật thường xuyên bởi chỉ một lập trình viên tại một thời điểm. Rất hiếm khi có hai hoặc nhiều tính năng được thêm vào một plugin cùng một lúc.

Bây giờ, chúng tôi đang di chuyển đến Gitorious . Chúng tôi đang cố gắng hình thành một mô hình phân nhánh cho một kịch bản như vậy.

Mô hình của tôi

Những gì tôi đề xuất là:

1. Mỗi plugin sẽ có kho lưu trữ riêng trong Gitorious bên trong một dự án. Ví dụ, một portlet để hiển thị mèo con sẽ có một kittens-portletkho lưu trữ bên trong liferay-portletsdự án.
2. Khi tạo một plugin mới, hãy tạo nó tại một nhánh có tên theo phiên bản Liferay (ví dụ lf5.2:).
3. Mỗi lần cập nhật được thực hiện trên các plugin, bản cập nhật được phê duyệt và triển khai trong sản xuất, thẻ plugin với một phiên bản (ví dụ lf5.2v1, lf5.2v2vv.) *
4. Mỗi khi plugin được chuyển sang phiên bản mới của Liferay, chúng tôi sẽ phân nhánh phiên bản mới nhất (ví dụ: tạo chi nhánh lf6.0).
5. Sau khi sản xuất, người đứng đầu chi nhánh mới sẽ nhận được một thẻ như lf6.0v1.
6. Mỗi lần chúng tôi phải tùy chỉnh plugin theo cách dành riêng cho khách hàng, chúng tôi sẽ tạo một chi nhánh với tên của khách hàng (ví dụ: chúng tôi sẽ tạo một chi nhánh lf5.2clientcorpcho khách hàng của mình "ClientCorp Inc.")

Đây là một mô hình bất thường: nó sẽ không có mastervà rất nhiều chi nhánh không hợp nhất. Đây là cách tôi cho rằng một kho lưu trữ với mô hình như vậy sẽ như thế nào:

Một người bạn thấy hệ thống này khá phức tạp và dễ bị lỗi. Ông đề xuất mô hình Vincent Driessen xuất sắc và nổi tiếng , điều mà tôi thấy vẫn khó quản lý và đòi hỏi kỷ luật hơn. Nó là tuyệt vời (và đã được thử nghiệm!) Tất nhiên nhưng dường như quá phức tạp với tình hình của chúng tôi.

Người mẫu của bạn tôi

Sau đó, ông đề xuất một mô hình khác: chúng tôi sẽ có một kho lưu trữ cho mỗi plugin trong phiên bản Liferay (vì vậy chúng tôi sẽ bắt đầu tạo một kittens-lf5.2-portletvà sau đó a kittens-lf6.0-portlet), mỗi cái có một masternhánh và một developnhánh. Các mastersẽ luôn sẵn sàng để triển khai. (Hoặc nó có thể là cách khác, mastervà stable, như đề xuất của Steve Losh ).

Điều này rất đơn giản, nhưng tôi không thích hệ thống này:

1. nó có thể dẫn đến rất nhiều kho lưu trữ trong một dự án, khiến Gitorious khó duyệt.
2. Tên của thư mục của dự án có liên quan. Nếu ai đó sao chép kho lưu trữ vào một kittens-lf6.0-portletthư mục và tạo WAR bằng ant (như thường lệ), tên WAR cũng sẽ kittens-lf6.0-portletnhư vậy. Các phiên bản cũ của portlet này ( kittens-portletví dụ được đặt tên ) sẽ được coi là các portlet khác nhau (và có thể bị thiếu) trong một cổng thông tin được nâng cấp. Một chút quan tâm có thể tránh nó nhưng tôi muốn tránh nó.
3. Các phiên bản khác nhau của cùng một plugin sẽ được duy trì tách biệt. Tôi tan nát trái tim :(
4. kittens-lf6.0-portlet là một cái tên xấu xí cho một kho lưu trữ, tôi nghĩ vậy.

Tôi nghi ngờ hai điểm cuối cùng - cũng là hai điểm chủ quan hơn - là lý do chính cho sự không sẵn lòng của tôi. Tuy nhiên, tất cả bốn phản đối đứng.

OTOH, đề xuất của riêng tôi có vẻ lạ đối với bản thân tôi và tôi tự hỏi liệu có lỗi ẩn trên đó không. OT3rdH git mạnh mẽ và linh hoạt đến mức tôi nghĩ rằng tôi không cảm thấy xấu hổ khi khám phá những khả năng của nó.

Vì vậy tôi hỏi:

1. Điều gì sẽ là mô hình tốt nhất? Đề nghị của tôi? Mô hình của bạn tôi? Hệ thống Vincent Driessen truyền thống hiện nay?
2. Những mô hình phân nhánh khác mà bạn sẽ đề nghị?
3. Nếu bạn nghĩ rằng mô hình của tôi là xấu, tại sao bạn nghĩ như vậy? Tôi rất thích tìm hiểu những nhược điểm và điểm mù.

* Trên thực tế, tôi thích gắn thẻ cam kết với một phiên bản, v1nhưng rõ ràng thẻ trong git không nằm trong nhánh - nghĩa là tôi không thể có v1thẻ 1 lf5.2và một thẻ khác trong lf6.0- vì vậy tôi phải đặt tên cho chi nhánh. Có đúng BTW không?

Nếu tôi đọc đúng các nhánh này về cơ bản là độ lệch một lần so với đường phát triển chính của bạn, không bao giờ có nghĩa là được sáp nhập trở lại vào dòng chính và các tiến bộ trong dòng chính không bao giờ được áp dụng cho các nhánh này. Sự sai lệch duy nhất sẽ là sửa lỗi phù hợp với phiên bản mà chi nhánh dựa trên nhu cầu được áp dụng cho chi nhánh.

Câu trả lời bây giờ xoay quanh quy trình công việc hàng ngày của bạn, số lượng nhà phát triển làm việc trên bất kỳ một chi nhánh hoặc số lượng thay đổi nào là những người thừa kế đỏ. Tôi thấy nhu cầu chính của bạn là muốn biết các nhánh nào nhận được bản cập nhật sửa lỗi từ thay đổi nhánh chính và vì điều này tôi nghĩ rằng kho lưu trữ kết hợp với các nhánh sẽ hiệu quả hơn vì tất cả nằm ở một nơi. Nếu không bao giờ có nhu cầu thụ phấn chéo thì các kho riêng biệt sẽ thực thi điều đó, nhưng kịch bản đó không phù hợp với thực tế của dự án của bạn như tôi hiểu.

Mô hình Driessen sẽ hoạt động tốt nếu dự án của bạn cần hợp nhất các nhánh trở lại dòng phát triển chính, nhưng bạn không cần điều đó. Mặc dù vậy, tôi nghĩ rằng có công trong việc duy trì khái niệm InDevelopment và StableRelease nếu bạn đang làm việc trên một sản phẩm đang hoạt động.

Vì vậy, để tóm tắt, tôi nghĩ rằng dự án của bạn sẽ hoạt động tốt với mô hình phân nhánh của bạn cộng với một dấu gạch ngang cho dòng chính của bạn. Số dặm của bạn có thể thay đổi; Tôi đã luôn làm việc với một nhánh "phát hành đang chờ xử lý" chuyển thành một nhánh "sống" và một "bản phát hành tiếp theo" riêng biệt, tất cả đều yêu cầu sự thụ phấn chéo của các bản sửa lỗi và thay đổi ở nhiều điểm khác nhau để nhận thức của tôi có thể bị sai lệch.

Điều khiến tôi ngạc nhiên là thực tế là mỗi portlet đều có kho lưu trữ riêng (nhưng câu chuyện của bạn có thể chưa hoàn thành). Cá nhân tôi sẽ tạo ra một kho lưu trữ cho mỗi dự án. Các dự án thường có nhiều portlet và tất cả đều được xây dựng trong cùng một phiên bản so với cùng một phiên bản Liferay. Mỗi dự án có thể là một bản sao của một dự án hiện có, được xây dựng dựa trên một phiên bản Liferay khác nhau nhưng tôi sẽ chỉ chia một sản phẩm nếu sự khác biệt quá lớn. Nếu bản dựng hoạt động theo Liferay 5.1 và 5.2 tôi sẽ không chia dự án. Tôi sẽ sử dụng kịch bản hoặc Maven (hoặc cả hai) để cho mọi thứ hoạt động. Tôi sẽ sử dụng Wiki (hoặc Trello) để quản lý từng sản phẩm và với phiên bản Liferay nào nó có thể được xây dựng để chống lại.

Nhân tiện: Tôi là một lập trình viên Java, chuyên gia Maven, chuyên gia Xây dựng và có kinh nghiệm với Liferay và các máy chủ cổng thông tin khác (IBM WebSphere và Glassfish).

Nhưng đây chỉ là 0,02 € của tôi.