힘내 vs 팀 파운데이션 서버 [닫기]

나는 Git을 개발자 팀에 소개했고 모든 사람은 나를 제외하고는 싫어한다. 그들은 그것을 Team Foundation Server로 교체하려고합니다. 나는 TFS에 익숙하지는 않지만 이것이 거꾸로 된 것처럼 느낍니다. 경험이있는 사람이 TFS의 분기 지원과 Git 분기를 비교할 수 있습니까? 또한 일반적으로 TFS의 장단점은 무엇입니까? 몇 년 동안 Git을 사용한 후에 그것을 싫어합니까?

내 생각 엔

나를 제외한 모두가 싫어

더 이상 토론을 낭비하지 마십시오. Git을 계속 사용하면 문제가 발생하면 책임이 있습니다 .

이 외에도 Git은 중앙 집중식 VCS에 비해 두 가지 장점을 가지고 있습니다 ( Rob Sobers가 부분적으로 설명 ).

• 전체 리포지토리의 자동 백업 : 누군가가 중앙 리포지토리를 가져올 때마다 변경 기록 전체를 가져옵니다. 하나의 리포지토리가 손실 된 경우 걱정하지 마십시오. 모든 워크 스테이션에있는 리포지토리 중 하나를 가져 가십시오.
• 오프라인 REPO 액세스 : 내가 집에서 일하고있을 때 (또는 비행기 또는 기차), 나는 직장 내 VPN 연결을 시작하지 않고, 프로젝트, 매 체크인의 전체 역사를 볼 수 있고 내가 좋아하는 일을 할 수 있었다 직장에서 : 체크인, 체크 아웃, 지점 등

그러나 내가 말했듯이 : 나는 당신이 잃어버린 전투와 싸우고 있다고 생각합니다. 모두가 Git을 싫어할 때 Git을 사용하지 마십시오. 그들이 그들을 설득하려고 시도하는 대신 그들이 힘내 를 싫어하는 이유 를 더 많이 알 수 있습니다.

그들이 단순히 새로운 것을 원하지 않기 때문에 새로운 것을 배우고 싶지 않다면, 그 직원과 함께 성공적인 개발을 하시겠습니까?

실제로 모든 사람이 Git을 싫어합니까, 아니면 일부 의견 리더의 영향을 받습니까? 지도자를 찾아 문제가 무엇인지 물어보십시오. 그들을 설득하면 나머지 팀을 설득 할 수 있습니다.

당신이 지도자를 설득 할 수 없다면 : Git 사용을 잊어라. TFS를 가져 가라. 당신의 인생을 더 쉽게 만들 것입니다.

두 시스템의 주요 차이점은 TFS는 중앙 집중식 버전 제어 시스템이고 Git은 분산 버전 제어 시스템이라는 것입니다.

TFS를 사용하면 리포지토리가 중앙 서버에 저장되고 개발자 는 특정 시점의 코드 스냅 샷 인 작업 복사본을 체크 아웃합니다 . Git을 사용하면 개발자 는 모든 히스토리를 포함 하여 전체 저장소 를 시스템에 복제합니다 .

개발자의 컴퓨터에 전체 저장소를두면 서버가 죽는 경우 중복성이 있다는 이점이 있습니다. 또 다른 좋은 장점은 서버와 대화하지 않고 작업 사본을 수정본간에 앞뒤로 이동할 수 있다는 것입니다. 이는 서버가 다운되었거나 연결할 수없는 경우 유용 할 수 있습니다.

제게 큰 장점 은 서버와 대화하거나 팀에 잠재적으로 불안정한 변경을 가하지 않고 (즉, 빌드 중단) 로컬 저장소에 변경 세트를 커밋 할 수 있다는 것입니다 .

예를 들어, 큰 기능을 사용하는 경우 코드를 작성하고 완전히 테스트하는 데 일주일이 걸릴 수 있습니다. 주중에 불안정한 코드를 체크인하고 빌드를 중단하고 싶지 않지만 주말에 가까워지고 실수로 전체 작업 사본을 중단하면 어떻게됩니까? 내가 최선을 다하지 않으면 나는 일을 잃을 위험이있다. 이는 효과적인 버전 제어가 아니며 TFS는 이에 취약합니다.

DVCS를 사용하면 변경 사항을 로컬로 커밋하므로 빌드 중단에 대해 걱정하지 않고 지속적으로 커밋 할 수 있습니다 . TFS 및 기타 중앙 집중식 시스템에는 로컬 체크인 개념이 없습니다.

DVCS에서 분기 및 병합이 얼마나 나은지에 대해서는 다루지 않았지만 SO 또는 Google을 통해 많은 설명을 찾을 수 있습니다. TFS에서의 브랜칭 및 병합이 좋지 않다는 것을 경험에서 알 수 있습니다.

조직의 TFS가 Git보다 Windows에서 더 잘 작동한다고 주장하는 경우 Windows에서 잘 작동하는 Mercurial을 제안합니다 .Windows 탐색기 (TortoiseHg) 및 Visual Studio (VisualHg)와 통합되어 있습니다.

사람들은 총을 내려 놓고 난간에서 물러나서 잠시 생각 해야합니다. DVCS에는 객관적이고 구체적이며 부인할 수없는 이점이있어 팀의 생산성에 큰 차이가 있습니다.

그것은 모두 분기 및 병합으로 귀결됩니다.

DVCS 이전에이 지침의 원칙은 "분지와 합병에 참여할 필요가 없도록 하나님 께기도하십시오. 그리고 그렇게한다면 최소한 아주 단순하게하도록 간구하십시오."

이제 DVCS를 사용하면 분기 ( 및 병합 )가 크게 향상되고 지침 원리는 "모자이를 떨어 뜨릴 때 수행하십시오. 이는 많은 이점을 제공하고 문제를 일으키지 않습니다."입니다.

그리고 그것은 모든 팀에게 커다란 생산성 향상 도구입니다.

문제는 사람들이 내가 방금 말한 것을 이해하고 그것이 사실이라는 것을 확신하기 위해서는 먼저 약간의 학습 곡선에 투자해야한다는 것입니다. 그들은 Git 또는 다른 DVCS 자체를 배울 필요가 없습니다 ... Git이 분기 및 병합을 수행하는 방법을 배우면됩니다. 일부 기사와 블로그 게시물을 읽고 다시 읽고 느리게 읽고 볼 때까지 작업하십시오. 하루나 이틀 더 나은 시간이 걸릴 수 있습니다.

그러나 일단 당신이 그것을 본 후에는 비 DVCS를 선택하는 것을 고려하지 않을 것입니다. DVCS에는 분명하고 객관적이고 구체적인 이점이 있기 때문에 가장 큰 장점은 분기 및 병합 분야에서입니다.

원본 : @Rob, TFS에는 공식 빌드에 영향을주지 않으면 서 진행중인 작업 커밋에 대한 우려를 해결하는 " 선반 "이라는 것이 있습니다. 중앙 버전 제어를 방해로 간주하지만 TFS와 관련하여 선반에 코드를 검사하는 것은 강도 b / c로 볼 수 있으며 중앙 서버는 드문 경우에 진행중인 작업 사본을 가지고 있습니다 로컬 기계가 충돌하거나 분실 / 도난 당했거나 기어를 빠르게 전환해야합니다. 저의 요점은이 분야에서 TFS가 적절한 칭찬을 받아야한다는 것입니다. 또한 TFS2010의 분기 및 병합은 이전 버전에서 개선되었으며 "... TFS에서의 분기 및 병합이 좋지 않은 경험을 바탕으로 어떤 버전을 참조하고 있는지 명확하지 않습니다." 면책 조항 : 저는 TFS2010의 중간 사용자입니다.

2011 년 12 월 5 일 편집 : OP에 대해 TFS에 대해 귀찮게하는 한 가지 사항은 작업하지 않을 때 모든 로컬 파일을 "읽기 전용"으로 설정해야한다는 것입니다. 변경하려는 경우, 파일을 "체크 아웃"해야 파일의 읽기 전용 속성 만 지워서 TFS가 파일을 계속 주시하도록합니다. 불편한 워크 플로입니다. 내가 선호하는 방식은 내가 변경했는지 여부를 자동으로 감지하고 파일 속성에 전혀 신경 쓰지 않습니다. 그렇게하면 Visual Studio 또는 메모장에서 또는 원하는 도구를 사용하여 파일을 수정할 수 있습니다. 이와 관련하여 버전 관리 시스템은 가능한 투명해야합니다. Windows 탐색기 확장 ( TFS PowerTools)이 있습니다)를 사용하면 Windows 탐색기에서 파일로 작업 할 수 있지만 워크 플로를 크게 단순화하지는 않습니다.

말한 모든 것의 위에 (

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

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

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

), 맞습니다. TFS는 단순한 VCS가 아닙니다. TFS가 제공하는 주요 기능 중 하나는 기본적으로 통합 된 버그 추적 기능입니다. 변경 세트는 문제와 연결되어 있으며 추적 할 수 있습니다. TFS를 실행하는 사람들이 가지고있는 Windows 도메인과의 통합뿐만 아니라 다양한 체크인 정책이 지원됩니다. Visual Studio와 GUI를 긴밀하게 통합 한 것은 또 다른 판매 포인트로, 평균 마우스 및 클릭 개발자와 그의 관리자 보다 매력적 이지 않습니다 .

따라서 Git과 TFS를 비교하는 것은 적절한 질문이 아닙니다. 비실용적이지만 올바른 질문은 Git을 TFS의 VCS 기능과 비교하는 것입니다. 그 때, Git은 TFS를 물 밖으로 불어냅니다. 그러나 심각한 팀에는 다른 도구가 필요하며 TFS는 한 번에 목적지를 제공합니다.

팀에서 TFS를 사용하고 Git을 사용하려는 경우 "git to tfs"브리지를 고려할 수 있습니다. 기본적으로 컴퓨터에서 Git을 사용하여 매일 작업 한 다음 변경 사항을 푸시하려면 TFS 서버로 변경 사항을 푸시합니다.

거기에 몇 가지가 있습니다 (github에). 마지막 장소에서 다른 개발자와 함께 하나의 성공을 거두었습니다. 보다:

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

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

찬반 양론을 조사한 결과, 제가 관여 한 회사도 TFS로 가기로 결정했습니다. GIT가 좋은 버전 제어 시스템이 아니기 때문에 TFS가 제공하는 완전히 통합 된 ALM 솔루션에 가장 중요합니다. 버전 제어 기능 만 중요한 경우 GIT 일 수 있습니다. 그러나 일반 개발자의 가파른 GIT 학습 곡선은 과소 평가되지 않을 수 있습니다.

내 블로그 게시물 TFS에서 진정한 교차 기술 플랫폼 으로 자세한 설명을 참조하십시오 .

Git의 전체 배포는 정말 훌륭합니다. 여기에는 로컬 롤백 및 커밋 옵션 (예 : Eclipse의 localhistory 기능 ) 과 같이 선반 세트에 현재 제품에없는 몇 가지 기능이 있습니다 . 개발자 브랜치를 사용하여이를 완화 할 수 있지만 솔직히 말하면 많은 개발자는 브랜칭 및 1 비트 병합을 좋아하지 않습니다. TFS에서 이전 스타일의 "독점 체크 아웃"기능을 너무 자주 몇 번 켜야했습니다 (매번 거부).

많은 대기업이 개발자가 전체 역사를 로컬 작업 공간으로 가져 와서 (예를 들어 새로운 고용주에게) 가져갈 수있게하는 것이 무서워한다고 생각합니다 ... 스냅 샷을 도용하는 것은 좋지 않지만 전체 역사를 빼앗아갑니다. 더 귀찮습니다. ( TFS 에서 원하는 전체 역사를 얻을 수는 없었 습니다) ...

백업을 수행하는 좋은 방법이라고 언급했는데, 이는 원래 유지 관리자가 관리를 중단하고 버전을 제거 할 수있는 오픈 소스를 다시 사용하는 것이 좋지만, 엔터프라이즈 계획의 경우 책임이 명확하게 지정되지 않기 때문에 많은 기업에게는 다시 부족합니다. 백업을 유지합니다. 그리고 주요 '프로젝트'가 어떻게 든 사라지면 사용할 버전을 파악하기가 어려울 것입니다. 하나의 저장소를 주요 / 중앙으로 지정하는 경향이 있습니다.

Git에서 가장 마음에 드는 점은 Push / Pull 옵션으로, 커밋 권한이 없어도 프로젝트에 코드를 쉽게 제공 할 수 있습니다. TFS에서 매우 제한된 사용자 및 선반 세트를 사용하여이를 모방 할 수는 있지만 Git 옵션만큼 강력하지는 않습니다. 팀 프로젝트 전체에 걸쳐 분기해도 효과가있을 수 있지만, 팀 프로젝트를 추가하면 많은 관리 오버 헤드가 발생하기 때문에 관리 측면에서는 많은 조직에서 실제로 실현 가능하지 않습니다.

또한 비 소스 제어 영역에서 언급 한 내용을 추가하고 싶습니다. 작업 항목 추적,보고 및 빌드 자동화 (실험실 관리 포함)와 같은 기능은 중앙의 주요 리포지토리에서 큰 이점을 얻습니다. 순수한 분산 모델을 사용하면 노드 중 하나를 선행하지 않고 덜 분산 된 모델로 돌아 가지 않는 한 훨씬 더 어려워집니다.

TFS 11과 함께 제공되는 TFS Basic을 사용하면 로컬 TFS 기본을 TFS 12+ 시대의 중앙 TFS와 동기화 할 수있는 분산 TFS를 기대할 수 있습니다. 나는 그것에 대한 투표를 uservoice에 넣을 것이다 !

나에게 가장 큰 차이점은 TFS가 TFS를 '지원'하기 위해 솔루션 (.vssscc)에 추가 할 모든 임시 파일입니다.이 파일에 대한 최근 문제가 잘못된 분기에 매핑되어 흥미로운 디버깅이 발생합니다. ...