Nhức đầu sử dụng kiểm soát phiên bản phân tán cho các đội truyền thống?

Mặc dù tôi sử dụng và thích DVCS cho các dự án cá nhân của mình và hoàn toàn có thể thấy cách nó giúp việc quản lý đóng góp cho dự án của bạn từ người khác dễ dàng hơn (ví dụ: kịch bản Github điển hình của bạn), có vẻ như một nhóm "truyền thống" có thể có một số vấn đề đối với Cách tiếp cận tập trung được sử dụng bởi các giải pháp như TFS, Perforce, v.v. (Theo "truyền thống", ý tôi là một nhóm các nhà phát triển trong một văn phòng làm việc trong một dự án mà không ai "sở hữu", với khả năng mọi người đều chạm vào cùng một mã.)

Một vài trong số những vấn đề này tôi đã lường trước được, nhưng xin vui lòng đồng ý với những cân nhắc khác.

Trong một hệ thống truyền thống, khi bạn cố kiểm tra thay đổi của mình đối với máy chủ, nếu trước đó người khác đã kiểm tra thay đổi xung đột thì bạn buộc phải hợp nhất trước khi bạn có thể kiểm tra thay đổi của mình. Trong mô hình DVCS, mỗi nhà phát triển sẽ kiểm tra thay đổi cục bộ và tại một số điểm đẩy sang một số repo khác. Repo đó sau đó có một nhánh của tập tin đó mà 2 người đã thay đổi. Có vẻ như bây giờ ai đó phải được giao trách nhiệm xử lý tình huống đó. Một người được chỉ định trong nhóm có thể không có đủ kiến ​​thức về toàn bộ cơ sở mã để có thể xử lý việc hợp nhất tất cả các xung đột. Vì vậy, bây giờ một bước bổ sung đã được thêm vào khi ai đó phải tiếp cận một trong những nhà phát triển đó, bảo anh ta kéo và thực hiện hợp nhất và sau đó đẩy lại (hoặc bạn phải xây dựng cơ sở hạ tầng tự động hóa nhiệm vụ đó).

Hơn nữa, vì DVCS có xu hướng làm cho hoạt động tại địa phương trở nên thuận tiện, nên có thể các nhà phát triển có thể tích lũy một vài thay đổi trong kho lưu trữ cục bộ của họ trước khi đẩy, làm cho các xung đột đó trở nên phổ biến và phức tạp hơn.

Rõ ràng nếu mọi người trong nhóm chỉ làm việc trên các khu vực khác nhau của mã, thì đây không phải là vấn đề. Nhưng tôi tò mò về trường hợp tất cả mọi người đang làm việc trên cùng một mã. Có vẻ như mô hình tập trung buộc các xung đột phải được xử lý nhanh chóng và thường xuyên, giảm thiểu sự cần thiết phải thực hiện các vụ sáp nhập lớn, đau đớn hoặc có bất kỳ ai "cảnh sát" repo chính.

Vì vậy, đối với những người bạn sử dụng DVCS với nhóm của bạn trong văn phòng của bạn, làm thế nào để bạn xử lý các trường hợp như vậy? Bạn có thấy quy trình làm việc hàng ngày (hoặc nhiều khả năng hơn là hàng tuần) bị ảnh hưởng tiêu cực không? Có bất kỳ cân nhắc nào khác mà tôi nên biết trước khi giới thiệu DVCS tại nơi làm việc của tôi không?

Chúng tôi đã sử dụng Mercurial khoảng một năm. Mặc dù vấn đề đau đầu mà bạn đề cập vẫn tồn tại, cho đến nay, thách thức lớn nhất đối với việc áp dụng đầy đủ cho chúng tôi là đi vào suy nghĩ DVCS của các kho lưu trữ cục bộ (= cam kết thường xuyên.) đi.

Bạn đã nói:

Trong mô hình DVCS, mỗi nhà phát triển kiểm tra các thay đổi của họ cục bộ và tại một số điểm đẩy sang một số repo khác. Repo đó sau đó có một nhánh của tập tin đó mà 2 người đã thay đổi. Có vẻ như bây giờ ai đó phải được giao trách nhiệm xử lý tình huống đó.

Một cài đặt mặc định của Mercurial chặn hành vi này. Nó sẽ không cho phép đẩy nếu nhiều hơn một đầu sẽ được tạo trong repo từ xa mà không cần xác nhận thêm. Đối với các hoạt động hàng ngày, chúng tôi tránh điều đó. (Git đã đặt tên cho các đầu và mỗi đầu chỉ có thể được cập nhật nếu nó hợp nhất hoàn toàn phiên bản trước mà không cần xác nhận thêm, do đó, một lần nữa tình huống không thể xảy ra.

Vì vậy, vào cuối mỗi ngày làm việc, cần dành thời gian để dành cho cam kết, đây thực sự là những hoạt động sau:

1. Cam kết thay đổi cục bộ.
2. Kéo từ repo trung tâm.
3. Hợp nhất (& cam kết hợp nhất.)
4. Đẩy vào repo trung tâm.

Điều này giữ cho hoạt động hợp nhất trên một người gần đây đang làm việc với mã này và có thể tích hợp các thay đổi của họ nhanh như bất kỳ ai khác.

Như đã chỉ ra trong câu hỏi, điều này thực sự chỉ thêm nỗ lực khi hai người đang làm việc trên cùng một khu vực mã. Nếu đó là trường hợp, thì dù sao cũng có nhiều lợi ích hơn khi sử dụng DVCS, do đó, mức chi trả đã rõ ràng đối với các nhà phát triển đó. (Các lợi ích bổ sung bao gồm mỗi nhà phát triển có thể cam kết mã riêng và chơi với repo của riêng họ mà không cần nhà phát triển khác cản trở.)

Một vấn đề khác mà bạn đề cập:

Hơn nữa, vì DVCS có xu hướng làm cho hoạt động tại địa phương trở nên thuận tiện, nên có thể các nhà phát triển có thể tích lũy một vài thay đổi trong kho lưu trữ cục bộ của họ trước khi đẩy, làm cho các xung đột đó trở nên phổ biến và phức tạp hơn.

Điều này không tạo ra vấn đề hợp nhất cho chúng tôi, nhưng có thể tạo ra một vấn đề khác:

Tính linh hoạt của DVCS có nghĩa là có thể có nhiều quy trình công việc khác nhau, nhưng một số trong số đó là vô trách nhiệm. Với DVCS, nhu cầu về quy trình hoặc thủ tục rõ ràng tăng lên. Hoạt động giữ các thay đổi cục bộ có thể hoặc không thể phù hợp, tùy thuộc vào nhiều thứ.

Ví dụ: nhà phát triển có thể làm việc trên tính năng thú cưng trong thời gian rảnh trong vài tuần không? Trong một số môi trường, điều này được khuyến khích, trong một số điều này sẽ không phù hợp và tất cả các thay đổi sẽ sớm được tập trung hóa. Nhưng nếu một nhà phát triển đang giữ các thay đổi cục bộ, thì họ chắc chắn sẽ muốn kéo bất kỳ thay đổi liên quan nào để đảm bảo công việc của họ sẽ tiếp tục chơi độc đáo với vòng quay chung mới nhất.

Khi cao su gặp đường, phần mềm phát hành hoặc triển khai thường đến từ một repo trung tâm, vì vậy các nhà phát triển cần phải có những thay đổi của họ ở đó để thử nghiệm và triển khai.

Đó là câu chuyện của tôi, và tôi gắn bó với nó, trong ít nhất vài phút ...

Tiền đề cho câu hỏi của bạn dường như xoay quanh vấn đề "Sáp nhập rất khó và phải tránh". Các hệ thống DVCS loại bỏ rào cản này, trên thực tế, chúng làm được nhiều hơn, nắm bắt ý tưởng hợp nhất - do đó, bạn không nên sợ sáp nhập và hợp nhất các xung đột, vì không giống như các công cụ tập trung, các công cụ DVCS hỗ trợ nó theo thiết kế.

Như câu trả lời xuất sắc của Jamie F tuyên bố - Luồng công việc của Commit-Pull-Merge-Push được thực hiện thường xuyên (hàng ngày) có nghĩa là nếu bạn đang đi bộ trên một số công việc, bạn sẽ thấy nó sớm - miễn là có thể nhìn thấy, nó có thể được quản lý .

Các vấn đề bạn mô tả là nhiều hơn về cách bạn chọn sử dụng các công cụ.

Chúng tôi đã chuyển từ SVN sang GIT 6 tháng trước, sau khi sử dụng SVN và GIT tại địa phương trong một vài năm. Không ai sẽ quay trở lại, và xung đột hợp nhất đau đớn đã là quá khứ. Câu thần chú "Cam kết nhỏ và thường xuyên" là chìa khóa.

Khi tôi làm việc trong một nhóm sử dụng git, nguyên tắc cơ bản là: làm việc trên một nhánh riêng, sau đó, khi bạn sẵn sàng để công việc của bạn có sẵn cho các thành viên còn lại, hãy đẩy chi nhánh của bạn lên chủ trước khi bạn đẩy. (Sau đó xác nhận chi nhánh của bạn.)

Chiến lược này có nghĩa là chủ là một loạt các cam kết tuyến tính, và tất cả các vấn đề tích hợp đã được sửa chữa trên các chi nhánh trước khi chúng được công khai.

Một công cụ như SVN khuyến khích mạnh mẽ cách làm việc tích hợp chặt chẽ.

Tức là cam kết thường xuyên với một nhánh được chia sẻ (thân cây hoặc nhánh dev).

Đây là A-OK cho hầu hết các môi trường phát triển công ty mà tôi đã trải nghiệm, được hỗ trợ và khuyến khích hơn nữa thông qua việc sử dụng Tích hợp liên tục được hỗ trợ bởi các thử nghiệm tích hợp rộng rãi, thử nghiệm hồi quy và thử nghiệm đơn vị (Giúp các nhà phát triển cá nhân có được sự tự tin rằng họ không bị phá vỡ bất cứ điều gì bởi những thay đổi của họ).

DVCS cho phép bạn tự do làm việc độc lập hơn, điều mà bạn cần trong một số trường hợp và hỗ trợ cải tiến (được ca ngợi nhiều) cho việc sáp nhập không thể gây hại gì.

Nỗi lo lắng luôn đọng lại trong tâm trí tôi là thế này: Với sự tự do tuyệt vời đến sự cám dỗ để sử dụng sự tự do đó.

Chắc chắn, theo kinh nghiệm (có giới hạn) của tôi, tôi dành nhiều thời gian hơn để làm việc độc lập trong nhóm hiện tại (sử dụng Mercurial) so với những vai trò trước đây (Nơi chúng tôi sử dụng SVN, CVS & P4).

Đây chỉ là một phần do công cụ, nhưng tôi nghĩ rằng đó là một quan sát hợp lý để làm điều đó, mà không có lý do thuyết phục để dành nỗ lực cho giao tiếp và phối hợp, mọi người sẽ có xu hướng làm việc tách biệt và cô lập.

Đây không hẳn là một điều xấu, nhưng tôi tin rằng đó là điều cần được xem xét.

Điều với kiểm soát phiên bản loại git / mercurial, là thường xuyên cam kết và đẩy đến máy chủ tập trung khi mã tốt. Một điểm cộng lớn với điều này là nó tạo ra các bản vá nhỏ, dễ áp ​​dụng trong các trường hợp xung đột. Ngoài ra, quy trình làm việc của bạn phải là một cái gì đó trong dòng:

1. Nhiều cam kết địa phương
2. Kéo từ máy chủ
3. Đẩy đến máy chủ

Việc kéo từ máy chủ này có thể tạo ra xung đột, nhưng để giải quyết vấn đề này, tất cả những gì cần thiết rất nhiều lần chỉ là một cuộc nổi loạn đơn giản, thay vì hợp nhất. Điều này, tôi cảm thấy, sẽ giữ lịch sử tuyến chính khá sạch sẽ và loại bỏ khá nhiều xung đột.

Đây cũng là trường hợp khi bạn kéo từ repo địa phương của đồng nghiệp, vì hai điều có thể xảy ra. Hoặc anh ấy đẩy đến máy chủ trước, điều này cũng tốt vì bạn đã có bản vá của anh ấy và không có xung đột nào xảy ra, hoặc bạn đẩy trước, điều đó có nghĩa là anh ấy sẽ chỉ nhận được bản vá của bạn khi anh ấy kéo.

Tất nhiên, đôi khi hợp nhất là một giải pháp tốt hơn, như một ví dụ nếu bạn làm việc trên một nhánh tính năng cần được hợp nhất thành chủ.

Trong quy trình làm việc của bạn, bạn đang nói về việc mọi người phải rõ ràng đến một nhà phát triển khác và bảo anh ta khắc phục xung đột, nhưng điều đó không cần thiết. Máy chủ trung tâm là "ông chủ" và những gì bạn chủ yếu nên làm việc chống lại. Nếu thay đổi của bạn áp dụng cho repo trung tâm, thì ok. Nếu không, công việc của BẠN là khắc phục xung đột, điều này có thể yêu cầu nhà phát triển mà bạn xung đột để giúp hiểu được những thay đổi của anh ấy / cô ấy. Đây là một cái gì đó bạn nhìn thấy khi bạn cố gắng kéo / rebase từ máy chủ. Vì vậy, hãy vui vẻ cam kết và giải quyết các xung đột khi bạn nên rút từ máy chủ.

Nguyên tắc làm việc với kho lưu trữ tập trung là giống nhau khi làm việc với hệ thống tập trung hoặc phân tán không khóa:

• Trong hệ thống tập trung, bạn:
  1. Nhận phiên bản mới nhất từ ​​dòng chính ("thân cây" trong lật đổ, "chính" trong git, ...)
  2. Sửa đổi các tập tin
  3. Hợp nhất các sửa đổi với phiên bản mới nhất từ ​​dòng chính bằng lệnh "update"
  4. Cam kết tuyến chính
• Trong hệ thống phân tán, bạn:
  1. Nhận phiên bản mới nhất từ ​​tuyến chính
  2. Sửa đổi các tập tin
  3. Cam kết tại địa phương
  4. Hợp nhất các sửa đổi với phiên bản mới nhất từ ​​dòng chính và cam kết kết quả cục bộ
  5. Đẩy vào tuyến chính.

Không có phiên bản phân tán nào sẽ cho phép bạn đẩy bản sửa đổi không hợp nhất hoàn toàn bản sửa đổi đầu trước đó (không có ghi đè đặc biệt; đôi khi nó hữu ích), vì vậy nó sẽ không được thực hiện mà không thực hiện bước hợp nhất (vì vậy sẽ không có hai phiên bản nào đó sẽ phải hợp nhất khi bạn quan tâm).

Bây giờ lưu ý rằng bốn trong số các bước là như nhau ngoại trừ thuật ngữ, nhưng các hệ thống phân tán thêm một bước bổ sung "3. Cam kết cục bộ". Ưu điểm lớn của bước này là khi cập nhật / kéo tạo ra xung đột và bạn không chắc chắn cách giải quyết hoặc mắc lỗi khi giải quyết chúng, bạn có thể quay lại, xem lại những gì bạn đã làm và làm lại việc hợp nhất. Subversion sẽ không nhớ bất kỳ ai trong số đó, vì vậy nếu bạn mắc lỗi giải quyết cập nhật, bạn sẽ bị lừa.

Đối với việc tích lũy thay đổi, mọi người cũng có xu hướng làm điều đó với hệ thống tập trung. Đặc biệt, nếu bạn phải chuyển đổi giữa các tính năng thường xuyên (như làm gián đoạn một số công việc lâu hơn để sửa lỗi hoặc thực hiện một số chỉnh sửa mà khách hàng cần gấp), mọi người thường sẽ cần phải thay đổi cục bộ đơn giản vì chúng chưa kết thúc. Vì vậy, sẽ tốt hơn nếu hệ thống ít nhất hỗ trợ ý nghĩa của nó.

Trong cả hai trường hợp, các vấn đề này cần được giải quyết bằng các hướng dẫn và giao tiếp phù hợp trong nhóm chứ không phải các công cụ. Với các công cụ linh hoạt hơn, các hướng dẫn là quan trọng hơn, nhưng các công cụ linh hoạt hơn cho phép giải quyết tốt hơn các trường hợp góc khác nhau.