Git vs Team Foundation 서버
제 개발팀에 Git을 소개했는데 저만 빼고 다 싫어합니다.이 서버를 Team Foundation Server로 바꾸려고 합니다.저는 TFS에 익숙하지 않지만, 이것이 큰 후퇴라고 생각합니다.경험이 있는 사람이 TFS의 분기 지원을 Git 분기와 비교할 수 있습니까?또한 일반적으로 TFS의 장단점은 무엇입니까?내가 몇 년 동안 Git를 사용하고 나면 싫어질까요?
내 생각에, 그 진술은
저만 빼고 다 싫어합니다.
더 이상의 토론을 낭비하게 만듭니다. Git를 계속 사용하면 문제가 생기면 그들이 당신을 비난할 것입니다.
이 외에도 Git는 중앙 집중식 VCS에 비해 두 가지 이점이 있습니다(Rob Sobers가 부분적으로 설명함)
- 전체 저장소의 자동 백업: 중앙 저장소에서 작업을 시작할 때마다 변경 사항에 대한 전체 기록을 얻을 수 있습니다.하나의 레포를 잃어버렸을 때: 걱정하지 말고, 모든 워크스테이션에 있는 사람들 중 하나를 가져가세요.
- 오프라인 레포 액세스: 집에서(또는 비행기나 기차 안에서) 작업할 때, 작업에 대한 VPN 연결을 시작하지 않고도 프로젝트의 전체 기록, 모든 체크인을 볼 수 있으며, 체크인, 체크아웃, 지점, 기타 모든 작업을 수행할 수 있습니다.
하지만 제가 말했듯이,내 생각에 당신은 패배한 싸움을 하고 있는 것 같아요: 모두가 깃을 싫어할 때, 깃을 사용하지 마세요.그들을 설득하는 대신 왜 Git를 싫어하는지 아는 것이 당신에게 더 도움이 될 수 있습니다.
만약 그들이 단지 그것이 그들에게 새로운 것이고 새로운 것을 배우려고 하지 않기 때문에 그것을 원하지 않는다면, 당신은 그 직원과 함께 성공적인 개발을 할 것이라고 확신합니까?
정말 모든 사람들이 깃을 싫어하나요 아니면 그들은 몇몇 오피니언 리더들의 영향을 받았나요?리더들을 찾아서 무엇이 문제인지 물어봅니다.그들을 설득하면 나머지 팀원들을 설득할 수 있습니다.
지도자들을 설득할 수 없다면, Git을 사용하는 것은 잊어버리고 TFS를 선택하십시오.당신의 삶을 더 편하게 해줄 것입니다.
두 시스템의 주요 차이점은 TFS는 중앙 집중식 버전 제어 시스템이고 Git는 분산형 버전 제어 시스템이라는 것입니다.
TFS를 사용하면 저장소가 중앙 서버에 저장되고 개발자는 특정 시점의 코드 스냅샷인 작업 복사본을 체크아웃합니다.Git를 사용하면 개발자는 모든 기록을 포함한 전체 저장소를 자신의 컴퓨터에 복제합니다.
개발자의 컴퓨터에 전체 리포지토리를 설치함으로써 얻을 수 있는 이점 중 하나는 서버가 중단될 경우를 대비한 이중화입니다.서버와 대화하지 않고 수정본 사이에서 작업 복사본을 앞뒤로 이동할 수 있다는 점도 좋은 장점입니다. 이는 서버가 다운되었거나 연결할 수 없는 경우에 유용합니다.
서버와 대화를 나누거나 팀에 잠재적으로 불안정한 변경 사항을 주지 않고 로컬 저장소에 변경 사항을 적용할 수 있다는 것이 저에게 진정한 이점입니다(예: 빌드 중단).
예를 들어 큰 기능을 사용하는 경우 코드를 작성하고 완전히 테스트하는 데 일주일이 걸릴 수 있습니다.불안정한 코드를 주 중반에 체크인하여 빌드를 중단하고 싶지는 않지만, 주말이 다 되어가는데 실수로 전체 작업 복사본을 잘못 작성하면 어떻게 됩니까?만약 제가 계속 일을 해오지 않았다면, 저는 제 일을 잃을 위험을 감수했을 것입니다.이것은 효과적인 버전 제어가 아니며 TFS는 이에 취약합니다.
DVCS를 사용하면 변경 사항을 로컬로 커밋하므로 빌드가 중단될 염려 없이 지속적으로 커밋할 수 있습니다.TFS 및 기타 중앙 집중식 시스템에는 로컬 체크인 개념이 없습니다.
DVCS에서 분기 및 병합이 얼마나 더 나은지에 대해서는 자세히 설명하지 않았지만 SO 또는 Google을 통해 수많은 설명을 찾을 수 있습니다.TFS에서의 분기 및 합병은 좋지 않다는 것을 경험을 통해 말씀드릴 수 있습니다.
조직에서 TFS의 주장이 Git보다 Windows에서 더 잘 작동한다는 것이라면 Windows 탐색기(TortoiseHg) 및 Visual Studio(VisualHg)와 통합된 Mercurial을 추천합니다.
사람들은 총을 내려놓고, 선반에서 물러나 잠시 생각해야 합니다.DVCS에는 객관적이고 구체적이며 부정할 수 없는 이점이 있으며 이는 팀의 생산성에 큰 변화를 가져올 것입니다.
모든 것은 분기와 병합으로 귀결됩니다.
DVCS 이전의 지도 원칙은 "하나님께 가지를 치고 합병할 필요가 없도록 기도하라"였습니다.그리고 만약 그렇다면, 적어도 그에게 매우, 매우 단순하게 해달라고 간청하세요."
이제 DVCS를 사용하면 분기(및 병합)가 훨씬 개선되어 지침이 됩니다. "바로 실행하십시오.그것은 당신에게 많은 혜택을 줄 것이고 당신에게 어떤 문제도 일으키지 않을 것입니다."
이는 모든 팀에게 엄청난 생산성 향상 효과를 가져다 줍니다.
문제는 사람들이 제가 방금 한 말을 이해하고 그것이 사실이라고 확신하기 위해서는 먼저 약간의 학습 곡선에 투자해야 한다는 것입니다.Git나 다른 DVCS 자체를 배울 필요는 없습니다.그들은 Git가 어떻게 분기하고 합병하는지만 알면 됩니다.일부 기사와 블로그 게시물을 읽고 다시 읽으며, 천천히 읽고, 볼 때까지 계속합니다.그것은 대부분 2~3일 정도 걸릴 것입니다.
하지만 일단 이를 알게 되면 비 DVCS를 선택하는 것은 고려하지도 않을 것입니다.DVCS에는 명확하고 객관적이며 구체적인 이점이 있으며 가장 큰 이점은 분기 및 합병 분야이기 때문입니다.
원본: @Rob, TFS에는 공식 빌드에 영향을 주지 않고 진행 중인 작업을 수행하는 것에 대한 우려를 해결하는 "쉘빙"이라는 것이 있습니다.중앙 버전 제어가 장애물로 간주된다는 것을 알고 있습니다. 하지만 TFS와 관련하여, 쉘프에 코드를 체크하는 것은 b/c로 간주될 수 있습니다. 그러면 중앙 서버는 드물게 로컬 기계가 충돌하거나 분실/도난을 당하거나 기어를 빨리 전환해야 하는 경우에도 진행 중인 작업의 복사본을 가지고 있습니다.제 요점은 TFS가 이 분야에서 적절한 칭찬을 받아야 한다는 것입니다.또한 TFS2010에서의 분기 및 병합은 이전 버전보다 개선되었으며, "... 경험상 TFS에서의 분기 및 병합은 좋지 않습니다."라고 말할 때 어떤 버전을 참조하는지 명확하지 않습니다.고지 사항:저는 TFS2010의 적당한 사용자입니다.
2011년 12월 5일 편집:OP에게 TFS에 대해 신경 쓰이는 한 가지는 작업하지 않을 때 모든 로컬 파일을 "읽기 전용"으로 설정해야 한다는 것입니다.변경하려면 파일을 "체크아웃"해야 합니다. 그러면 TFS가 파일을 감시하도록 파일의 읽기 전용 특성만 삭제합니다.그것은 불편한 작업 흐름입니다.제가 원하는 방식은 변경했는지 자동으로 감지하고 파일 속성을 전혀 걱정하거나 신경 쓰지 않는 것입니다.그러면 Visual Studio, 메모장 또는 원하는 도구로 파일을 수정할 수 있습니다.버전 관리 시스템은 이와 관련하여 가능한 한 투명해야 합니다.Windows 탐색기에서 파일 작업을 수행할 수 있는 Windows 탐색기 확장(TFS PowerTools)이 있지만 워크플로가 그리 간단하지는 않습니다.
모든 말 위에 (
https://stackoverflow.com/a/4416666/172109
). 맞습니다. TFS는 단순한 VCS가 아닙니다.TFS가 제공하는 주요 기능 중 하나는 기본적으로 통합된 버그 추적 기능입니다.변경사항 집합은 문제와 연결되어 있으며 추적할 수 있습니다.체크인을 위한 다양한 정책과 TFS를 실행하는 사람들이 가지고 있는 Windows 도메인과의 통합이 지원됩니다.Visual Studio와 긴밀하게 통합된 GUI는 평균 이하의 마우스와 클릭 개발자 및 관리자에게 매력적인 또 다른 세일즈 포인트입니다.
따라서 Git를 TFS와 비교하는 것은 질문하기에 적절한 질문이 아닙니다.Git를 TFS의 VCS 기능과 비교하는 것은 비현실적이지만 올바른 문제입니다.그 때, Git은 TFS를 물 밖으로 날려버립니다.그러나 심각한 팀은 다른 툴을 필요로 하며, 여기서 TFS가 한 곳에서 목적지를 제공합니다.
팀에서 TFS를 사용하고 Git를 사용하려면 "Git to tfs" 브리지를 고려해야 합니다.기본적으로 컴퓨터에서 Git를 사용하여 매일 작업한 다음 변경 사항을 TFS 서버에 적용합니다.
밖에 (깃허브에) 커플이 있습니다.저는 마지막 장소에서 (다른 개발자와 함께) 어느 정도 성공적으로 사용했습니다.참조:
https://github.com/spraints/git-tfs
https://github.com/git-tfs/git-tfs
찬성과 반대 사이에 약간의 조사가 있은 후, 제가 관여했던 회사도 TFS에 가기로 결정했습니다.GIT가 좋은 버전 제어 시스템이 아니기 때문이 아니라 TFS가 제공하는 완전 통합 ALM 솔루션에 가장 중요합니다.버전 제어 기능만 중요했다면 GIT를 선택했을 수 있습니다.그러나 일반 개발자를 위한 가파른 GIT 학습 곡선은 과소평가되지 않을 수 있습니다.
진정한 교차 기술 플랫폼으로서의 자세한 설명은 블로그 게시물 TFS를 참조하십시오.
Git의 분산된 모든 것은 정말 훌륭합니다.셸프셋에는 로컬 롤백 및 커밋 옵션(예: Eclipse의 로컬 히스토리 기능)과 같은 현재 제품에는 없는 몇 가지 기능이 있습니다.개발자 브랜치를 사용하면 이 문제를 완화할 수 있지만, 솔직히 말해서 많은 개발자들은 브랜치와 합병을 좋아하지 않습니다.저는 TFS에서 오래된 스타일의 "전용 체크아웃" 기능을 켜달라는 요청을 몇 번 너무 자주 받았습니다(그리고 매번 거부했습니다).
많은 대기업들이 개발자가 전체 역사를 로컬 작업 공간에 가져와서 (예를 들어 새로운 고용주에게) 가져가도록 허용하는 것을 상당히 두려워하고 있다고 생각합니다.스냅샷을 훔치는 것은 나쁘지만, 전체 기록을 훔치는 것은 훨씬 더 귀찮습니다.(TFS에서 원하는 전체 내역을 얻을 수 없었던 것은 아닙니다.)
백업을 수행하는 좋은 방법으로 언급되고 있습니다. 즉, 원래 유지 관리자가 백업을 중단하고 버전을 제거할 수 있는 오픈 소스에는 적합하지만, 엔터프라이즈 계획의 경우 백업을 유지할 책임이 명확하게 할당되어 있지 않기 때문에 많은 기업에서는 백업이 부족합니다.그리고 메인 '프로젝트'가 어떻게든 사라진다면 어떤 버전을 사용해야 할지 고민이 될 것입니다.즉, 하나의 저장소를 선도적/중심적으로 지정하는 경향이 있습니다.
내가 Git에 대해 가장 좋아하는 것은 Push/Pull 옵션인데, 이 옵션은 커밋 권한 없이 프로젝트에 코드를 쉽게 제공할 수 있습니다.TFS에서 매우 제한된 사용자와 쉘프 세트를 사용하여 이를 모방할 수 있지만 Git 옵션만큼 강력하지는 않습니다.팀 프로젝트 간에 분기하는 것도 효과적일 수 있지만, 관리 측면에서는 팀 프로젝트를 추가하면 관리 오버헤드가 많이 발생하기 때문에 많은 조직에서 실현 가능하지 않습니다.
저는 또한 비소스 제어 영역에서 언급된 사항들을 추가하고 싶습니다.작업 항목 추적, 보고 및 빌드 자동화(랩 관리 포함)와 같은 기능은 중앙 최고의 저장소를 통해 큰 이점을 얻을 수 있습니다.순수 분산 모델을 사용할 때는 노드 중 하나를 선행 모델로 만들지 않는 한(따라서 덜 분산된 모델로 되돌리지 않는 한) 이러한 작업이 훨씬 더 어려워집니다.
TFS 11과 함께 제공되는 TFS Basic을 사용하면 TFS 12+ 시대에 로컬 TFS 기본을 중앙 TFS에 동기화할 수 있는 분산 TFS를 기대할 수 있습니다.저는 그것에 대한 저의 투표를 사용자 목소리로 적겠습니다!
TFS의 주요 차이점은 TFS가 TFS를 '지원'하기 위해 솔루션에 추가하는 모든 부속 파일(.vsscc)입니다. 최근에는 이러한 파일이 잘못된 분기에 매핑되는 문제가 있었습니다. 이로 인해 몇 가지 흥미로운 디버깅이 발생했습니다.
언급URL : https://stackoverflow.com/questions/4415127/git-vs-team-foundation-server
'itsource' 카테고리의 다른 글
| Angular 2에서 경로 간 이동 시 로딩 화면 표시 (0) | 2023.05.22 |
|---|---|
| ES6 모듈을 사용하는 경우 Node.js의 __dirname에 대한 대안 (0) | 2023.05.22 |
| --save와 --save-dev의 차이점은 무엇입니까? (0) | 2023.05.22 |
| Mongo에서 컬렉션의 인덱스를 표시하려면 어떻게 해야 합니까? (0) | 2023.05.22 |
| MySQL과 같은 targzip mongo 덤프 (0) | 2023.05.22 |