Là một chiến lược hợp nhất như Git Flow thực sự là một mô hình chống?


30

Công ty của tôi đang sử dụng Git và đang sử dụng sơ đồ phân nhánh đặc biệt - công việc được thực hiện trong tổng thể và các chi nhánh được dành riêng cho các bản phát hành. Điều này hoạt động tốt, miễn là tất cả các công việc được thực hiện trong một lần lặp làm cho nó vào chi nhánh, nhưng nếu một vấn đề sản xuất quan trọng xuất hiện, chúng tôi phải đảm bảo rằng công việc bằng cách nào đó làm cho nó thành cả hai chi nhánh.

Gần đây, chúng tôi đã có một số "niềm vui" với các chi nhánh. Đó là một vấn đề đau đầu về hành chính, đảm bảo rằng tất cả các công việc sẽ đưa nó vào mọi chi nhánh và một số lỗi đã được sửa trên một nhánh không biến nó thành chủ cho đến khi có ai đó chỉ ra điều đó.

Tôi tình cờ gặp Git Flow một lúc trước và tôi cảm thấy rằng đó sẽ là một giải pháp cho vấn đề của chúng tôi - mã không thấm qua tất cả các cách để phát hành, hoặc tất cả các cách quay trở lại. Điều hấp dẫn duy nhất là sự dẫn dắt của tôi đã nói rằng loại phát triển này là một mô hình chống - phát triển dữ dội trong hai tuần, sau đó dành ba để giải quyết các xung đột hợp nhất.

Tôi không hoàn toàn chắc chắn rằng mình đồng ý và kể từ khi tôi đưa nó lên, công việc đã hoạt động trở lại như bình thường. Chỉ gần đây chúng tôi đã có một số điểm đau lớn với điều này.

Tôi muốn biết - tại sao loại sơ đồ phát triển này sẽ được coi là một mô hình chống? thực sự là một mô hình chống?


1
Phần "Quy tắc 3" từ blogpost cũ của Ted Dziuba có thể giúp minh họa làm thế nào nó có thể là một mô hình chống.
Isxek

5
IMO, thời gian thực tế bạn dành để nghĩ về kiểm soát phiên bản càng nhiều, điều đó càng sai với toàn bộ người dùng -> hiện tượng công cụ ở nơi đầu tiên.
Erik Reppen

@ErikReppen: Tôi muốn đưa tâm trí của mọi người ra khỏi kiểm soát phiên bản và có một quy trình mà mọi người đều có thể làm quen. Bằng cách này, chúng ta không phải lo lắng về những điều như liệu đây có phải là mô hình chống hay không.
Makoto

6
@Makoto Bất cứ điều gì vi phạm KISS là chống mẫu, IMO. Đây là nơi người dùng quyền lực của VCS có xu hướng làm tôi phát điên.
Erik Reppen

6
Thuật ngữ "antipotype" giống như "thực hành tốt nhất", ở chỗ nó thường đóng vai trò là cái cớ để mọi người tắt não. Đừng chấp nhận khái niệm này nếu người dẫn đầu không thể cho bạn biết rõ anh ta có kinh nghiệm gì với nó và tại sao nó tệ.
Kyralessa

Câu trả lời:


30

Anh ấy chủ yếu đề cập đến các nhánh tính năng của mô hình. Các nhánh tính năng đã được tuyên bố chống mẫu từ lâu khi các nhánh tồn tại trong nhiều tháng và các hệ thống kiểm soát phiên bản không thể hợp nhất để cứu mạng chúng. Các nhánh tính năng kéo dài một hoặc hai tuần có ít vấn đề hơn, đặc biệt là nếu bạn liên tục sáp nhập từ develop vào nhánh tính năng trong thời gian đó. Bất cứ điều gì lâu hơn thế vẫn không được khuyến khích.

Ngay cả khi bạn không sử dụng nhánh nhánh tính năng của luồng git, các phần khác vẫn hữu ích trong việc đảm bảo bạn có được sự hợp nhất sạch sẽ và các thay đổi của bạn được lan truyền theo đúng hướng.


3
Kinh nghiệm của tôi với các nhánh tính năng, hoặc cách chúng tôi đã thực hiện chúng, là có thể đau lòng với chúng nếu chúng được phép sống nhiều hơn một lần lặp. Một quy tắc tuyên bố rằng tất cả các tính năng phải được hợp nhất vào lần lặp trước khi phát hành sẽ tốt, để giảm bớt nỗi đau của sự hợp nhất - và chàng trai, chúng ta đã có một số đau khổ nghiêm trọng đằng sau những điều đó ...
Makoto

6
Kinh nghiệm của tôi là bạn có thể có những thứ địa phương nằm xung quanh miễn là bạn giữ nó được hợp nhất với chủ gần đây và hoặc phát triển khi thích hợp.
Jan Hudec

2
@JaHudec ... hoặc cho đến khi bạn có hai điều xung quanh đang mâu thuẫn theo một cách nào đó. Bạn phải luôn có cái nhìn tổng quan về việc đó đang được thực hiện ...
johannes

5
Đọc một chút về nó, và tài liệu tham khảo của Martin Fowler dường như chỉ ra rằng các nhánh tính năng được thực hiện trong một luồng tích hợp liên tục có thể hoạt động - nếu chúng được thực hiện trong các vết cắn nhỏ hơn so với hầu hết mọi người sẽ xem xét thực hiện chúng. Vì vậy, theo một nghĩa nào đó, bạn đúng - chưa đầy hai tuần như một thời gian để sống trên một nhánh tính năng có vẻ phù hợp. Tuy nhiên, tôi không thấy cách các nhánh tính năng là mô hình chống.
Makoto

3
Bạn đúng. Chúng chỉ là một mô hình chống khi chúng sống quá lâu mà không được hợp nhất. Đôi khi mọi người vẫn chống lại một ý tưởng khi họ không nhớ những lý do cơ bản.
Karl Bielefeldt

21

Sáp nhập là một điều buồn cười - càng ít thường xuyên thì càng khó, càng khó, mọi người sẽ càng sợ nó, họ sẽ càng ít làm điều đó.

Giải pháp là không cho phép các nhánh lệch quá nhiều hoặc không sử dụng các nhánh.

Nếu mọi người hiểu điều này, có lẽ bạn sẽ không gặp nhiều vấn đề với việc hợp nhất, nếu không - có thể các chi nhánh không phải là một ý tưởng tốt nếu không có sự giáo dục.


1
Không, không sử dụng các chi nhánh là không bắt đầu. Vấn đề chính khác là công việc có thể được thực hiện ở hai nơi khác nhau trong cùng một mã, vì vậy hy vọng chúng ta cũng có thể làm gì đó để giảm bớt điều đó.
Makoto

12
@makoto, khá thường xuyên tách rời mọi thứ trong mã làm cho xung đột ít xảy ra hơn. Nó có thể là sự phân tách rõ ràng của một chức năng thành các chức năng / lớp hoặc cao hơn để tránh các giả định không có giấy tờ giữa các mô-đun. Sau đó, những thay đổi trở nên cục bộ hơn.
maxim1000

1
@ maxim1000 Tôi đồng ý. Tôi nghĩ ai đó đã từng nói điều gì đó như "Một VCS là một người nghèo thay thế cho kiến ​​trúc mô đun [tách rời]"
8DH

+1 cho đoạn đầu tiên. Và vâng, không có giáo dục giống như gitflow là một ngõ cụt
daitangio 29/07/2015
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.