TFS 관리자 체크인

Question

는 TFS에서 "미리 체크인을"할 수 있습니까?

내 시나리오는 내가이 소스 제어하기 위해 최선을 다하고 있습니다 전에 코드 감사는 코드 감사를 수행 할 수 있습니다. 이를 통해 회사의 내부 관행에서 코드 품질 및 아키텍처 확인 준수를 보장합니다. 프로그래머 체크 - 인 그/그녀의 코드는, 알림이 자동으로 코드 감사 및 규정 준수에 대한 그 감사 검사에 전송하고 소스 제어에 커밋 할 때처럼

.

감사합니다. TFS에서

Answer 1

는 Shelveset의 개념이있다. 이것은 소스 컨트롤에 아직 적용되지 않은 체크인입니다 (다소 부드러운 체크 인). 팀의 다른 회원도 Shelveset에 액세스 할 수 있습니다.

는 TFS 2012, 그들은이 Shelveset 시스템을 기반으로 코드 리뷰 시스템을 도입했다.

여기

더 많은 정보 : http://channel9.msdn.com/Series/Visual-Studio-2012-Premium-and-Ultimate-Overview/Visual-Studio-Ultimate-2012-Using-Code-Review-to-Improve-Quality

선반 (here @TJB에서 촬영) 많은 용도가

1. 상황 전환 : 다른 높은 우선 순위로 전환 할 수 있도록 현재 작업에 작업을 저장 태스크. 상사가 뛰어 들어서 "아! 버그 버그 버그!"라고 말하면서 자신의 사업에 집중하면서 새로운 기능을 개발하고 있다고 가정 해보십시오. 기능에 대한 현재 변경 사항을 삭제하고 버그를 수정해야합니다. 기능에 대한 작업을 중단하고 버그를 수정 한 다음 나중에 돌아와 변경 사항을 처리하지 않을 수 있습니다.
2. 공유 변경 집합 : 코드를 변경하지 않고 코드 집합을 공유하려는 경우 다른 사람이 해당 코드를 쉘빙하여 쉽게 액세스 할 수 있습니다. 이것은 불완전한 작업을 다른 사람 (불쌍한 사람)에게 건네 주거나 어떤 종류의 테스트 코드가 있으면 다른 사람이 실행해야한다는 것을 결코 확인하지 못했을 때 사용할 수 있습니다. h/t를 리뷰에 사용하는 것에 대한 다른 응답에 대해서는 매우 좋은 생각입니다.
3. 진행 상황 저장 : 복잡한 기능을 작업하는 동안 진행 상황을 저장하려는 '좋은 시점'에있을 수 있습니다. 이는 코드를 저장하기에 이상적인 시간입니다. 렌더링 버그를 수정하기 위해 일부 CSS/HTML을 해킹한다고 가정 해 봅시다. 일반적으로 올바른 모양이 될 때까지 생각할 수있는 모든 kludge를 반복합니다. 그러나 일단 올바른 것으로 확인되면 마크 업을 정리하고 다시 시도하여 다른 사람이 체크인 전에 수행 한 작업을 이해할 수있게 할 수 있습니다.이 경우 모든 것이 올바르게 렌더링되면 코드를 선반에 쌓을 수 있습니다 , 당신은 당신이 우연히 그것을 다시 깨면, 당신은 항상 되돌아 가서 당신의 changeset을 얻을 수 있다는 것을 알고 당신의 마크 업을 자유롭게 가서 리팩터링 할 수 있습니다.