우리는 릴리스주기에 여러 개의 TFS 분기를 유지합니다. 현재의 프로세스는 사용자 스토리가 완료되면 WIP 브랜치에서 테스트 브랜치로 변경 세트를 체리 선택하는 것입니다.git-tf가 원격 분기를 병합 할 수 있습니까? 체리 따기는 어떨까요?
git-tf가 다중 원격 브랜치와 함께이 방법으로 작업 할 수 있는지, 그리고 새 코드와 같은 코드를 병합으로 검사하는지 검사 할 수 있는지 궁금합니다.
가 여기에 대해 논의했다 :
Merge two TFS branches with git tfs
가와가 자식-TFS 직접 VS를 사용하는 것이 다른 사람들과 좋은 연주하지 않을 것이라고 언급했다. 누구든지 git-tf를 사용하는지 알고 있습니까?
이 시점에서 git-tf은 git 분기가있는 TFS 분기를 나타내지 않으며 어느 방향 으로든 병합을 변환하지 않습니다. 즉 병합을 검사하지 않으며 TFS 병합 결과를 다음과 같이 표시합니다. 자식 병합. 이것은 두 가지 아키텍처의 병합간에 근본적인 차이점이 있기 때문에 일종의 중요하지 않은 문제입니다. 자식이 합병으로
는 TFS는 병합 : 자식에
, 당신은 두 개의 커밋을 병합하고 결과 커밋을 끝낼. TFS는 병합 원본과 대상 변경 집합을 선택한다는 점에서 비슷하지만 병합 원본은 변경 집합 일 필요는 없습니다. 레이블, 작업 공간 버전, 날짜 등을 기준으로 병합 할 수 있습니다. 따라서 여러 다른 변경 사항에서 여러 파일을 병합 할 수 있습니다. 이것은 쉽게 풀 수있는 문제입니다 (궁극적으로, 나는 그것을 미친 문어 병합으로 표현할 것입니다).
더 어려운 문제는 TFS 분기를 기반으로 git 분기를 만드는 것입니다. 이것은 설정 문제입니다 - 즉, 어떤 지점을 원하십니까? 모두들? 그들 중 일부? 대답이 "모두"라면 초기 복제를 할 때 쉽게 설정할 수 있습니다. 하지만 저에게는 처음 몇 시간에 수백 개의 지점과 비용이 들었습니다. 대답이 "그 중 일부"라면 복제를 할 때 모두 지정해야합니다. 그렇지 않으면 나중에 git 기록을 불쾌한 방식으로 다시 작성하게됩니다. TFS가 합병으로
자식은 병합 : 자식에
, 가지 종류의 임시 있습니다. 실제로는 트리의 노드에 대한 포인터입니다 ... "1b4caf이 한 번 지점 branch에 있었음을 나타내는 수명이 길지 않은 상태입니다." 당신이 어떤 자식 브랜치를 가지고 있다고 상상해보십시오. 을 가리키는 master과 을 가리키는 다른 자식 브랜치 test을 상상해보십시오. 자식에서 test을 main에 병합합니다. 이 시점에서 문제가되지 않습니다. main의 HEAD 커밋의 부모는 test의 HEAD입니다. 그러나 test 지점에서 일을 변경하기 시작하면 신속하게 결정하기가 어려워 질 수 있습니다.
더 나아가 지금 git-tf은 단일 git 브랜치를 TFS 서버 경로에 매핑합니다. 병합 체크 인의 경우 여러 분기를 한 번에 확인해야합니다. master으로 몇 가지 커밋을 만들고 test으로 커밋 한 다음 HEAD을 병합했다고 가정 해 보겠습니다. 이제 각 TFS 분기에 대한 커밋을 여러 번 확인한 다음 병합을 수행해야합니다. 이것은 반드시 어려운 것은 아니지만, 현재 git-tf 작품과 매우 근본적인 차이가 있습니다.
이것은 결코 불가능한 문제는 아니지만 약간의 영리한 엔지니어링과 영리한 테스트가 필요합니다. 그러나 그것은 아직 없습니다.