Trường hợp tái cấu trúc thuộc về mô hình đặt tên nhánh GitFlow?

Gần đây tôi đã bắt đầu làm việc với mô hình GitFlow được triển khai bởi bitbucket. Và có một điều không hoàn toàn rõ ràng với tôi.

Chúng tôi cố gắng thường xuyên giải quyết các khoản nợ kỹ thuật của mình bằng cách đăng ký lại, lập kế hoạch và thực hiện các nhiệm vụ tái cấu trúc. Các nhánh tái cấu trúc như vậy kết thúc với các yêu cầu kéo được hợp nhất vào develop. Câu hỏi của tôi là các nhánh tái cấu trúc thuộc về GitFlow ở đâu?

Sử dụng featuretiền tố có vẻ hợp lý nhất, tuy nhiên nó không cảm thấy hoàn toàn đúng, bởi vì tái cấu trúc không thêm bất kỳ chức năng mới nào.
Tuy nhiên, việc sử dụng bugfixtiền tố có vẻ không đúng cũng như không có sửa lỗi tái cấu trúc lỗi thực tế .
Mặt khác, việc tạo một tiền tố tùy chỉnh có vẻ như phức tạp nếu không quá kỹ thuật.

Bạn đã có tình huống như vậy? Những thực hành nào bạn sử dụng để giải quyết điều này? Hãy giải thích tại sao.

— AMA
nguồn

Tại sao bạn cần một chi nhánh cho các nhà tái cấu trúc? Họ không thay đổi chức năng của sản phẩm theo định nghĩa, vì vậy bạn sẽ có thể thực hiện chúng trực tiếp trong quá trình phát triển.

— jonrsharpe

@jonrsharpe trong ngắn hạn, nó là thuận tiện hơn và kiểm soát. Thường có một vé Jira cho việc tái cấu trúc và nó cũng được xem xét mã trong yêu cầu kéo. Ngoài ra các bản dựng và kiểm tra được chạy cho nó, trước khi nó được hợp nhất. Chúng tôi cố gắng để phát triển chi nhánh xanh.

— AMA

Bạn là những thứ quá kỹ thuật - trong trường hợp này là quá trình. Tái cấu trúc khi bạn làm việc trên hệ thống, không phải là một gói công việc riêng biệt.

— Ông Nam Kỳ

Trong trường hợp đó: 1. Bạn có cảm tình của tôi; và 2. Tôi muốn sử dụng refactor, sau đó rõ ràng việc chuyển đổi từng hợp nhất dự kiến sẽ làm gì với sản phẩm (bugfix: sửa hành vi bị hỏng, tính năng: thêm hành vi mới, refactor: giữ lại hành vi trước đó). Nhưng @MrCochese là đúng, nó thực sự nên là một phần của công việc khác mà bạn không làm một nhiệm vụ riêng biệt. Cũng lưu ý rằng nếu các bộ tái cấu trúc của bạn phá vỡ bản dựng, chúng không phải là bộ tái cấu trúc!

— jonrsharpe

Một số công việc tái cấu trúc mà bạn đang làm nên thực sự là một phần của công việc chính. Tôi chắc chắn sẽ không tạo ra các nhánh tái cấu trúc thường xuyên, mà chỉ là một phần của nỗ lực dọn dẹp lớn hơn. Biến điều này thành thói quen sẽ khuyến khích các thói quen xấu khác, chẳng hạn như trì hoãn công việc dọn dẹp cho chi nhánh "tái cấu trúc".

— Robert Harvey

Tái cấu trúc công việc nên đi trong một nhánh tính năng.

Tiền tố "tính năng" chỉ là một từ để mô tả một nhiệm vụ lập trình rời rạc, bạn có thể chọn bất kỳ từ nào bạn thích, bất kỳ nhánh nào từ sự phát triển là một nhánh "tính năng" hoặc một nhánh "phát hành"

Thêm một tiền tố mới như "tái cấu trúc" là vấn đề. Vì bạn sẽ thường thực hiện một số thao tác tái cấu trúc khi thêm một tính năng, bạn chỉ đơn giản là tạo cho mình một vấn đề về đặt tên và thêm sự nhầm lẫn. I E. "một số nhánh tính năng của chúng tôi được gọi là 'tái cấu trúc', không có chúng không chứa tất cả các công việc tái cấu trúc và đôi khi chúng có sửa lỗi hoặc các tính năng trong đó '

các nhánh "hotfix" tương tự không được gọi là hotfix vì chúng chứa hotfix, nhưng vì chúng phân nhánh từ master chứ không phải phát triển

— Ewan
nguồn

cảm ơn bạn. Điều này nghe có vẻ hợp lý. Tôi sẽ chờ thêm một chút, và nếu không có câu trả lời nào khác, tôi sẽ chấp nhận câu trả lời của bạn.

— AMA