Tại sao Git nhận được rất nhiều sự cường điệu? Sọ trong khi những người khác không? [đóng cửa]

Trong những năm gần đây, sự cường điệu xung quanh Git đã tăng lên rất nhiều. Mọi người đều biết về Git, không ai biết về các lựa chọn thay thế.

Những người khác như Mercurial dường như không được chú ý. Cả hai đã được phát hành vào năm 2005, và cung cấp các chức năng tương tự. Hơn nữa, Mercurial thường được coi là dễ sử dụng hơn, trực quan hơn và có giao diện người dùng tốt hơn trong một thời gian dài. Do đó, có thể giả định rằng đây sẽ là một giải pháp thay thế phổ biến, đặc biệt đối với những người mới kiểm soát phiên bản phân tán. Tuy nhiên, dường như hầu hết mọi người đều không biết, không giống như Git đã thành công khá tốt.

Quan điểm của bài này là cố gắng hiểu hiện tượng này tốt hơn.

Làm thế nào mà Git có được tất cả các phần của bánh? Có phải họ bằng cách nào đó sử dụng tiếp thị tốt hơn? Có phải vì cộng đồng của nó nhiều ... ôi ... "dài dòng"? Có phải vì tên "Linus"? Có phải vì hình ảnh táo bạo của nó?

Ý kiến ​​của bạn là gì?

Tôi tin rằng các dịch vụ như GitHub hoặc Gitorious là một yếu tố lớn. Điều quan trọng đối với mọi người là họ có thể lưu trữ nội dung của mình ở đâu đó và đặc biệt là GitHub là một dịch vụ tuyệt vời cho việc đó.

Đối với đồng bóng, không có dịch vụ nào như vậy khi DVCS trở nên phổ biến (ít nhất là tôi không biết). Bạn có Bitbucket bây giờ và có thể là những người khác, nhưng GitHub đã ở đó khá lâu, nó nổi tiếng và nó ngày càng tốt hơn.

Tôi thấy rất nhiều câu trả lời cho điều này dựa trên cảm xúc của tác giả khi nghe về một hoặc SCM khác. Những người khác nói rằng tất cả là may mắn. Tôi tin rằng may mắn có thể được truy trở lại trong lịch sử.

Tôi sẽ nói về lịch sử.

Git và Mercurial đã được tạo ra đồng thời để giải quyết vấn đề tương tự. Quay trở lại những ngày đó, nhân Linux đã buộc phải ngừng sử dụng BitKeeper , một SCM phân phối độc quyền mà nó đã sử dụng trong 3 năm. Lý do cho điều này là vì Larry McVoy, CEO của BitMover, công ty đứng sau BitKeeper, đã ngừng cung cấp phần mềm của mình miễn phí cho các nhà phát triển Linux, bởi vì ai đó trong cộng đồng Linux đã thiết kế ngược lại.

Linus Torvalds, không hài lòng với những gì đã tồn tại, sau đó bắt đầu làm việc trên một SCM hoàn toàn mới mà anh sẽ sớm gọi cho Git. Ngay sau đó, Matt Mackall bắt đầu dự án Mercurial vì những lý do tương tự.

Sau một thời gian phát triển các dự án này một cách riêng biệt, Matt Mackall đã trình bày một phiên bản nâng cao của SCM của mình và đánh giá nó theo một cách nhất định, so sánh nó với Git (bản thân nó chỉ mới vài tuần tuổi). Linus đã cân nhắc sử dụng nó thay vì phát triển Git cho Kernel, nhưng đã bỏ ý tưởng khi anh nhận ra rằng Mercurial đang sử dụng Changeets để ghi lại các sửa đổi sửa đổi . Anh ta sợ điều đó quá gần với cách thức hoạt động của BitKeeper và anh ta chắc chắn không muốn bất cứ điều gì có thể khiến ai đó nói, "Họ đã tạo ra một bản sao BitKeeper".

Do đó, Git được sử dụng để phát triển Kernel thay vì Mercurial, nhưng cả hai đều liên quan đến kỹ thuật. Kết quả cuối cùng là, Git bắt đầu bằng cách thực sự được sử dụng ở nơi nó được thiết kế để sử dụng, trong khi Mercurial không nhanh chóng tìm thấy việc sử dụng FOSS lớn đầu tiên của mình. Bởi vì nó được ban cho một thiết kế rất tốt, và nhờ sự kiên trì của Matt Mackall, cuối cùng nó đã trở nên nổi tiếng và được sử dụng cho các dự án lớn, trong thế giới thực.

Ngày nay, cả hai đều nổi tiếng. Cái nào nổi tiếng nhất là không thể nói. Google Code chỉ tích hợp Git gần đây, trong khi nó có Mercurial trong một thời gian dài. Nhiều dự án thực sự lớn và nổi tiếng sử dụng một trong hai.

Tôi đoán những gì tôi muốn nói là, khi chính lý do tại sao bạn bắt đầu một dự án biến mất, khó có được sự nổi tiếng hơn, nhưng vẫn khả thi.

Bazaar là một SCM khác rất nổi tiếng trong thế giới GNU, nhưng không quá nhiều vì nó được xây dựng với mục đích thỏa mãn cộng đồng GNU. Phần mềm thường đi đến nơi mà người sáng tạo của họ muốn đến, và không còn nữa.

Mặt khác, các SCM phân tán là những người chiến thắng rõ ràng. Tôi không thấy nhiều SCM không được phân phối rộng rãi ngoài kia.

Linus Torvalds

Linus là một người ủng hộ lớn của Git và đã quảng bá nó mạnh mẽ cho nhóm linux lõi trong nhiều năm và nó đã phát triển từ đó. Tôi dám khẳng định đó hoàn toàn là do ảnh hưởng của Linus đối với cộng đồng * nix.

Cá nhân tôi vẫn sử dụng Subversion, nhưng đó là từ sở thích hơn là tiện ích.

Điểm đau thông thường với hệ thống kiểm soát phiên bản là hợp nhất chi nhánh .

Bạn cần phải thử nó khi nó không hoạt động để hiểu nó có thể đau như thế nào và nó quan trọng như thế nào khi làm việc, để được làm việc tự do với các chi nhánh.

Biết rằng Linus Torvalds đã viết git để làm điều này đúng, và được cho là trong một tình huống, anh ta đã sử dụng git để hợp nhất mười hai nhánh với nhau, đây là một lập luận rất thuyết phục để git trở nên thú vị.

Tôi đã ở trong tình huống khoảng một năm trước, nơi tôi phải lựa chọn giữa hg và git, và sự hợp nhất ở trên là một yếu tố quan trọng trong việc chọn git. Thứ hai là tổ chức Eclipse đã chuyển sang git, do đó, công cụ Eclipse được dự kiến ​​sẽ tốt cho các dự án Java. Với việc phát hành Eclipse 3.7, điều này đã xảy ra. Chúng tôi có lẽ đã sớm 6-9 tháng về việc này.

Đối với các nhu cầu khác nhau, hg có thể hữu ích như vậy. Sun đã chọn nó cho VCS của họ dựa trên một cuộc điều tra rất cẩn thận. Bạn có thể muốn tìm những tờ giấy trắng và xem lý do của họ là gì.

EDIT: Lưu ý, tôi không nói rằng có bất cứ điều gì Mercurial không thể làm, chỉ là đối với Java với Eclipse - vốn là trọng tâm chính của chúng tôi - các lực lượng thị trường hiện đang mạnh nhất đối với git, ngay cả dưới Windows và chúng tôi cần phải đứng trên vai của người khác, không phải bàn chân của họ.

Thay vì nói tại sao git hoặc đồng bóng tốt hơn và nói lý do duy nhất phổ biến của nó, tôi sẽ tập trung vào cộng đồng.

Như tôi đã nhấn mạnh trước đó , cộng đồng Git rất ồn ào và kiêu ngạo. Hầu hết sẽ bảo vệ mạnh mẽ chương trình quý giá của họ. Hầu hết các cuộc chiến Git vs Mercurial mà tôi từng thấy được bắt đầu bởi những người git, những người đang tự hỏi tại sao mọi người trên Trái đất không sử dụng git thần thánh. Các trang web như whygitisbetterthanx.com thậm chí còn thể hiện sự kiêu ngạo này trong phần giới thiệu, được viết để châm lửa cho người khác.

Tôi không nói mọi người đều theo cách này, nhưng hầu hết thời gian tôi gặp phải người git, trang web ủng hộ và blog ủng hộ tôi cảm thấy như git bị đẩy xuống cổ họng thay vì được cung cấp như một DVCS khả thi hệ thống.

Ngược lại, các cộng đồng DVCS khác không ồn ào. Tôi không biết Mercurial tồn tại cho đến khi tôi thấy một "DVCS tốt nhất là gì?" câu hỏi về SO. Trong khi git xuất hiện ở mọi nơi, các DVCS khác sẽ mất thời gian để tìm kiếm.

Tôi không nghĩ Mercurial đặc biệt thấp. Kiln được xây dựng trên Hg và hiện đã có sự hỗ trợ tốt trong các IDE như Eclipse & Netbeans.

Hầu hết các nhà phát triển mà tôi nói chuyện dường như thích Hg hơn vì hỗ trợ Windows tốt hơn. Nếu chúng tôi là nhà phát triển Linux thì đó có thể là một câu chuyện khác.

Bạn cũng đang thiếu "Bazaar", đó là "DVCS bị lãng quên" thực sự.

Chắc chắn tôi đồng ý rằng Linus là một anh chàng rất lôi cuốn và một mọt sách alpha gần như không có ai sánh bằng nên rất nhiều người sẽ bị hút vào Git vì điều đó. Ngoài ra, "huyền thoại sáng tạo" của Git rất hấp dẫn với Linus lao động trong 6 ngày để tạo ra Git và nghỉ ngơi vào ngày thứ bảy - hoặc đại loại như thế. Khi một sản phẩm có một câu chuyện đáng nhớ sẽ dễ dàng đạt được lực kéo.

Đó là một ý kiến ​​khiêm tốn, nhưng git có thể nhận được tất cả sự cường điệu này vì hai tham số:

1. Nó rất hiệu quả
2. Thật thú vị khi sử dụng (theo một cách nào đó của nhà khoa học máy tính rất cụ thể)

Thêm vào đó, git có một số ứng dụng sát thủ như github, và một số dự án rất phổ biến đã quyết định sử dụng nó, điều này mang lại cho nó rất nhiều khả năng hiển thị.

Có ba yếu tố làm việc ở đây, "phương tiện truyền thông beta", "thời gian là đúng" và "đi theo người lãnh đạo"

Phương tiện truyền thông Beta Geek

Có một số kênh nhận được thảo luận về "các hoạt động táo bạo". Họ chắc chắn sẽ bao gồm sự xuất hiện của một hệ thống kiểm soát phiên bản mới, nhưng họ bao gồm git nhiều hơn. Tại sao? Bởi vì Linus Torvalds đã viết nó ban đầu, tranh luận về nó một cách công khai và sử dụng nó như một giải pháp cho vấn đề được công bố rộng rãi của mình với bitkeeper. Thực tế, bất cứ khi nào có một cuộc chiến nảy lửa trên lkml, các phương tiện truyền thông beta sẽ viết một bài báo về nó. Thảo luận Git bắt đầu trên lkml, vì vậy nó có phạm vi bảo hiểm nhiều hơn các lựa chọn thay thế khác. Và những người đam mê beta đã đọc slashdot như Variety đã ăn nó. Kết quả cuối cùng của điều đó là git có số lượng bài viết nhiều gấp mười lần.

Thời gian là đúng

Các dự án nguồn mở lớn với rất nhiều người đóng góp có vấn đề với kiểm soát nguồn tập trung. Khi nguồn mở phát triển và các dự án trở nên có nhiều người đóng góp hơn, vấn đề trở nên tồi tệ hơn. Linux có lẽ là dự án được biết đến nhiều nhất vì điều này, nhưng có rất nhiều dự án khác. Với nhiều dự án đạt đến điểm này, một số loại VCS tiên tiến là cần thiết. Git, Mercurial và Bazaar là những người chiến thắng lớn ở đây. Arch và Monotone chỉ là quá sớm, và đã bỏ lỡ làn sóng cường điệu.

Theo dõi người lãnh đạo

Các dự án lớn có những người theo dõi kiểm tra và xây dựng mã thường xuyên, ngay cả khi họ không đóng góp. Những người theo dõi trở nên quen thuộc với các công cụ cần thiết để tìm nạp dự án mà họ theo dõi, vì vậy những công cụ đó được sử dụng nhiều hơn. Chúng ta hãy xem các dự án "rút thăm lớn" cho ba DVCS lớn:

• Git : Linux, Perl, jQuery, Ruby on Rails, Eclipse, Gnome, KDE, QT, X
• Mercurial : Java, Mozilla, Python
• Chợ : Ubuntu, Emacs

Git có nhiều dự án "vẽ lớn" hơn bằng cách sử dụng nó, do đó nhiều người quen thuộc với git hơn, có nhiều hướng dẫn git hơn được viết.

Nó chủ yếu chỉ là cường điệu tự củng cố. Git là phổ biến nhất, vì vậy nó được công khai nhất, dẫn đến nó trở nên phổ biến hơn.

Git, Hg và Bzr đều là những hệ thống DVCS hoàn toàn tốt, nhưng một số người đáng sợ đánh đồng DVCS với Git và nghĩ rằng tất cả các tính năng đáng yêu của DVCS là duy nhất đối với Git. Và như vậy họ sử dụng Git, và khuyên Git, và nói những câu như "Git là tốt hơn bởi vì nó có thể làm hòa trộn bạch tuộc" (Vì vậy, có thể Bazaar), hoặc "Git là tốt hơn bởi vì nó được phân phối" (như vậy là bất kỳ DVCS, do đó tên ) hoặc "Git tốt hơn vì nó giúp phân nhánh và hợp nhất dễ dàng" (một lần nữa, điều này đúng với mọi DVCS).

Đáng buồn thay, vì tôi cảm thấy các lựa chọn thay thế cũng có rất nhiều thứ để cung cấp, và tôi muốn mọi người chọn Git vì những thế mạnh độc đáo của nó, hơn là vì họ nghĩ DVCS == Git.

Khi ai đó phát hiện ra các DVCS thông minh như thế nào, bằng cách chỉ vào một DVCS cụ thể, họ thường không đi và nói với người khác "này, DVCS rất tuyệt, bạn nên sử dụng chúng", nhưng thay vào đó, "DVCS mà tôi đã học về DVCS từ đó là tuyệt vời, bạn nên sử dụng nó ".

Github. Github là người tiên phong trong lĩnh vực mã hóa xã hội. Nó đã biến kiểm soát phiên bản thành một nền tảng xã hội thu hút nhiều sự chú ý và rõ ràng nó chỉ hỗ trợ Git. Phương tiện truyền thông xã hội = áp dụng lớn hơn. Bitbucket đang có được hơi nước mặc dù nhận được rất nhiều tính năng mới, làm cho nó trở thành một đối thủ có khả năng :)

Thực tế tôi nghĩ rằng sự cường điệu là về tất cả các cuộc họp của DSVC.

Nhưng những người ủng hộ git chỉ là những người có tiếng nói hơn, thường tỏ ra khó chịu hơn trong các bình luận của họ để trung thực và thích nói về nó ở khắp mọi nơi.

Tôi nghi ngờ Mercurial sẽ được sử dụng rộng rãi, chắc chắn là thường xuyên như git, có thể nhiều hơn (Microsoft và các công ty lớn khác sử dụng nó bây giờ), nhưng mọi người sử dụng Mercurial thường chỉ muốn một DSVC mà họ có thể nắm bắt nhanh chóng, không phải là thứ gì đó để dựa vào tôn giáo. Vì vậy, họ ít nói và phản ứng nhiều hơn trong các cuộc thảo luận hơn là chủ động như một số người dùng git.

Bazaar không nói nhiều về chắc chắn vì chỉ có vài dự án lớn được biết đến sử dụng nó và không có công ty lớn nào khác ngoài Canonical được biết là sử dụng nó. Ví dụ, so sánh với Google (git, mercurial, svn) và các dự án nguồn mở lớn và bạn có thể thấy lý do tại sao nó không thực sự được nói đến. Fossil là một ứng dụng thú vị khác dành cho các nhà phát triển, vì vậy tôi đoán rằng họ chỉ nghe thấy những người tìm kiếm các tính năng mà họ cung cấp (như wiki nhúng, theo dõi vấn đề và diễn đàn).

Điều đó đang được nói, tôi nghĩ rằng chúng ta đang dần đi vào chu kỳ cường điệu và rất nhiều nhà phát triển đã sử dụng một số giải pháp khác nhau có thể bắt đầu thấy một trong những phù hợp với nhu cầu của họ.

Ngoài ra, Google Code Hosting và SourceForge hiện cho phép cả git và đồng bóng để nó trở thành lựa chọn dành riêng cho dự án hơn trước đây khi bạn chọn git vì các tính năng của GitHub.

Không có chiến tranh thực sự, chỉ là một loạt các công cụ thú vị.

Tôi biết đã có rất nhiều câu trả lời cho câu hỏi này rồi, nhưng tôi cảm thấy mình có thể thêm một chút quan điểm.

Tôi đã sử dụng Bazaar khá nhiều kể từ khi nó được tạo ra cho nhiều thứ khác nhau. Điều lớn nhất tôi đã sử dụng nó là dự án AllTray, mà hiện tại tôi là nhà phát triển và bảo trì duy nhất. Chợ là tốt. Nó chỉ hoạt động, nó nằm ngoài tầm của tôi, và hầu như không bao giờ tôi phải xem một trang --help hoặc trang man cho nó. Điều đó nói rằng, có một số nhược điểm của nó:

1. Rất nhiều chức năng mà nó có thể được cho là một phần của VCS cốt lõi, thì không. Những thứ như khả năng thực hiện chia nhỏ lịch sử, để chạy đầu ra dài thông qua máy nhắn tin hoặc để có các nhánh nhánh colocated (ví dụ: kho kiểu git) được cung cấp dưới dạng bổ trợ.
2. Rất nhiều plugin không ổn định. Ví dụ, chức năng các nhánh được tạo ra dường như không hoạt động tốt ở phía máy chủ (ít nhất, tôi chưa bao giờ làm cho nó hoạt động, nó có xu hướng lỗi khi nói rằng nhánh tại đường dẫn cụ thể không tồn tại khi nó tồn tại ngay trước mặt bạn và bạn có thể thấy điều đẫm máu).
3. Nó không có hoạt động clone khác, bạn kéo từng nhánh một. Bạn phải làm thêm nếu bạn muốn có một kho lưu trữ để bạn có thể kéo các nhánh mới một cách hiệu quả.
4. Đối với một số dự án, nó rất chậm. Thỉnh thoảng hãy thử nhánh bzr lp: mysql.
5. Nó thiếu hỗ trợ mạnh mẽ cho móc; bạn có thể viết các plugin bzr cung cấp hook, nhưng không có cách chuẩn nào để có các script hook tùy ý phía máy chủ.

Gần đây tôi đã chuyển sang git để phát triển AllTray và rất nhanh chóng xem xét việc chuyển tất cả các dự án của tôi sang git. Có một chút thời gian phía trước dành để làm quen với các sợi dây, nhưng nó có vẻ là giá trị nó. Một số điều mà tôi đã nhận thấy:

1. git clone là một hoạt động tương đối nhanh và cung cấp cho bạn thông tin về tất cả các nhánh tồn tại trong kho lưu trữ mà bạn đã nhân bản.
2. Thêm các kho lưu trữ từ xa bổ sung là không đau, và vì vậy bạn có thể theo dõi nhiều kho lưu trữ khác nhau có nhiều chi nhánh nếu bạn muốn.
3. Các Git Pro cuốn sách là có sẵn trực tuyến và trong nhiều định dạng, bao gồm cho người đọc eBook thiết bị và nó không phải là một đọc khó khăn.
4. git dường như dễ dàng mở rộng hơn Bazaar và bạn không phải sử dụng bất kỳ API cụ thể nào để làm điều đó. (NB: đây là cả nhược điểm và nhược điểm.)
5. git được tích hợp sẵn và tôi không thể nhấn mạnh đủ tiện ích của tính năng đó.
6. GitHub khá đẹp.
7. Các gitosishệ thống cũng khá thoải mái. Tôi thậm chí không chắc người ta sẽ triển khai nó như thế nào ngoài một plugin trong Bazaar và tôi không thể tưởng tượng được nó sẽ ở đâu hiệu quả.

Câu chuyện dài: Tôi đã sử dụng bzr trong một thời gian rất dài, nhưng git đang nhanh chóng chứng minh sự tuyệt vời của nó đối với tôi.

Sử dụng git, bạn có xu hướng luôn ở trong cùng một thư mục cục bộ khi bạn phát triển và chỉ cần thực hiện git checkout branchnameđể chuyển đổi giữa các nhánh (tôi sử dụng các nhánh tính năng "nhẹ" mọi lúc, vì vậy đây là một tính năng rất quan trọng đối với tôi).

Nhìn vào tài liệu và hướng dẫn của Mercurial, có vẻ như cách ưa thích để đối phó với các nhánh phát triển khác nhau là tạo ra các kho lưu trữ mới bằng cách nhân bản. Hướng dẫn này là một ví dụ.

Tôi tin rằng bạn có thể làm điều tương tự trong Mercurial như trong git, nhưng vì một số lý do, tài liệu Mercurial (mà tôi đã đọc) hầu như luôn hiển thị phân nhánh bằng cách tạo một bản sao kho lưu trữ.

(Tôi sử dụng git hàng ngày. Tôi có ít kinh nghiệm về đồng bóng, tôi đã chơi với nó và làm theo một vài hướng dẫn)

Tôi không biết có bao nhiêu lời tán tỉnh như vậy tôi đã thấy trong vài tuần qua, nhưng tất cả họ dường như coi đó là sự thật rằng Mercurial và / hoặc Bazaar khách quan hơn Git. Tính khả dụng dường như là một chủ đề phổ biến. Đúng, học Git thật khó khăn sau khi sử dụng CVS và Subversion, nhưng tại thời điểm này tôi sẽ không muốn trao đổi nó với bất kỳ VCS nào khác trừ khi nó tạo thành một sự thay đổi mô hình khác . Và chỉ vào một bảng các tính năng sẽ cho tôi biết rất ít về mức độ linh hoạt, mở rộng, an toàn hoặc dễ dàng của nó. Ví dụ, theo mặc định git-diff sử dụng màu sắc và máy nhắn tin. Chắc chắn tôi có thể nhận được cùng diff ... | colordiff | less -Rhoặc với một cái gì đó, nhưng rõ ràng tại sao cái này tốt hơn cái kia.

Công bằng mà nói, tôi nghĩ rằng những người ủng hộ git so với đồng bóng là rất ít và xa so với những người ủng hộ git so với tập trung. Tuy nhiên, những lý do rất dễ để tóm tắt:

Git là kiểm soát phiên bản cho lập trình viên. Mercurial là phiên bản kiểm soát cho các doanh nghiệp. Tập trung là một thử nghiệm đầu tiên đầy đủ trong việc phát minh ra kiểm soát phiên bản, đặc biệt là xem xét nó được thiết kế trước cuộc cách mạng máy tính cá nhân.

Điều tôi muốn nói là kiểm soát phiên bản cho các lập trình viên là các lập trình viên nói chung thiên về sự linh hoạt hơn là dễ học. Rốt cuộc, chúng tôi sẵn sàng dành nhiều năm để học các ngôn ngữ bí truyền để có thể linh hoạt làm cho máy tính làm những điều không thể đào tạo được. Git cung cấp cho các lập trình viên sự linh hoạt để sử dụng nó theo cách họ muốn, với chi phí mất nhiều thời gian hơn để học cách sử dụng sự linh hoạt đó một cách an toàn. Nó cho phép các hạn chế được đưa ra để thực thi các chính sách, nhưng không đi ra khỏi đó. Lưu ý tôi nói dễ học hơn là dễ sử dụng . Khi bạn tìm hiểu nó, git cũng dễ sử dụng như mọi VCS khác, và thường dễ dàng hơn do tốc độ và tính năng tăng lên.

Một số lập trình viên học đủ để làm những gì họ muốn, sau đó chống lại việc học những cách mới để làm điều đó. Các doanh nghiệp thuê và sử dụng nhiều người trong số họ, vì vậy họ muốn bất kỳ thay đổi nào trong các công cụ họ sử dụng để có một mức độ quen thuộc nhất định. Các doanh nghiệp cũng muốn các lập trình viên của họ có đủ sự linh hoạt để thực hiện công việc của họ, nhưng không quá nhiều để làm cho việc đào tạo hoặc di chuyển ban đầu trở nên khó khăn. Đây là nơi phù hợp với đồng bóng. Nó có hầu hết sức mạnh của git, nhưng một con đường di chuyển có phần dễ dàng hơn.

Tôi không nghĩ công bằng khi nói git chỉ phổ biến vì sự cường điệu, hay sự chứng thực của Linus. Điều đó có thể chiếm nhiều người dùng thử , nhưng họ gắn bó và quảng bá nó vì nó hoạt động tốt với họ, thuần túy và đơn giản.

Phát triển NetBSD sử dụng CVS và đó là tất cả những điều quan trọng.

Nó có một tên snappier, pithy hơn cho vay để chơi chữ.

Gần đây tôi đã tìm kiếm một hệ thống kiểm soát phiên bản cho các dự án cá nhân, vì vậy tôi chỉ thử một loạt chúng. Tôi thực sự không biết chữ trên dòng lệnh và tôi đã nghe nói rằng mặc dù GUI có sẵn, Git thực sự được sử dụng thông qua dòng lệnh, điều này khiến tôi hơi do dự. Thành thật mà nói, nó rất dễ để nhận, và tôi thực sự thích nó. Tài liệu là một yếu tố rất lớn trong việc áp dụng một công nghệ mới và Git có hàng tấn tài liệu đơn giản đến nực cười, rõ ràng và có sẵn. Các lựa chọn thay thế khác như SVN và Bazaar là tuyệt vời, họ chỉ không làm cho nó dễ dàng như Git. Github cũng là một nhân tố lớn, vì nó đã trở thành trung tâm của phong trào nguồn mở tại thời điểm này. Có một vị trí tập trung (trớ trêu thay) để trao đổi mã và các dự án thông qua chính nó là một công cụ thay đổi trò chơi.

Chỉ 2 - Tôi đã chọn git thay cho các lựa chọn thay thế bởi vì nó được viết bằng C thay vì ngôn ngữ radtool hoặc ngôn ngữ cấp cao quá hàn lâm. Lợi ích là nó nhanh và hiệu quả và tôi thực sự có thể RTFS nếu gặp phải lỗi hoặc hành vi mà tôi không thể giải thích. Nó cũng cho phép sử dụng trên các môi trường phát triển tự lưu trữ nhỏ không bao gồm trình thông dịch / thời gian chạy khổng lồ, nghĩa là tôi có thể trực tiếp lấy từ một repo git và biên dịch trên các hệ thống đó thay vì phải tìm nguồn mới nhất ở nơi khác và rsync.

Bạn có thể muốn đọc lý do tại sao dự án máy tính để bàn Gnome chọn git trên hg và bzr, khi nó quyết định chuyển từ svn vài năm trước. Có rất nhiều cuộc thảo luận tôn giáo sôi nổi trên đường đi, nhưng trang Wiki Gnome này tóm tắt một cách độc đáo những ưu và nhược điểm khi họ áp dụng cho cộng đồng cụ thể đó.

Chưa kể Apple hiện đã tham gia vào việc đẩy nó vào cộng đồng khách quan, nếu bạn đã tạo một ứng dụng mới trong Xcode 4 gần đây, bạn sẽ nhận thấy rằng nó sẽ tự động hỏi bạn có muốn tạo repo Git không.

Xcode 4 được cấp chỉ mới xuất hiện được vài tháng và không ảnh hưởng đến thành công trước đó của Gits, nhưng tất cả chúng ta đều biết Apple có thể tạo ra mọi thứ trong một khoảng thời gian ngắn như thế nào.

Tôi hiện đang chuyển từ hg (lò nung) sang git (github). Tôi đã sử dụng lò nung khoảng một năm nay. Đối với tôi hg không có bất lợi. Tôi có thể làm mọi thứ tôi phải làm. Thật tuyệt vời

Tại sao tôi đang sử dụng ngay bây giờ?

Chỉ có ba lý do ngay bây giờ.

1. gitHub cung cấp ý chính rất tuyệt
2. gitHub cung cấp các tính năng xã hội tuyệt vời
3. Trong khi thực hiện các bài thuyết trình và hội thảo dành cho nhà phát triển, tôi luôn công bố các mẫu của mình trên hg và git. Trên git tôi có khoảng 10 lần khách truy cập so với trên hg !!

Tôi nghĩ rằng cái thứ ba là quan trọng nhất.

Trầm hương

Tôi đoán là may mắn thuần túy, cho đến bây giờ hầu như không thể chứng minh được tại sao thứ gì đó hoạt động và thứ khác lại không. Linus có thể xây dựng một cái gì đó ngoạn mục và không có thành công.