Máy chủ Git vs Team Foundation [đã đóng]

Tôi đã giới thiệu Git cho nhóm phát triển của mình và mọi người ghét nó ngoại trừ tôi. Họ muốn thay thế nó bằng Team Foundation Server. Tôi cảm thấy như đây là một bước lùi rất lớn, mặc dù tôi không quen lắm với TFS. Ai đó có kinh nghiệm có thể so sánh hỗ trợ phân nhánh trên TFS với phân nhánh Git không? Ngoài ra, nói chung, những ưu và nhược điểm của TFS là gì? Tôi sẽ ghét nó sau khi sử dụng Git trong một vài năm?

Tôi nghĩ rằng, tuyên bố

mọi người ghét nó trừ tôi

làm cho bất kỳ cuộc thảo luận nào trở nên lãng phí: khi bạn tiếp tục sử dụng Git, họ sẽ đổ lỗi cho bạn nếu có gì sai sót.

Ngoài ra, đối với tôi, Git có hai lợi thế so với một VCS tập trung mà tôi đánh giá cao nhất (như được mô tả một phần bởi Rob Sobers ):

• tự động sao lưu toàn bộ repo: mỗi khi có ai đó rút từ repo trung tâm, anh ấy / cô ấy sẽ có một lịch sử đầy đủ về các thay đổi. Khi một repo bị mất: đừng lo lắng, hãy lấy một trong những thứ có mặt trên mỗi máy trạm.
• truy cập repo ngoại tuyến: khi tôi làm việc tại nhà (hoặc trên máy bay hoặc tàu hỏa), tôi có thể xem toàn bộ lịch sử của dự án, mỗi lần đăng ký, mà không cần khởi động kết nối VPN của tôi để hoạt động và có thể hoạt động như tôi đang làm việc : checkin, checkout, chi nhánh, bất cứ thứ gì.

Nhưng như tôi đã nói: Tôi nghĩ rằng bạn đang chiến đấu với một trận chiến đã mất: khi mọi người ghét Git, đừng sử dụng Git. Nó có thể giúp bạn biết thêm lý do tại sao họ ghét Git thay vì cố gắng thuyết phục họ.

Nếu họ chỉ đơn giản là không muốn điều đó vì nó mới đối với họ và không sẵn sàng học hỏi điều gì mới: bạn có chắc chắn rằng bạn sẽ phát triển thành công với nhân viên đó không?

Có thực sự mỗi người ghét Git hoặc họ bị ảnh hưởng bởi một số nhà lãnh đạo ý kiến? Tìm các nhà lãnh đạo và hỏi họ những gì vấn đề. Thuyết phục họ và bạn sẽ thuyết phục phần còn lại của đội.

Nếu bạn không thể thuyết phục được các nhà lãnh đạo: hãy quên sử dụng Git, hãy dùng TFS. Sẽ làm cho cuộc sống của bạn dễ dàng hơn.

Sự khác biệt chính giữa hai hệ thống là TFS là hệ thống kiểm soát phiên bản tập trung và Git là hệ thống kiểm soát phiên bản phân tán.

Với TFS, các kho lưu trữ được lưu trữ trên một máy chủ trung tâm và các nhà phát triển kiểm tra một bản sao đang hoạt động, đó là một ảnh chụp nhanh mã tại một thời điểm cụ thể. Với Git, các nhà phát triển đã sao chép toàn bộ kho lưu trữ vào máy của họ, bao gồm tất cả lịch sử.

Một lợi ích của việc có kho lưu trữ đầy đủ trên các máy của nhà phát triển của bạn là dự phòng trong trường hợp máy chủ chết. Một lợi ích tuyệt vời khác là bạn có thể di chuyển bản sao làm việc của mình qua lại giữa các lần sửa đổi mà không bao giờ nói chuyện với máy chủ, điều này có thể hữu ích nếu máy chủ ngừng hoạt động hoặc không thể truy cập được.

Đối với tôi, lợi ích thực sự là bạn có thể cam kết thay đổi vào kho lưu trữ cục bộ của mình mà không bao giờ nói chuyện với máy chủ hoặc gây ra những thay đổi có thể không ổn định trong nhóm của bạn (ví dụ: phá vỡ bản dựng).

Chẳng hạn, nếu tôi đang làm việc trên một tính năng lớn, có thể tôi sẽ mất một tuần để viết mã và kiểm tra nó hoàn toàn. Tôi không muốn đăng ký mã không ổn định vào giữa tuần và phá vỡ bản dựng, nhưng điều gì xảy ra nếu tôi gần cuối tuần và tôi vô tình làm hỏng toàn bộ bản sao làm việc của mình? Nếu tôi không cam kết tất cả cùng tôi có nguy cơ mất việc. Đó không phải là kiểm soát phiên bản hiệu quả và TFS dễ bị điều này.

Với DVCS, tôi có thể cam kết liên tục mà không lo lắng về việc phá vỡ bản dựng, vì tôi cam kết thay đổi cục bộ . Trong TFS và các hệ thống tập trung khác, không có khái niệm về đăng ký cục bộ.

Tôi thậm chí chưa đi sâu vào việc phân nhánh và sáp nhập tốt hơn như thế nào trong DVCS, nhưng bạn có thể tìm thấy vô số lời giải thích ở đây trên SO hoặc thông qua Google. Tôi có thể nói với bạn từ kinh nghiệm rằng việc phân nhánh và sáp nhập trong TFS là không tốt.

Nếu đối số cho TFS trong tổ chức của bạn là nó hoạt động tốt hơn trên Windows so với Git, thì tôi đề xuất Mercurial, hoạt động tốt trên Windows - tích hợp với Windows Explorer (TortoiseHg) và Visual Studio (VisualHg).

Mọi người cần đặt súng xuống, bước ra khỏi gờ đá và suy nghĩ trong một phút. Hóa ra, có những lợi thế khách quan, cụ thể và không thể phủ nhận đối với DVCS sẽ tạo ra sự khác biệt lớn trong năng suất của một đội.

Tất cả đều thuộc về Phân nhánh và Sáp nhập.

Trước DVCS, nguyên tắc chỉ đạo là "Hãy cầu nguyện với Chúa rằng bạn không cần phải phân nhánh và hợp nhất. Và nếu bạn làm thế, ít nhất hãy cầu xin Ngài hãy để nó thật đơn giản."

Giờ đây, với DVCS, việc phân nhánh ( và sáp nhập ) đã được cải thiện rất nhiều, nguyên tắc hướng dẫn là: "Hãy làm điều đó ngay lập tức. Nó sẽ mang lại cho bạn rất nhiều lợi ích và không gây ra cho bạn bất kỳ vấn đề nào."

Và đó là một tăng năng suất HUGE cho bất kỳ đội nào.

Vấn đề là, để mọi người hiểu những gì tôi vừa nói và tin chắc rằng đó là sự thật, trước tiên họ phải đầu tư vào một chút của một đường cong học tập. Họ không phải học Git hoặc bất kỳ DVCS nào khác ... họ chỉ cần học cách Git phân nhánh và hợp nhất. Đọc và đọc lại một số bài viết và bài đăng trên blog, làm cho nó chậm, và làm việc với nó cho đến khi bạn nhìn thấy nó. Điều đó có thể mất phần tốt hơn của 2 hoặc 3 ngày đầy đủ.

Nhưng một khi bạn thấy điều đó, bạn thậm chí sẽ không cân nhắc lựa chọn không phải DVCS. Bởi vì thực sự có những lợi thế rõ ràng, khách quan, cụ thể đối với DVCS và những chiến thắng lớn nhất là trong lĩnh vực phân nhánh và sáp nhập.

Bản gốc : @Rob, TFS có một cái gì đó gọi là " Kệ " giải quyết mối quan tâm của bạn về việc cam kết tiến hành công việc mà không ảnh hưởng đến bản dựng chính thức. Tôi nhận thấy bạn thấy kiểm soát phiên bản trung tâm là một trở ngại, nhưng đối với TFS, việc kiểm tra mã của bạn vào giá có thể được xem là một điểm mạnh sau đó máy chủ trung tâm có một bản sao tiến trình công việc của bạn trong sự kiện hiếm gặp máy cục bộ của bạn gặp sự cố hoặc bị mất / bị đánh cắp hoặc bạn cần chuyển đổi bánh răng nhanh chóng. Quan điểm của tôi là TFS nên được khen ngợi trong lĩnh vực này. Ngoài ra, việc phân nhánh và hợp nhất trong TFS2010 đã được cải thiện so với các phiên bản trước và không rõ bạn đang đề cập đến phiên bản nào khi bạn nói "... từ kinh nghiệm rằng việc phân nhánh và sáp nhập trong TFS là không tốt." Tuyên bố miễn trừ trách nhiệm: Tôi là người dùng vừa phải của TFS2010.

Chỉnh sửa ngày 5 tháng 12 năm 2011 : Đối với OP, một điều khiến tôi băn khoăn về TFS là nó khăng khăng cài đặt tất cả các tệp cục bộ của bạn thành "chỉ đọc" khi bạn không làm việc với chúng. Nếu bạn muốn thực hiện thay đổi, luồng là bạn phải "kiểm tra" tệp, chỉ cần xóa thuộc tính chỉ đọc trên tệp để TFS biết để mắt đến nó. Đó là một quy trình làm việc bất tiện. Cách tôi muốn nó hoạt động là nó chỉ tự động phát hiện nếu tôi đã thực hiện thay đổi và hoàn toàn không lo lắng / bận tâm với các thuộc tính tệp. Bằng cách đó, tôi có thể sửa đổi tệp trong Visual Studio hoặc Notepad hoặc với bất kỳ công cụ nào tôi muốn. Hệ thống kiểm soát phiên bản phải minh bạch nhất có thể về vấn đề này. Có tiện ích mở rộng Windows Explorer ( TFS PowerTools) cho phép bạn làm việc với các tệp của mình trong Windows Explorer, nhưng điều đó không đơn giản hóa quá trình làm việc rất nhiều.

Trên tất cả mọi thứ đã được nói (

https://stackoverflow.com/a/4416666/172109

https://stackoverflow.com/a/3614099/172109

https://stackoverflow.com/a/4415234/172109

), điều này là chính xác, TFS không chỉ là một VCS. Một tính năng chính mà TFS cung cấp là chức năng theo dõi lỗi tích hợp. Thay đổi được liên kết với các vấn đề và có thể được theo dõi. Các chính sách khác nhau để đăng ký được hỗ trợ, cũng như tích hợp với miền Windows, đó là những gì những người chạy TFS có. GUI tích hợp chặt chẽ với Visual Studio là một điểm bán hàng khác, hấp dẫn nhà phát triển nhấp chuột và nhấp chuột trung bình và người quản lý của anh ta.

Do đó, so sánh Git với TFS không phải là một câu hỏi thích hợp để hỏi. Mặc dù không chính xác, câu hỏi là so sánh Git với chức năng VCS của TFS. Khi đó, Git thổi TFS ra khỏi nước. Tuy nhiên, bất kỳ nhóm nghiêm túc nào cũng cần các công cụ khác và đây là nơi TFS cung cấp một điểm dừng.

Nếu nhóm của bạn sử dụng TFS và bạn muốn sử dụng Git, bạn có thể muốn xem xét một cây cầu "git to tfs". Về cơ bản, bạn làm việc hàng ngày bằng cách sử dụng Git trên máy tính của mình, sau đó khi bạn muốn đẩy các thay đổi của mình, bạn đẩy chúng đến máy chủ TFS.

Có một cặp vợ chồng ngoài kia (trên github). Tôi đã sử dụng một cái ở vị trí cuối cùng của tôi (cùng với một nhà phát triển khác) với một số thành công. Xem:

https://github.com/spraint/git-tfs

https://github.com/git-tfs/git-tfs

Sau một vài cuộc điều tra giữa pro và cons, công ty mà tôi tham gia cũng quyết định đi TFS. Không phải vì GIT không phải là một hệ thống kiểm soát phiên bản tốt, mà quan trọng nhất là giải pháp ALM tích hợp đầy đủ mà TFS cung cấp. Nếu chỉ có tính năng kiểm soát phiên bản là quan trọng, sự lựa chọn có thể là GIT. Tuy nhiên, đường cong học tập GIT dốc cho các nhà phát triển thường xuyên có thể không được đánh giá thấp.

Xem giải thích chi tiết trong bài đăng trên blog của tôi TFS như một nền tảng công nghệ chéo thực sự .

Toàn bộ điều phân phối của Git thực sự rất tuyệt vời. nó cung cấp một vài tính năng Kệ không có (trong sản phẩm hiện tại), chẳng hạn như các tùy chọn rollback và cam kết cục bộ (như tính năng lịch sử cục bộ của Eclipse ). Bạn có thể giảm bớt điều này bằng cách sử dụng các nhánh của nhà phát triển, nhưng thành thật mà nói, nhiều nhà phát triển không thích phân nhánh và hợp nhất một chút. Tôi đã được yêu cầu bật tính năng "thanh toán độc quyền" kiểu cũ trong TFS một vài lần quá thường xuyên (và từ chối nó mỗi lần).

Tôi nghĩ rằng nhiều doanh nghiệp lớn khá sợ hãi khi cho phép một nhà phát triển chỉ mang toàn bộ lịch sử vào không gian làm việc tại địa phương và mang nó theo (ví dụ với một chủ nhân mới) ... Đánh cắp ảnh chụp nhanh là xấu, nhưng lấy đi toàn bộ lịch sử thậm chí còn rắc rối hơn. (Không phải là bạn không thể có được một lịch sử đầy đủ từ TFS của bạn muốn nó) ...

Nó đã đề cập rằng đó là một cách tuyệt vời để sao lưu, rất tốt cho nguồn mở một lần nữa, nơi người bảo trì ban đầu có thể dừng lại để quan tâm và xóa phiên bản của anh ta, nhưng đối với một kế hoạch doanh nghiệp, điều này lại trở nên thiếu sót đối với nhiều doanh nghiệp vì không có sự phân công trách nhiệm rõ ràng để giữ bản sao lưu. Và thật khó để tìm ra phiên bản nào sẽ sử dụng nếu 'dự án' chính biến mất bằng cách nào đó. Mà sẽ có xu hướng chỉ định một kho lưu trữ là hàng đầu / trung tâm.

Điều tôi thích nhất ở Git là tùy chọn Đẩy / Kéo, nơi bạn có thể dễ dàng đóng góp mã cho dự án mà không cần phải có quyền cam kết. Tôi đoán bạn có thể sử dụng những người dùng và kệ rất hạn chế trong TFS để bắt chước điều này, nhưng nó không mạnh bằng tùy chọn Git. Việc phân nhánh giữa các dự án nhóm cũng có thể hoạt động tốt, nhưng từ góc độ hành chính, điều đó không thực sự khả thi đối với nhiều tổ chức vì việc thêm các dự án nhóm thêm rất nhiều chi phí quản lý.

Tôi cũng muốn thêm vào những điều được đề cập trong khu vực không kiểm soát nguồn. Các tính năng như Theo dõi mục công việc, báo cáo và tự động hóa xây dựng (bao gồm quản lý phòng thí nghiệm) được hưởng lợi rất nhiều từ kho lưu trữ hàng đầu trung tâm. Chúng trở nên khó hơn rất nhiều khi bạn sử dụng một mô hình phân tán thuần túy, trừ khi bạn tạo một trong các nút dẫn đầu (và do đó quay trở lại mô hình ít phân tán hơn).

Với TFS Basic đi kèm với TFS 11, có thể không còn xa để mong đợi một TFS phân tán cho phép bạn đồng bộ hóa TFS cơ bản của bạn với TFS trung tâm trong kỷ nguyên TFS 12+. Tôi sẽ bỏ phiếu của tôi cho điều đó trong uservoice !

Đối với tôi, sự khác biệt chính là tất cả các tệp phụ trợ mà TFS sẽ thêm vào giải pháp của bạn (.vssscc) để 'hỗ trợ' TFS - chúng tôi đã gặp sự cố gần đây với các tệp này bị ánh xạ vào nhánh sai, dẫn đến một số gỡ lỗi thú vị ...