Một nhánh phát hành hoặc nhánh chính nên được gắn thẻ khi sử dụng gitflow?


16

Vấn đề này chỉ ra rằng:

Theo hiểu biết của tôi, việc đặt thẻ trên nhánh phát hành trước khi hợp nhất (chứ không phải trên nhánh chính) thực tế là điều chính xác để làm điều đó có thể được tìm thấy bởi git mô tả --tags từ nhánh phát triển, quá. Xem # 374

trong khi một bài khác :

Tôi đã vô tình cài đặt phiên bản 0.4.2 qua homebrew hôm nay và bị nhầm lẫn bởi cách hoạt động của việc gắn thẻ trong phiên bản đó. Trước đây (phiên bản 0.4.1) thẻ đã được tạo trên nhánh chính, sau khi nhánh phát hành được sáp nhập vào nó. Bây giờ có vẻ như thẻ được tạo trên cam kết cuối cùng của nhánh phát hành, dường như đó không phải là một ý tưởng tốt cho tôi. Đặc biệt là nếu bạn có một hệ thống xây dựng dựa trên thẻ git và tạo phiên bản phát hành nếu HEAD là một cam kết được gắn thẻ và phiên bản phát triển nếu một trong những cam kết sau đây. Ai đó có thể giải thích logic đằng sau sự thay đổi này với tôi? Và đối với phiên bản ngữ nghĩa, tôi sẽ không coi đây là một phiên bản nâng cấp ở cấp độ bản vá!

Trong nhóm của chúng tôi, chúng tôi đã và đã có nhiều cuộc thảo luận về điều này. Một số chỉ ra rằng một thẻ cần phải được tạo từ nhánh chính trong khi những người khác thích nhánh phát hành. Theo hình ảnh gitflow:

nhập mô tả hình ảnh ở đây

Có vẻ như thẻ được đặt trên bản gốc.


1
Tôi biết GitLab đấu tranh với các thẻ trên các nhánh khi bạn tỉa các nhánh cũ đi, vì vậy sẽ tốt hơn nếu thẻ nằm trên thẻ chính. Không chắc chắn về các công cụ git khác.
HorusKol

'Luồng git' ngụ ý rằng quy trình công việc (kém IMO) này là quy trình công việc git tiêu chuẩn hoặc chính thức. Không phải vậy.
Miles Rout

@MilesRout Quy trình công việc git yêu thích của bạn là gì?
030

đối với trường hợp của tôi, tôi sử dụng các giá trị của thẻ git để đặt tên cho phiên bản của ứng dụng khi phát hành, vì vậy tôi đặt nó trong nhánh phát hành.
Hãy nghĩ mã hai lần một lần vào

Câu trả lời:


16

Đầu tiên, bạn không thể gắn thẻ các chi nhánh, bạn chỉ có thể gắn thẻ cam kết.

Bạn nên gắn thẻ cam kết bạn thực sự phát hành. Đó là điểm của cam kết gắn thẻ phiên bản. Nếu bạn gặp sự cố với phần mềm của mình trong một số môi trường (sản xuất hoặc theo cách khác), bạn có thể tự tin nói rằng vấn đề được đưa ra bởi cam kết rằng bản phát hành đó có nguồn gốc từ.

(Đây là lý do tại sao mọi người nói về 'bản dựng có thể tái tạo': vì vậy họ có thể tin tưởng rằng quy trình phát hành của họ không giới thiệu các lỗi mới không xuất hiện trong môi trường xem trước / dàn dựng của họ và nếu họ có lỗi trong sản xuất giống nhau binary đang chạy trên máy của họ khi họ gỡ lỗi.)

Không có điểm nào gắn thẻ cam kết xanh thứ hai từ dưới lên (con xanh của cam kết được đánh dấu 'Chỉ sửa lỗi!) Là' v1.0 'vì bạn không phát hành cam kết đó cho sản xuất. Bạn đã phát hành cam kết trên chủ. Bạn thậm chí có thể thấy luồng git đã đánh dấu là 'Thẻ 1.0'.

Hãy nhớ rằng, các thẻ có một mục đích: để dễ dàng tìm thấy các cam kết. Bạn gắn thẻ một cam kết là 'v1.0' để bạn có thể dễ dàng tìm thấy thứ mà bạn đã phát hành dưới dạng phiên bản 1.0. Bạn không gắn thẻ vì mục đích có thẻ 'v1.0' ở đâu đó trong cây cam kết của bạn gần với cam kết bạn thực sự phát hành.

Nếu bạn gặp vấn đề trong việc tìm kiếm các thẻ từ nhánh phát triển của mình thì đó là một vấn đề hoàn toàn riêng biệt. Sửa chữa công cụ bạn sử dụng để tìm thẻ. Hoặc tốt hơn nữa: không sử dụng git-Flow. Nó trông đẹp trong sơ đồ đó vì các chấm màu đáng yêu và các đường được bố trí độc đáo, nhưng trong thực tế, nó trông giống như một mạng lưới lộn xộn điên cuồng của các đường màu và dấu chấm.


3
You should tag the commit you actually release. Vì vậy, nếu ví dụ 20 cam kết cần được phát hành nằm trong nhánh phát hành và nhánh này được sáp nhập vào chủ, thì cam kết hợp nhất đã được tạo phải được gắn thẻ để biết những gì đã được phát hành?
030

1
Có, cam kết hợp nhất sẽ được gắn thẻ. Là một biến thể của dòng chảy git, tôi cũng đã thấy việc tạo / gắn thẻ một "phiên bản cam kết riêng biệt" trực tiếp trênbranch:master
rmharrison
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.