Có bất kỳ sai sót với mô hình phân nhánh Git này?

Tôi đang hỏi về mô hình phân nhánh git hoặc quy trình làm việc này. Tôi thực sự thích điều này. Nó gây ấn tượng với tôi rất trực quan và hiệu quả, nhưng điều tôi đang hỏi là liệu có bất kỳ sai sót hay tiêu cực nào đối với phương pháp này chưa rõ ràng đối với tôi (đến từ một thế giới khác nơi ClearCase cai trị ngày đó).

(Bạn không cần trả lời mọi câu hỏi, bất cứ điều gì bạn có thể hữu ích)

1. Bạn có sử dụng điều này hoặc một quy trình phân nhánh git tương tự?

2. Bạn có xem đây là một cách tiếp cận hiệu quả?

3. Bạn có thấy bất kỳ sai sót với phương pháp này? Bất kỳ nhược điểm tiềm năng?

4. Nếu bạn có một cách tiếp cận tốt hơn, bạn có phiền chia sẻ, hoặc cung cấp một liên kết đến một bài viết hoặc thảo luận về nó?

Đối với hầu hết các phần, đây là quy trình công việc thông thường được sử dụng với bất kỳ VCS nào chúng tôi đã sử dụng cho đến nay. Với một số (CVS, SVN) khó thực hiện hơn, với GIT, điều đó không quan trọng. Điều đó nói rằng, tôi có hai nhận xét:

Đầu tiên, có hai trường phái tư tưởng khi nói đến các nhánh đặc trưng:

1. Hợp nhất chúng
2. Đánh bại họ

(1) là những gì bài báo dường như đề xuất. Vấn đề với các cam kết hợp nhất được gọi là Evil Merges . Cụ thể, những người tham gia các đường dẫn phát triển trong đó một hàm đã thay đổi ngữ nghĩa ở một trong các nhánh, nhưng hợp nhất tự động không thể vá tất cả các lần xuất hiện trong mã đến từ nhánh khác. Các hồi quy được giới thiệu theo cách đó nổi tiếng là khó gỡ lỗi. Là người dùng GIT, bạn thường có thể thoải mái hơn nhiều về hồi quy, bởi vì bạn phải git bisecttự động tìm ra nguyên nhân cho họ. Tuy nhiên, trong tình huống được mô tả, git bisectsẽ chỉ ra cam kết hợp nhất, điều này không giúp ích gì cho bạn cả.

(2) tránh vấn đề này bằng cách cố gắng duy trì lịch sử tuyến tính nhất có thể. Những cuộc nổi loạn đối nghịch tuyên bố nó vô hiệu hóa bất kỳ thử nghiệm nào bạn có thể đã thực hiện trước cuộc nổi loạn.

Cá nhân, tôi chắc chắn ở trại (2), vì tôi coi trọng tính hợp lệ của git bisectkết quả hơn là khả năng mất bảo hiểm kiểm tra, điều này dễ dàng được bù đắp bằng cách sử dụng hệ thống CI thích hợp.

Thứ hai, tôi đã quyết định cho tôi rằng đẩy giữa các nhà phát triển hiếm khi là một ý tưởng tốt. Có các vấn đề bảo mật liên quan đến việc cho phép mọi người ssh vào hộp của bạn để tìm nạp hoặc chạy git-deamon cục bộ, và quan trọng hơn, trong các đội không quá nhỏ, việc giám sát có thể bị mất khá nhanh.

Điều đó nói rằng, tôi hoàn toàn ủng hộ một kho lưu trữ dàn (đôi khi còn được gọi là đầu ), cho phép các chuỗi phụ chia sẻ tiến trình công việc của họ thông qua một máy chủ trung tâm, tuy nhiên, khác với máy chủ chính (thường là bên ngoài- phải đối mặt, nếu không công khai). Thông thường, mỗi chuỗi con sẽ duy trì một nhánh chủ đề cho riêng mình và một hệ thống CI sẽ thực hiện hợp nhất bạch tuộc định kỳ của tất cả các nhánh chủ đề thành một nhánh tích hợp lớn, phàn nàn về xung đột và xây dựng lỗi.

Tôi hiện đang trong quá trình thực hiện các phép tái cấu trúc lớn và lâu dài (chuyển đổi một ứng dụng từ bộ công cụ GUI này sang bộ công cụ GUI khác) và thực hiện quy trình làm việc trung tâm rebase thành công, bởi vì các thành viên khác trong nhóm tiếp tục làm việc trên các tính năng mới:

Chủ yếu có hai nhánh chính, masternơi các tính năng mới được phát triển và toolkit-conversionnhánh. Quy tắc quan trọng nhất là đơn giản: chỉ làm những việc trong toolkit-conversionchi nhánh có liên quan đến việc chuyển đổi. Bất cứ khi nào có một cái gì đó có thể được thực hiện trong master(bộ công cụ GUI cũ), tôi sẽ thực hiện nó ở đó và phản hồi các toolkit-conversionthay đổi của tôi sang phần masterđầu mới . Một quy tắc khác là giữ cho toolkit-conversionchi nhánh khá ngắn. Do đó, tôi thường sử dụng thiết lập lại, chọn cherry và sửa đổi cam kết và rebase để gắn kết các cam kết nhỏ hơn với các cam kết lớn hơn (cuối cùng có cùng mục đích). Điều này cũng hoạt động tốt khi tôi đã thử một cái gì đó không hoạt động tốt để "hoàn tác" thay đổi hoặc sau khi tôi đã cấu trúc lại một số mã bằng mã trợ giúp tạm thời.

Tôi đã quyết định chống lại việc hợp nhất các thay đổi từ mastervào toolkit-conversionchi nhánh, bởi vì điều đó sẽ khiến việc từ chối các cam kết trước đó trở nên khó khăn hơn nhiều để giữ cho chi nhánh sạch sẽ và dễ dàng xem xét. Ngoài ra, việc sáp nhập có thể đưa ra các xung đột mà các nghị quyết của họ không rõ ràng như khi giữ một lịch sử trong sạch.

Tất nhiên, luồng công việc này cũng có nhược điểm. Điều quan trọng nhất là, nó chỉ hoạt động tốt cho một người. Khi tôi buộc phải đẩy toolkit-conversionchi nhánh sau khi khởi động lại nó vào đầu của masternó, việc kéo nó trên một kho lưu trữ khác trở nên khó khăn (tự động khởi động lại vào nhánh theo dõi thường thất bại với xung đột).

Cuối cùng, toolkit-conversionchi nhánh của tôi vẫn ngắn, sạch sẽ và dễ xem xét. Tôi không thể tưởng tượng được đã làm điều này mạnh mẽ tương tự với, ví dụ, SVN.

Trong công ty tôi hiện đang làm việc, chúng tôi đã áp dụng một biến thể của mô hình phân nhánh này trong một thời gian. Chúng tôi cũng đã sử dụng scrum để chúng tôi thực hiện một nhánh cho mỗi quy trình làm việc.

Vấn đề duy nhất chúng tôi có cho đến nay là khi nhóm đủ lớn và có thể bắt đầu nhiều câu chuyện và những câu chuyện đó phụ thuộc vào nhau, nó trở thành một mớ hỗn độn để hợp nhất các thay đổi giữa các nhánh và trở lại thành chủ.

Bên cạnh đó, điều này đã được chứng minh là đáng tin cậy :).

Tôi hiện đang bận điều chỉnh quy trình công việc này. Tôi nghĩ rằng đây là một quy trình công việc khá tốt, bởi vì nó sử dụng mô hình phân nhánh trong đó git vượt trội.

Nhược điểm nhỏ duy nhất là nó cần một số kỷ luật trong việc giữ vững quy trình làm việc này và không cố gắng thực hiện các phím tắt.

Các nhà phát triển của kohana cũng sử dụng quy trình công việc này và họ có vẻ thích nó khá nhiều.

Bạn có sử dụng điều này hoặc một quy trình phân nhánh git tương tự?

Chúng tôi sử dụng một quy trình công việc tương tự tại nơi làm việc, nhưng ít phức tạp hơn một chút. Tuy nhiên, nó được truyền cảm hứng rất nhiều bởi quy trình làm việc này, vì tôi đã đọc bài viết này nhiều lần. Tôi thậm chí còn có bản pdf của mô hình phân nhánh được in màu bên cạnh bàn của mình :)

Bạn có xem đây là một cách tiếp cận hiệu quả?

Năng suất. Làm thế nào để bạn xác định năng suất? Vâng, trong suy nghĩ của tôi, điều quan trọng nhất là phải có chất lượng cao, ít nhất là cố gắng và đạt được chất lượng tốt hơn mọi lúc. Không ngừng cải tiến quy trình, vv Nếu bạn có thể tạo ra mã chất lượng, năng suất sẽ được hưởng lợi từ nó. Vì vậy, câu hỏi thực sự là: Điều này có cải thiện chất lượng của phần mềm không? Và câu trả lời của tôi cho điều đó chắc chắn là có.

Điều tôi thích nhất với kiểu mô hình phân nhánh này là nó giới thiệu các nhánh ở các lớp chất lượng khác nhau. Càng nhiều bên phải trong hình ảnh, độ ổn định cao hơn và chất lượng cao hơn. Nhánh chính là thánh và tất cả các cam kết trên nó nên được coi là phiên bản ổn định của phần mềm. Bạn càng đi bên trái, bạn càng thử nghiệm nhiều hơn và độ ổn định bạn nhận được càng thấp.

Ngay khi bạn kiểm tra các tính năng mới và sửa lỗi, bạn có thể chuyển dần chúng từ trái sang phải và do đó chuyển mã với chất lượng cao chính xác khi bạn biết rằng mã đáp ứng các yêu cầu chất lượng mà bạn yêu cầu về mã. Vâng, ít nhất là về mặt lý thuyết, vì bạn không thể kiểm tra mọi thứ đến 100% và biết chắc chắn rằng mã không chứa bất kỳ lỗi nào, bởi vì nó sẽ luôn có lỗi. Nhưng nó cho phép bạn giữ một sự tự tin cao.

Không có gì hấp dẫn hơn với tư cách là một lập trình viên, hơn là làm việc trong một hệ thống mà không ai tin tưởng vào mã, bởi vì họ biết nó chỉ hút và có vô số lỗi trong đó.

Bạn có thấy bất kỳ sai sót với phương pháp này? Bất kỳ nhược điểm tiềm năng?

Điều quan trọng là phải suy nghĩ thông qua mô hình phân nhánh của bạn để nó phù hợp với nhu cầu của tổ chức của bạn. Chỉ vì mô hình này hoạt động tốt với một số người, không nhất thiết có nghĩa là nó tối ưu hay mong muốn cho người khác.

Luôn có sự đánh đổi và thậm chí trong trường hợp này. Một sự đánh đổi là số lượng chi nhánh so với độ phức tạp. Bằng cách giới thiệu rất nhiều loại nhánh khác nhau, bạn tăng độ phức tạp của quy trình làm việc. Ví dụ, có thể chỉ sai khi luôn buộc mọi người tạo một nhánh tính năng mới, khi họ đang cố gắng sửa một lỗi đơn giản bằng cách thay đổi một vài dòng mã.

Chúng ta đều biết rằng các lỗi ít nhiều phức tạp để giải quyết. Vì vậy, khi một lỗi nhỏ được phát hiện, bạn có thể muốn cắt giảm sự phức tạp và quản trị để thoát khỏi chi phí phụ và chỉ để mọi người cam kết trực tiếp, ví dụ như chủ hoặc phát triển chi nhánh. Nhưng khi bản chất của các bản sửa lỗi của bạn trở nên phức tạp hơn, thì đáng để chi phí thêm đó để tạo ra các nhánh mới cho chúng. Đặc biệt là nếu bạn không chắc chắn về kích thước và độ dài của nó hoặc nếu bạn muốn cải thiện sự hợp tác giữa bạn và các nhà phát triển khác.

Nếu bạn có một cách tiếp cận tốt hơn, bạn có phiền chia sẻ, hoặc cung cấp một liên kết đến một bài viết hoặc thảo luận về nó?

Đây chắc chắn là một cách tiếp cận tốt và nó có thể phù hợp với hầu hết các trường hợp vì hầu hết chúng ta đều có quá trình phát triển tương tự, nhưng nó có thể không phù hợp với tất cả mọi người. Tôi đặc biệt khuyên bạn nên suy nghĩ về cách bạn xử lý mã của mình ngay bây giờ và cố gắng tạo một mô hình phân nhánh phù hợp với mô hình bạn đã có.

Điểm quan trọng nhất là bắt đầu với git và phần còn lại sẽ diễn ra tự nhiên. Bắt đầu đơn giản và dần dần cải thiện! Sáng tạo!

Chúc mừng