2009-03-24 17 views
6

Hãy tưởng tượng bạn có một người bạn trên điện thoại (không phải VoIP), người hỏi: "Có gì đặc biệt về Git? Tôi ổn khi sử dụng Subversion." Điều gì sẽ là "sân thang máy" của bạn để mô tả lợi thế của việc sử dụng DVCS như Git?Sân thang máy cho Git a/o DVCS

+0

Tôi thường đặt thang máy cho 90 hải lý/giờ, sau đó điều khiển chiếc kính lúp của tôi bằng van tiết lưu. Qua ngưỡng, mở rộng các cánh nếu bạn chắc chắn rằng bạn không có bất kỳ băng, sau đó ga trở lại và vòng ra về một chân ra khỏi mặt đất ... Xin lỗi, sai trang web. –

+0

Điện thoại của tôi hiếm khi hoạt động trong thang máy. – Damo

Trả lời

2

Đối với tôi, một trong những điều chính bạn có thể làm trong một DVCS như git điều đó không làm việc tốt trong SVN là như sau:

1) Tạo một số chi nhánh phát triển ra khỏi thân cây cho các tính năng khác nhau mà là đang trong quá trình phát triển.

2) Hợp nhất mã từ một chi nhánh đối tượng vào một chi nhánh tính năng khác trước khi một trong hai chi nhánh tính năng kết thúc và sẵn sàng để được hợp nhất vào thân cây.

3) Sau đó, hợp nhất các chi tiết đối tượng vào thân cây.

Thật tuyệt khi chia nhỏ các tính năng mới thành các nhánh riêng biệt để thân cây luôn sạch sẽ cho đến khi các tính năng kết thúc. Tuy nhiên, chắc chắn bạn gặp phải tình huống mà một đội làm việc trên một nhánh tính năng đã viết một số mã cần thiết bởi một nhóm trên một nhánh tính năng khác. Nếu bạn hợp nhất mã này qua các nhánh tính năng với SVN, bạn sẽ gặp sự cố khi hợp nhất vào thân sau này. Git tránh được vấn đề này.

Đây là một lợi ích khác ... Công ty của bạn quyết định thuê ngoài phát triển tính năng cho công ty ký hợp đồng của Ấn Độ.Hoặc, nhóm Dịch vụ chuyên nghiệp của bạn cần phải thêm đối tượng địa lý cho khách hàng và tính năng đó có thể được sản xuất trong tương lai. Bạn thực sự không muốn cấp quyền truy cập viết cho SVN của bạn cho nhà thầu Ấn Độ hoặc nhóm PS của bạn. Vì vậy, họ phải xây dựng mã bên ngoài kiểm soát nguồn và bạn phải hợp nhất nó vào chính mình, phát hiện và giải quyết bất kỳ xung đột nào mà không có sự trợ giúp từ SVN và mất tất cả lịch sử đăng ký của nhà thầu trong quá trình này.

Nhưng với git, bạn chỉ cần cung cấp cho nhà thầu hoặc nhóm PS của bạn một bản sao của kho lưu trữ và họ có thể cam kết với nó giống như một nhà phát triển. Sau đó, bạn có thể sử dụng các tính năng của git để hợp nhất các thay đổi trở lại kho lưu trữ git của bạn. Git sẽ tìm thấy những xung đột, và nó sẽ bảo tồn lịch sử.

Cuối cùng, một trong những điều thú vị nhất về git là bạn thực sự không phải thuyết phục bạn mình rằng nó tốt hơn SVN. Vì git tích hợp rất tốt với SVN, công ty/bạn của bạn có thể vui vẻ sử dụng SVN trong khi bạn vui vẻ sử dụng git được kết nối với SVN.

0

Hai từ: Hợp nhất, phân nhánh.

Việc hợp nhất và phân nhánh dễ dàng hơn trong Git so với bất kỳ nơi nào khác. Git cần thiết để giải quyết một vấn đề: Hợp nhất mã được viết bởi hàng ngàn nhà phát triển, những người hiếm khi cùng sửa đổi. Bây giờ thử điều này trong SVN:

  1. Commit bản sao làm việc của bạn (không có vi phạm xây dựng cho bất cứ ai khác)
  2. Fetch phiên bản mới nhất (mà không làm hư hỏng bản sao làm việc của bạn)
  3. Merge mã với một phiên bản đích tùy ý trong khi có thể quay trở lại bản sao làm việc hoặc phiên bản đích của bạn mà không có nguy cơ mất bất kỳ một trong ba (bản sao làm việc, phiên bản đích, hợp nhất giữa hai bản).

Có thể thực hiện với SVN nhưng trong Git, đây là chế độ hoạt động mặc định và do đó, đơn giản nhất.

+0

Tôi nghĩ rằng tuyên bố "trong Git, đây là mặc định" là không rõ ràng. "Cái này" trong câu nói đó là gì? –

+0

Bạn có chắc chắn về "M & B dễ dàng hơn trong SVN so với Git" không? –

+0

Ngớ ngẩn tôi. Đã sửa. –

1

Yêu cầu anh ta làm việc/kiểm tra/cam kết/kiểm tra nhật ký/hoàn nguyên mà không cần truy cập vào kho lưu trữ mạng của mình (ví dụ: trên máy bay).

+0

Điều này được trích dẫn mỗi lần mọi người nói về bản sửa đổi phân phối nhưng thành thật mà nói, có bao nhiêu nhà phát triển * làm việc trên máy bay? – JasonSmith

+0

Tôi làm việc trên tàu gần như mỗi ngày. – Dustin

+0

Tôi biết một người làm việc trong một ngôi làng ở châu Phi và đóng góp cho nhân Linux và rất nhiều dự án mã nguồn mở khác. Truy cập Internet duy nhất của anh ta là một quán cà phê Internet trong một thị trấn cách đó 3 giờ, và quán cà phê đó chỉ mở một giờ một tuần. Truy cập Internet phổ biến là một huyền thoại. –

2

Đã có a question similar to this. Ngoài ra, Eric Sink có một số number trong số articles về DVCS. Cả hai câu trả lời cho câu hỏi khác và các bài viết có thể giúp xây dựng một quyết định sáng suốt. Đơn giản chỉ cần nói rằng cái kia tốt hơn cái kia có lẽ sẽ không giúp được gì (Đáng buồn thay, đó dường như là tất cả những gì mà Linus làm trong khía cạnh đó, điều này thực sự không giúp thuyết phục mọi người - ít nhất là không phải tôi :)).

1

Đó là sự cố của blub.

Mọi thứ bạn có thể làm trong hệ thống tập trung, tôi có thể làm trong hệ thống phân tán của mình, nhưng nhiệm vụ DVCS hàng ngày của tôi khiến tôi trở thành nhà phát triển hiệu quả không thể thực hiện được trong hệ thống tập trung của bạn bạn không thể hiểu rằng bởi vì bạn cảm nhận thế giới với những giới hạn mà hệ thống của bạn đã đặt lên bạn.

0

Đối với nhà phát triển, sự khác biệt quan trọng nhất giữa DVCS và SVN là tốc độ.

Khi lệnh mất 30 giây hoặc 4 phút trong SVN thay vì mất 1 hoặc 2 giây trong Git hoặc Mercurial hoặc Bazaar, đó là sự khác biệt lớn đối với nhà phát triển. Kiểm soát phiên bản trở thành một nhiệm vụ nhỏ hơn là một gián đoạn đối với quy trình làm việc của bạn. Bạn không cần phải thêm caffeine & gọi lại nghi lễ pavlovian của bạn để làm việc; bạn giữ tập trung của bạn bằng cách không mất nó.

Các lợi ích khác là quan trọng, nhưng họ là thứ yếu bằng cách so sánh:

  • đơn giản, nhánh linh hoạt hơn và sáp nhập, với ít hơn, đơn giản hơn merge mâu thuẫn
  • tự do brom bị giới hạn bởi truy cập mạng và thời gian hoạt động máy chủ
  • cấu trúc repo khớp với quy trình làm việc của bạn
Các vấn đề liên quan