Trở ngại khi sử dụng Git Flow trong Subversion


10

Nhóm của tôi đang làm việc đang bắt đầu một dự án mới, sử dụng Subversion làm VCS của chúng tôi (bạn có thể xem xét bộ này trong mục đích của câu hỏi này). Chúng tôi vẫn đang trong giai đoạn đầu của dự án và đang cố gắng đồng ý về một mô hình phân nhánh. Dự án trước đây của chúng tôi dựa trên mô hình phiên bản không chuẩn dẫn đến các vấn đề khi quản lý các bản sửa lỗi nóng và các bản vá cho các bản phát hành hiện có.

Tôi đã tìm thấy các mô hình phân nhánh khác nhau khá phức tạp, nhưng một mô hình mà tôi hiểu khá rõ là git Flow . Tôi tò mò về mức độ khó / không mong muốn khi thực hiện một biến thể của điều này trong Subversion. Rõ ràng sẽ có một số khác biệt về những người hợp tác trong các chi nhánh. Các nhánh tính năng sẽ phải được tập trung thay vì giới hạn trong kho lưu trữ cục bộ, nhưng các khái niệm khác của mô hình nên có thể được tái tạo trong Subversion như tôi hiểu.

Điều gì sẽ là nhược điểm hoặc thách thức đối với phương pháp này. Điều tôi đã nghe là trong SVN "hợp nhất là tốn kém" so với Git. Nhưng tôi không hoàn toàn rõ ràng về ý nghĩa của điều này trong thực tế hoặc nó sẽ ảnh hưởng đến khả năng sử dụng luồng git như mô hình phân nhánh của chúng ta như thế nào.

Điều gì sẽ là mối quan tâm lớn nhất với phương pháp này. Có một cách tiếp cận rõ ràng tương tự mà tự nhiên hơn trong Subversion?

Câu trả lời:


12

Gitflow dựa trên các thực tiễn tốt nhất về phiên bản và phân nhánh mã nguồn. Một bài viết rất hay về điều này là Chiến lược phân nhánh SCM nâng cao

Điểm mà Vance đưa ra trong bài viết được liên kết là các nhánh khác nhau có vai trò khác nhau . Ông xác định vai trò của:

  1. Mainline (tất cả các chi nhánh từ đây)
  2. Phát triển (nơi thực hiện công việc phát triển)
  3. Bảo trì (nơi thực hiện công việc bảo trì)
  4. Tích lũy (Mang mọi thứ lại với nhau để chuẩn bị phát hành)
  5. Bao bì (đóng gói bản dựng để phát hành)

Trong gitflow, đây là:

  1. Phát triển, xây dựng
  2. chi nhánh tính năng
  3. Chi nhánh Hotfix
  4. Phát hành chi nhánh
  5. Bậc thầy

Bài viết về sự phân nhánh đã được viết với Perforce. Perforce là một VCS tập trung, giống như svn. Các mô hình phân nhánh mà ông mô tả hoàn hảo ánh xạ tới svn.

Chìa khóa để nhận ra là không phải gitflow được chuyển sang svn như thế nào, mà là cách áp dụng các khái niệm cơ bản giống nhau của phân nhánh và vai trò của các nhánh đối với các cấu trúc VCS khác nhau.

Tôi sẽ mạnh mẽ khuyên bạn nên đọc bài viết này, tôi không thể làm tín dụng nhiều đến nó. Cách mọi thứ được mô tả trong đó dựa trên triết lý xây dựng đường trục / đường chính mà bạn sẽ thấy dễ dàng ánh xạ svn tới.


1
Quay trở lại ý tưởng dẫn đầu thiết kế của gitflow là một sự cải tiến thông minh của câu hỏi ban đầu!
dùng40989

@ user40989 Tôi không chắc liệu Vincent Driessen (nvie) đã đọc bài báo hay chưa đưa ra khái niệm phân nhánh này, hoặc nếu anh ta tự mình khám phá lại điều này. Dù bằng cách nào, việc nhận ra vai trò cần thiết cho luồng công việc thông qua kiểm soát phiên bản giúp dễ dàng nhận thấy sự tương đồng giữa các phương pháp và thực tiễn tốt nhất.
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.