Giữ một lịch sử git sạch khi sử dụng gitflow - cam kết không được phát triển khi phát triển

Sử dụng gitflow, khi tạo một release-1.0.0nhánh và hợp nhất nó với cả hai mastervà develop, cả hai nhánh sẽ có một cam kết bị thiếu:

mastersẽ không có cam kết nơi release-1.0.0hợp nhất vớidevelop
developsẽ không có cam kết nơi release-1.0.0hợp nhất vớimaster

Thay vào đó, sau khi hotfix-1.0.1được tạo và sáp nhập vào master, khi nó được hợp nhất develop, các cam kết hợp nhất sẽ bao gồm các cam kết trước đó release-1.0.0được sáp nhập vào master; vì vậy nó sẽ trông như thế này:

User 'john doe' is trying to merge the following commits into 'develop' from 'hotfix-1.1.1'.

* merge release-1.0.0 to master
* merge release-1.1.0 to master
* Fix shopping cart critical bug

Nếu điều này nghe có vẻ khó hiểu, bạn có thể dễ dàng nhận thấy mọi thứ bạn thấy developthường là một vài cam kết phía sau master(mặc dù về mặt lý thuyết, chỉ nên đi trước vì nó là nhánh chính. Những cam kết đó được hợp nhất từ release-x.x.xđến master).

Làm thế nào điều này nên được xử lý để duy trì một lịch sử sạch?

git gitflow

— Christopher Francisco
nguồn

Vui lòng xác định "lịch sử sạch".

— Jace Browning

Bạn muốn một lịch sử trong sạch? Đừng sử dụng gitflow. Nó theo định nghĩa gây ô nhiễm lịch sử của bạn. Thay vào đó, hãy suy nghĩ về những gì bạn thực sự cần và xây dựng một quy trình công việc xung quanh đó, để nó thực sự phù hợp với cách bạn muốn làm việc.

— FP

Hợp nhất thành chủ sẽ là một "bản sao", không cần hợp nhất để phát triển. Thực hiện các bản sửa lỗi nóng từ nhánh phát hành trước đó, không phải bản chính và hợp nhất với cả hai từ đó và bạn sẽ không gặp vấn đề gì. Master không thêm nhiều vào mô hình để bạn thực sự có thể bỏ nó hoàn toàn, IMO.

— axl

@axl Tôi hiểu ý của bạn, nhưng tôi đang cố gắng theo dõi gitflow càng gần với tài liệu của nó. Tôi thà không thực hiện bất kỳ loại "hackz" nào vì gitflow đã được nhiều nhà phát triển chấp nhận, nên họ đã có một giải pháp cho điều đơn giản này

— Christopher Francisco

Có một số cuộc thảo luận về cách giải quyết các vấn đề khác nhau với GitFlow trên GitHub và các nơi khác. Đôi khi không phải là một viên đạn bạc.

— axl

Tôi nghĩ rằng một cách tiếp cận tốt là tránh có hai nhánh "chính", chủ và phát triển là loại dư thừa. Nó được giải thích kỹ lưỡng ở đây , thương hiệu cactus-flowcủa tác giả.

Một số điểm nổi bật trái ngược với dòng chảy git:

Chỉ một nhánh chính
Chỉ hợp nhất chuyển tiếp nhanh

Đối với tôi, điều cuối cùng rất quan trọng, vì sau khi sử dụng git-Flow trong một thời gian dài, tôi vẫn chưa thấy những gì hữu ích về việc --no-ffhợp nhất.

Tôi đang cố gắng theo dõi gitflow càng gần càng tốt với tài liệu của nó. Tôi thà không thực hiện bất kỳ loại "hackz" nào vì gitflow đã được nhiều nhà phát triển chấp nhận, nên họ đã có một giải pháp cho điều đơn giản này

IMHO đó là sai lầm lớn của bạn. Không có lý do gì để bạn dính vào git-Flow càng nhiều càng tốt. Nó có thể được sử dụng trong hàng ngàn dự án nhưng điều đó không ảnh hưởng đến dự án của bạn, không làm cho nó tốt.

Git-Flow là một điểm khởi đầu tốt nhưng bạn nên suy nghĩ về việc thích ứng nó với các công cụ và quy trình làm việc của bạn chứ không phải là cách khác.

— Sergio Basurco
nguồn