Tại sao mọi người sử dụng Git một cách tập trung?

Tôi đã sử dụng Git tại hai công ty trước đây để kiểm soát phiên bản. Có vẻ như từ những gì tôi đã nghe nói rằng khoảng 90% các công ty sử dụng Git trên các hệ thống kiểm soát phiên bản khác.

Một trong những điểm bán hàng lớn nhất của Git là nó được phân cấp, tức là tất cả các kho lưu trữ đều như nhau; không có kho lưu trữ trung tâm / nguồn sự thật. Đây là một tính năng Linus Torvalds vô địch.

Nhưng dường như mọi công ty đều sử dụng Git theo cách tập trung, giống như người ta sẽ sử dụng SVN hoặc CVS. Luôn có một kho lưu trữ trung tâm trên một máy chủ (thường là trên GitHub) mà mọi người kéo từ và đẩy tới. Tôi chưa bao giờ thấy hoặc nghe nói (theo kinh nghiệm hạn chế được thừa nhận của tôi) mọi người sử dụng Git theo cách thực sự phi tập trung mà nó dự định, tức là đẩy và kéo đến các kho lưu trữ của đồng nghiệp khác khi họ thấy phù hợp.

Câu hỏi của tôi là:

1. Tại sao mọi người không sử dụng quy trình làm việc phân tán cho Git trong thực tế?
2. Là khả năng làm việc theo cách phân tán thậm chí quan trọng đối với kiểm soát phiên bản hiện đại, hay nó chỉ nghe có vẻ hay?

Biên tập

Tôi nhận ra tôi đã không vượt qua giai điệu chính xác trong câu hỏi ban đầu của mình. Có vẻ như tôi đã hỏi tại sao mọi người sẽ làm việc theo cách tập trung khi một hệ thống kiểm soát phiên bản phân tán (DVCS) rõ ràng là vượt trội. Trên thực tế, điều tôi muốn nói là, tôi không thấy bất kỳ lợi ích nào cho DVCS cả . Tuy nhiên, tôi thường nghe mọi người giảng về tính ưu việt của nó, trong khi thế giới thực dường như đồng ý với quan điểm của tôi.

Ahh, nhưng trên thực tế bạn đang sử dụng git một cách phi tập trung!

Hãy để chúng tôi so sánh người tiền nhiệm của git trong mindshare, svn. Subversion chỉ có một "repo", một nguồn sự thật. Khi bạn thực hiện một cam kết, đó là một repo trung tâm duy nhất, mà mọi nhà phát triển khác cũng cam kết.

Cách này hiệu quả, nhưng nó đã dẫn đến nhiều vấn đề, vấn đề lớn nhất là xung đột hợp nhất đáng sợ . Chúng hóa ra là bất cứ nơi nào từ khó chịu đến ác mộng để giải quyết. Và với một nguồn sự thật, họ có thói quen khó chịu là khiến công việc của mọi người dừng lại cho đến khi họ được giải quyết. Hợp nhất các xung đột chắc chắn tồn tại với git, nhưng chúng không phải là sự kiện dừng công việc và dễ dàng hơn và nhanh hơn để giải quyết; chúng thường chỉ ảnh hưởng đến các nhà phát triển liên quan đến những thay đổi xung đột hơn là tất cả mọi người.

Sau đó là toàn bộ điểm duy nhất của sự thất bại, và các vấn đề tiếp viên mang lại. Nếu repo svn trung tâm của bạn chết bằng cách nào đó, tất cả các bạn đều bị vặn cho đến khi nó có thể được khôi phục từ bản sao lưu và nếu không có bản sao lưu, tất cả các bạn đều bị vặn. Nhưng nếu git repo "trung tâm" chết, bạn có thể khôi phục từ bản sao lưu hoặc thậm chí từ một trong các bản sao khác của repo trên máy chủ CI, máy trạm của nhà phát triển, v.v. Bạn có thể làm điều này một cách chính xác vì chúng được phân phối, và mỗi nhà phát triển có một bản sao hạng nhất của repo.

Mặt khác, vì git repo của bạn là một repo hạng nhất theo đúng nghĩa của nó, khi bạn cam kết, các cam kết của bạn sẽ chuyển đến repo địa phương của bạn. Nếu bạn muốn chia sẻ chúng với những người khác, hoặc đến nguồn trung tâm của sự thật, bạn phải rõ ràng làm điều này với một cú đẩy từ xa. Các nhà phát triển khác sau đó có thể kéo xuống những thay đổi đó khi thuận tiện cho họ, thay vì phải kiểm tra svn liên tục để xem ai đó đã làm gì đó sẽ làm hỏng chúng.

Thực tế là, thay vì đẩy trực tiếp đến các nhà phát triển khác, bạn đẩy các thay đổi gián tiếp đến họ thông qua một repo từ xa khác, không quan trọng lắm. Phần quan trọng từ quan điểm của chúng tôi là bản sao repo địa phương của bạn là một repo theo đúng nghĩa của nó. Trong svn, nguồn sự thật trung tâm được thi hành theo thiết kế của hệ thống. Trong git, hệ thống thậm chí không có khái niệm này; nếu có một nguồn sự thật, nó được quyết định từ bên ngoài.

Khi máy chủ xây dựng của bạn (bạn đang sử dụng CI, phải không?) Tạo một bản dựng, nó lấy từ đâu? Chắc chắn, một bản dựng tích hợp mà bạn có thể lập luận không cần "một repo thật" mà chắc chắn là một bản dựng phân phối (tức là những gì bạn cung cấp cho khách hàng).

Nói cách khác: phân mảnh. Nếu bạn chỉ định một repo là "repo và chỉ định người giám hộ, những người không yêu cầu kéo, bạn có một cách dễ dàng để đáp ứng yêu cầu" cho tôi bản dựng phần mềm "hoặc" Tôi là người mới trong nhóm, mã ở đâu? "

Sức mạnh của DVCS không phải là khía cạnh ngang hàng của nó, mà thực tế là nó có thứ bậc . Tôi sửa đổi không gian làm việc của mình, sau đó tôi cam kết với địa phương. Khi tôi có một tính năng hoàn chỉnh, tôi hợp nhất các cam kết của mình và đẩy chúng vào điều khiển từ xa. Sau đó, bất cứ ai cũng có thể xem mã dự kiến ​​của tôi, cung cấp phản hồi, v.v. trước khi tôi tạo yêu cầu kéo và quản trị viên dự án hợp nhất nó vào repo One True.

Với CVCS truyền thống, bạn cam kết hoặc bạn không. Điều đó tốt cho một số quy trình công việc (tôi sử dụng cả hai loại VCS cho các dự án khác nhau), nhưng lại thất bại trong một dự án công khai hoặc OSS. Chìa khóa là DVCS có nhiều bước, công việc nhiều hơn, nhưng cung cấp cách tốt hơn để tích hợp mã từ người lạ thông qua quy trình tích hợp cho phép hiển thị tốt hơn những gì đang được kiểm tra. Sử dụng theo cách tập trung có nghĩa là bạn vẫn có thể có tiêu chuẩn vàng về tình trạng hiện tại của dự án đồng thời cung cấp cơ chế chia sẻ mã tốt hơn.

Tôi không biết làm thế nào bạn xác định "mọi người", nhưng đội của tôi có "một repo trung tâm trên một máy chủ" và cũng tùy từng thời điểm chúng tôi kéo từ Repos đồng nghiệp khác mà không đi qua đó repo trung ương. Khi chúng tôi làm điều này, chúng tôi vẫn đi qua một máy chủ, bởi vì chúng tôi chọn không gửi email các bản vá về địa điểm, nhưng không thông qua repo trung tâm. Điều này thường xảy ra khi một nhóm đang cộng tác trên một tính năng cụ thể và muốn cập nhật với nhau, nhưng vẫn chưa quan tâm đến việc xuất bản tính năng này cho mọi người. Đương nhiên vì chúng tôi không phải là những người làm việc bí mật, những tình huống đó không kéo dài, nhưng DVCS cung cấp sự linh hoạt để làm bất cứ điều gì thuận tiện nhất. Chúng tôi có thể xuất bản một nhánh tính năng hoặc không theo sở thích.

Nhưng 90% + thời gian, chắc chắn, chúng tôi đi qua repo trung tâm. Khi tôi không quan tâm đến bất kỳ thay đổi cụ thể hoặc công việc cụ thể nào của đồng nghiệp, nó sẽ thuận tiện hơn và có quy mô tốt hơn, để kéo "tất cả các thay đổi của đồng nghiệp của tôi đã được hiệu chỉnh trong repo trung tâm", thay vì kéo riêng các thay đổi từ mỗi N đồng nghiệp. DVCS không cố gắng ngăn "pull from main repo" là quy trình công việc phổ biến nhất, nó cố gắng ngăn chặn nó là quy trình công việc duy nhất có sẵn.

"Phân phối" có nghĩa là tất cả các repos đều tương đương về mặt kỹ thuật đối với gitphần mềm, nhưng nó không tuân theo việc tất cả chúng đều có tầm quan trọng như nhau đối với các nhà phát triển và quy trình công việc của chúng tôi. Khi chúng tôi phát hành cho khách hàng hoặc máy chủ sản xuất, repo chúng tôi sử dụng để làm điều đó có một ý nghĩa khác với repo chỉ được sử dụng bởi một nhà phát triển trên máy tính xách tay của họ.

Nếu "thực sự phi tập trung" có nghĩa là "không có hợp đồng mua lại đặc biệt", sau đó tôi không nghĩ rằng đó là những gì Linus có nghĩa là vô địch, cho rằng trong quan điểm thực tế, ông không duy trì các hợp đồng mua đặc biệt mà là quan trọng hơn trong các chương trình lớn của sự vật, hơn là một số bản sao ngẫu nhiên của Linux mà tôi đã tạo ngày hôm qua và dự định chỉ sử dụng để phát triển một số bản vá nhỏ và sau đó xóa nó sau khi anh ấy chấp nhận bản vá. gitkhông đặc quyền repo của ông trên tôi, nhưng Linus không đặc quyền đó. "Là trạng thái hiện tại của Linux", của tôi thì không. Vì vậy, tự nhiên thay đổi xu hướngđể đi qua Linus. Sức mạnh của DVCS so với VCS tập trung không phải là không có trung tâm thực tế, đó là những thay đổi không phải đi qua bất kỳ trung tâm nào vì (xung đột cho phép) bất kỳ ai cũng có thể hợp nhất bất cứ điều gì.

Các hệ thống DVCS cũng bị ép buộc , vì chúng được phân cấp, để cung cấp các tính năng tiện lợi nhất định dựa trên thực tế là bạn nhất thiết phải có một lịch sử hoàn chỉnh (ví dụ như một repo) để làm bất cứ điều gì. Nhưng nếu bạn nghĩ về nó thì không có lý do cơ bản nào khiến bạn không thể định cấu hình một VCS tập trung với bộ đệm cục bộ giữ toàn bộ lịch sử cho các hoạt động chỉ đọc được phép hết hạn (tôi nghĩ Perforce có tùy chọn cho chế độ này, nhưng tôi chưa bao giờ sử dụng Perforce). Hoặc về nguyên tắc bạn có thể cấu hình gitvới.git/thư mục trên hệ thống tệp được gắn từ xa để mô phỏng "tính năng" của SVN mà nó không hoạt động khi bạn không có kết nối mạng. Trên thực tế, DVCS buộc hệ thống ống nước phải mạnh mẽ hơn mức bạn có thể thoát khỏi trong một VCS tập trung. Đây là một tác dụng phụ (rất đáng hoan nghênh) và giúp thúc đẩy thiết kế DVCS, nhưng sự phân phối trách nhiệm này ở cấp độ kỹ thuật không giống như phân cấp hoàn toàn mọi trách nhiệm của con người .

Điều thú vị về bản chất của DVCS là nếu người khác sử dụng nó theo cách phân tán, bạn có thể sẽ không biết điều đó trừ khi họ tương tác trực tiếp với bạn. Điều duy nhất bạn có thể nói dứt khoát là bạn và đồng đội trực tiếp của bạn không sử dụng git theo cách này. Điều này không đòi hỏi một chính sách toàn công ty. Vì vậy, tôi sẽ hỏi bạn, tại sao không bạn sử dụng git một cách phi tập trung?

Để giải quyết chỉnh sửa của bạn, có lẽ bạn cần một số kinh nghiệm làm việc với kiểm soát phiên bản tập trung thực tế để đánh giá cao sự khác biệt, bởi vì mặc dù chúng có vẻ tinh tế, nhưng chúng có sức lan tỏa. Đây là tất cả những điều mà nhóm của tôi thực sự làm trong công việc mà chúng tôi không thể làm khi chúng tôi tập trung vào VCS:

• Có một danh sách rất nhỏ các nhà phát triển cốt lõi có quyền truy cập vào repo "trung tâm" cho mỗi microservice. Mọi người khác có thể làm việc ngoài dĩa và gửi qua yêu cầu kéo.
• Có thể cam kết nhiều thường xuyên hơn, thường là vài lần mỗi giờ so với một hoặc hai lần mỗi ngày.
• Có thể tạo các nhánh vì bất kỳ lý do nào để phối hợp tạm thời với đồng nghiệp, và đẩy nó và kéo từ đó vài lần mỗi ngày, sau đó ép nó khi sẵn sàng chia sẻ với một nhóm lớn hơn. Bạn có biết khó khăn thế nào khi xin phép tạo một nhánh tạm thời cho một cái gì đó như thế này trong CVCS truyền thống không?

Có nguy cơ nghe có vẻ cũ khi nói điều đó, bạn thực sự không biết bạn có nó dễ dàng như thế nào.

Tôi nghĩ rằng câu hỏi của bạn xuất phát từ một tư duy (có thể hiểu được) luôn luôn được kết nối . tức là máy chủ ci Các trung tâm 'thật' là luôn (hoặc gần luôn luôn) có sẵn. Trong khi điều này đúng trong hầu hết các môi trường, tôi đã làm việc ở ít nhất một môi trường khác xa với điều này.

Một dự án mô phỏng quân sự mà nhóm của tôi đã làm việc cách đây vài năm. Tất cả các mã (Chúng tôi đang nói về một cơ sở mã hóa 1 đô la Mỹ) phải (theo luật / thỏa thuận quốc tế, đàn ông mặc đồ tối đến nếu bạn không) ở trên các máy cách ly với mọi kết nối Internet . Điều này có nghĩa là tình huống thông thường của mỗi chúng tôi có 2 PC, một cho việc viết / chạy / kiểm tra mã, cái còn lại cho Google, kiểm tra E-mail và như vậy. Và có một mạng cục bộ trong nhóm các máy này, rõ ràng là không có bất kỳ cách nào kết nối với Internet.

"Nguồn trung tâm của sự thật" là một cỗ máy trên một căn cứ quân sự, trong một căn phòng không cửa sổ dưới lòng đất toàn bộ (tòa nhà được gia cố, yada-yada). Máy đó cũng không có kết nối Internet.

Theo định kỳ, công việc của ai đó là vận chuyển (vật lý) một ổ đĩa với git repo (chứa tất cả các thay đổi mã của chúng tôi) đến căn cứ quân sự - cách đó vài trăm km, vì vậy, bạn có thể tưởng tượng.

Hơn nữa, trong các hệ thống rất lớn, nơi bạn có rất nhiều đội. Nhìn chung, mỗi người sẽ có repo "trung tâm" của riêng mình, sau đó quay trở lại repo trung tâm (cấp thần) thực tế. Tôi biết ít nhất 1 nhà thầu khác đã thực hiện cùng một git repo ổ cứng với mã của họ.

Ngoài ra, nếu bạn xem xét một cái gì đó trên quy mô của nhân Linux ... Các nhà phát triển không chỉ gửi yêu cầu kéo cho chính Linus. Về cơ bản, đó là một hệ thống phân cấp của repo - mỗi nhóm trong số đó là "trung tâm" đối với ai đó / một số nhóm.

Bản chất bị ngắt kết nối của git có nghĩa là nó có thể được sử dụng trong các môi trường nơi các công cụ kiểm soát nguồn mô hình được kết nối ( ví dụ SVN, đối với một) không thể được sử dụng - hoặc không thể sử dụng dễ dàng.

Cuối cùng, bạn đang xây dựng một sản phẩm. Sản phẩm này đại diện cho mã của bạn tại một thời điểm duy nhất. Cho rằng, mã của bạn phải kết hợp ở đâu đó . Điểm tự nhiên là một máy chủ ci hoặc máy chủ trung tâm mà từ đó sản phẩm được xây dựng và có ý nghĩa rằng điểm trung tâm này là một kho lưu trữ git.

Khía cạnh phân tán của một DVCS luôn xuất hiện trong phát triển nguồn mở, dưới hình thức giả mạo. Ví dụ, một số dự án tôi đóng góp đã bị tác giả ban đầu bỏ rơi và bây giờ có một loạt các nhánh mà các nhà bảo trì đôi khi kéo các tính năng cụ thể từ nhau. Ngay cả nói chung, các dự án OSS có đóng góp bên ngoài thông qua yêu cầu kéo, thay vì cấp cho những người ngẫu nhiên đẩy quyền truy cập vào repo thật.

Đây không phải là trường hợp sử dụng rất phổ biến khi xây dựng một sản phẩm cụ thể với một bản phát hành chính thức cụ thể, nhưng trong thế giới F / OSS, đó là tiêu chuẩn, không phải là ngoại lệ.

Tại sao mọi người sử dụng git một cách tập trung?

Chúng tôi chưa bao giờ gặp nhau, làm thế nào mà bạn nói tất cả mọi người? ;)

Thứ hai, có nhiều tính năng khác mà bạn tìm thấy trong Git nhưng không có trong CVS hoặc SVN. Có lẽ chỉ là bạn cho rằng đây phải là tính năng duy nhất cho mọi người .

Chắc chắn nhiều người có thể sử dụng nó tập trung như CVS hoặc SVN. Nhưng đừng quên tính năng khác vốn có đi kèm với một VCS được phân bổ: tất cả các bản sao đều ít nhiều "hoàn thành" (tất cả các chi nhánh và toàn bộ lịch sử đều có sẵn) và tất cả các chi nhánh có thể được kiểm tra mà không cần kết nối với máy chủ.

Tôi cho rằng đây là một tính năng không nên quên.

Mặc dù bạn không thể thực hiện việc này với CVS và SVN, nhưng Git có thể được sử dụng tập trung như trước đây mà không gặp vấn đề gì.

Vì vậy, tôi có thể cam kết các thay đổi của mình, có thể cùng nhau thực hiện các cam kết đang thực hiện, sau đó tìm nạp và khởi động lại công việc của tôi vào nhánh phát triển chính.

Các tính năng khác đi kèm với Git:

• ký mã hóa cam kết
• rebasing (sắp xếp lại và xác nhận squash; chỉnh sửa cam kết, không chỉ tin nhắn)
• hái anh đào
• chia đôi lịch sử
• chi nhánh địa phương và thay đổi stashing (được gọi là "kệ" trong Wikipedia)

Cũng xem ba bảng này trong Wikipedia - So sánh phần mềm kiểm soát phiên bản :

• Đặc trưng

• Các lệnh cơ bản

• Lệnh nâng cao

Vì vậy, một lần nữa, có thể cách thức phi tập trung không phải là tính năng duy nhất khiến mọi người sử dụng nó.

1. Tại sao mọi người không sử dụng quy trình làm việc phân tán cho Git trong thực tế?

Bất cứ ai đóng góp hoặc lưu trữ một dự án lớn hơn trên Bitbucked, GitHub, v.v ... sẽ thực sự làm điều đó. Các nhà bảo trì giữ kho lưu trữ "chính", một bản sao đóng góp, cam kết và sau đó gửi yêu cầu kéo.

Trong các công ty, ngay cả với các dự án hoặc nhóm nhỏ, quy trình làm việc phân tán là một tùy chọn khi họ thuê ngoài các mô-đun và không muốn các bên ngoài sửa đổi (các) nhánh phát triển thiêng liêng mà không cần xem xét các thay đổi của họ trước đó.

2. Là khả năng hoạt động theo cách phân tán thậm chí quan trọng đối với kiểm soát phiên bản hiện đại, ...

Như mọi khi: nó phụ thuộc vào yêu cầu.

Sử dụng một VCS phi tập trung nếu bất kỳ điểm nào áp dụng:

• muốn cam kết hoặc điều hướng lịch sử ngoại tuyến (nghĩa là hoàn thành mô hình con trong cabin trên núi trong kỳ nghỉ)
• cung cấp repos trung tâm nhưng muốn tách rời kho lưu trữ "thật" để xem xét các thay đổi (nghĩa là đối với các dự án lớn hoặc nhóm phân phối)
• thỉnh thoảng muốn cung cấp (một bản sao) toàn bộ lịch sử và các chi nhánh trong khi ngăn truy cập trực tiếp vào repo trung tâm (tương tự như thứ hai)
• muốn phiên bản một cái gì đó mà không phải lưu trữ từ xa hoặc thiết lập một kho lưu trữ chuyên dụng (đặc biệt là với Git, chỉ git init .cần đủ để sẵn sàng để phiên bản một cái gì đó)

Có một số nhiều nhưng bốn nên là đủ.

... Hay nó nghe có vẻ hay?

Tất nhiên nó có vẻ tốt - cho người mới bắt đầu.

Linh hoạt là một lời nguyền cũng như một phước lành. Và như Git là vô cùng linh hoạt, nó hầu như luôn luôn xa quá linh hoạt cho các tình huống điển hình. Cụ thể, hầu hết các dự án Git không phải là Linux.

Kết quả là, lựa chọn thông minh là loại bỏ một số tính linh hoạt lý thuyết đó khi thực hiện Git. Trong kho lý thuyết có thể tạo thành bất kỳ biểu đồ nào, trong thực tế, sự lựa chọn thông thường là một cái cây. Chúng ta có thể thấy những lợi ích rõ ràng khi sử dụng lý thuyết đồ thị: trong một cây các kho lưu trữ, bất kỳ hai kho lưu trữ nào cũng chia sẻ chính xác một tổ tiên. Trong một biểu đồ ngẫu nhiên, ý tưởng về tổ tiên thậm chí không tồn tại!

Tuy nhiên, ứng dụng khách git của bạn gần như chắc chắn mặc định theo mô hình "tổ tiên duy nhất". Và các biểu đồ trong đó các nút có một tổ tiên duy nhất (ngoại trừ một nút gốc) chính xác là các cây. Vì vậy, máy khách git của bạn mặc định cho mô hình cây, và do đó các kho lưu trữ tập trung.

Logic kinh doanh thưởng cho một máy chủ tập trung. Đối với gần như tất cả các kịch bản kinh doanh thực tế, một máy chủ tập trung là một tính năng cơ bản của quy trình làm việc.

Chỉ vì bạn có khả năng làm DVCS không có nghĩa là luồng công việc chính của bạn phải là DVCS. Khi tôi sử dụng git tại nơi làm việc, chúng tôi sử dụng nó theo cách tập trung, ngoại trừ những trường hợp kỳ lạ kỳ lạ trong đó bit phân tán là điều cần thiết để giữ mọi thứ di chuyển theo.

Mặt phân phối của mọi thứ là phức tạp. Thông thường bạn muốn giữ cho mọi thứ trơn tru và dễ dàng. Tuy nhiên, bằng cách sử dụng git, bạn đảm bảo rằng bạn có quyền truy cập vào phía phân phối để xử lý các tình huống sởn gai ốc có thể phát sinh trên đường.

Để đồng nghiệp lấy từ một git repo trên máy của tôi nghĩa là tôi cần phải có một git daemon chạy ở cấp gốc làm tác vụ nền. Tôi rất tinh ranh với daemon chạy trên máy tính của riêng tôi, hoặc trên máy tính xách tay do công ty cung cấp. Giải pháp đơn giản nhất là "KHÔNG"! Đối với đồng nghiệp để lấy từ một git repo trên máy của tôi cũng có nghĩa là địa chỉ internet của tôi cần phải được sửa. Tôi đi du lịch, tôi làm việc ở nhà, và thỉnh thoảng tôi làm việc từ văn phòng của tôi.

Mặt khác, VPN vào trang web của công ty và đẩy một chi nhánh đến repo trung tâm chỉ mất chưa đầy một phút. Tôi thậm chí không cần VPN trong nếu tôi đang ở trong văn phòng. Đồng nghiệp của tôi có thể dễ dàng kéo từ chi nhánh đó.

Mặt khác, git repo địa phương của tôi là một kho lưu trữ đầy đủ tính năng. Tôi có thể thực hiện công việc mới, tạo một chi nhánh mới cho công việc thử nghiệm và hoàn nguyên công việc khi tôi tạo ra một mớ hỗn độn, ngay cả khi tôi đang làm việc trong một chiếc máy bay bay ở độ cao 30.000 feet giữa không trung. Hãy thử làm điều đó với một hệ thống kiểm soát phiên bản tập trung.

Phức tạp:

Với một kho lưu trữ trung tâm, một luồng công việc điển hình có thể là

branch off from the central master branch
change the code
test
possibly go back to changing the code
commit
merge any new changes from the central master branch
test
possibly go back to changing the code
merge changes into the central master branch and push

Sự phức tạp liên quan đến số lượng nhà phát triển trong O (1).

Nếu thay vào đó, mỗi nhà phát triển có nhánh chính của riêng mình thì nó trở thành, cho nhà phát triển 0:

branch off from master branch 0
merge from master branch 1
...
merge from master branch N-1
change the code
test
possibly go back to changing the code
commit
merge any changes from master branch 0
merge any changes from master branch 1
...
merge any changes from master branch N-1
test
possibly go back to changing the code
merge changes into master branch 0

Cách tiếp cận ngang hàng là O (N).

Tính nhất quán:

Bây giờ hãy xem xét nếu có xung đột hợp nhất giữa nhánh chính của Alice và nhánh chính của Bob. Mỗi nhà phát triển N có thể giải quyết xung đột khác nhau. Kết quả: hỗn loạn. Có nhiều cách để đạt được sự thống nhất cuối cùng, nhưng cho đến khi điều đó xảy ra, tất cả các loại thời gian của nhà phát triển có thể bị lãng phí.

Đơn giản:

Các công ty là các tổ chức tập trung, với quy trình làm việc tập trung.

Mỗi lập trình viên đều có một ông chủ và ông ta có ông chủ của mình, v.v ... cho đến CTO. CTO là nguồn cuối cùng của sự thật kỹ thuật. Bất cứ công ty công cụ nào sử dụng, nó phải phản ánh chuỗi lệnh này. Một công ty giống như một đội quân - bạn không thể để tư nhân vượt qua một vị tướng.

GIT cung cấp các tính năng hữu ích cho các công ty (ví dụ: yêu cầu kéo để xem lại mã) và chính điều đó khiến họ chuyển sang GIT. Phần phi tập trung chỉ đơn giản là một tính năng mà họ không cần - vì vậy họ bỏ qua nó.

Để trả lời câu hỏi của bạn: Phần phân tán thực sự vượt trội trong môi trường phân tán, ví dụ như nguồn mở. Kết quả khác nhau tùy thuộc vào người đang nói chuyện. Linus Torvalds không chính xác là chuột con của bạn, đó là lý do tại sao các tính năng khác nhau của GIT quan trọng với anh ta hơn là với công ty trung tâm của bạn.

Có thể đó là do anh ta xử lý bảng lương là tập trung, vì vậy chúng tôi phải giữ cho một người trung tâm hạnh phúc nếu chúng tôi muốn được trả tiền.

Có thể đó là vì chúng tôi đang tạo ra một sản phẩm, vì vậy chúng tôi cần một bản sao chính của phần mềm cho khách hàng.

Có lẽ đó là vì lập trình viên đến một nơi dễ dàng hơn rất nhiều để có được những thay đổi của mọi người, thay vì phải kết nối với nhiều máy khác nhau.

Có thể đó là do cơ sở dữ liệu lỗi được tập trung và phải được giữ đồng bộ với mã .

Được tập trung là tuyệt vời, cho đến khi có một vấn đề về ..

Git là một hệ thống phân tán cho phép tạo ra một trung tâm mới với chi phí thấp từ bất kỳ kho lưu trữ cập nhật nào (chỉ cần hiển thị kho lưu trữ ra mạng). Git cũng cho phép cập nhật bản sao lưu lỗi thời từ kho lưu trữ trên các máy của nhà phát triển, do đó giúp khôi phục trung tâm dễ dàng hơn.

Có thể hợp nhất vv trên một bản sao cục bộ của một kho lưu trữ khi mạng ngừng hoạt động là rất tốt, nhưng không cần một hệ thống phân tán; nó chỉ cần một hệ thống giữ một bản sao cục bộ của tất cả dữ liệu. Tương tự như vậy với việc kiểm tra mã với bay, vv

Vào cuối ngày, có rất ít chi phí cho việc phân phối và một số lợi ích. Hầu hết chi phí phân phối là trong khu vực cần thiết nếu bạn muốn theo dõi chi nhánh tuyệt vời, v.v. Nếu bạn thiết kế một hệ thống để sử dụng ở hầu hết các công ty, bạn sẽ không thiết kế để phân phối, vì kiểm soát tập trung mã nguồn rõ ràng là trường hợp sử dụng chính của trường học.