TFS 소스 코드 관리 기능 (1) - Changeset
TFS의 Check In/Out 만을 기계적으로 하는 분들이 ^^ 있으신 듯해서, TFS의 소스 코드 관리에 대한 다양한 기능들을 잠시 알아볼까 합니다.
실습을 위해 다음과 같이 설정된 팀 프로젝트와 솔루션이 생성되어져 있고 이를 바탕으로 하나씩 살을 붙여가면서 설명해 보겠습니다.
파일 단위 복원
설정된 TestLibrary 프로젝트에 다음과 같은 변경을 합니다.
- Class1.cs 체크 아웃 및 편집
- MyClass.cs 파일 추가
- 1번 ~ 2번에 대한 체크인
위의 변경으로 인해 추가된 Changeset 번호는 52입니다. (Changeset 번호는 "팀 프로젝트" 단위가 아닌, "팀 프로젝트 컬렉션" 단위로 증가합니다. 즉, 이미 다른 팀 프로젝트의 체크인에서 번호가 증가했기 때문에 이번에는 그 이후의 번호를 할당받은 것입니다.)
이런 상태에서 다음과 같은 상황으로 진행될 수 있습니다.
- 다시 Class1.cs 파일을 체크아웃하고 수정하고 있는데, 코딩이 원하는 방향으로 진행되지 않아서 다시 지난번 체크인 했던 시점으로 소스 코드를 돌리고 싶은 경우
- Class1.cs 파일을 이후 변경/체크인 하고 나서 배포를 했는데, 그 버전의 Class1.cs 파일에 버그가 있다는 것이 밝혀졌으나, 고칠 시간은 없고 일단 이전 버전으로 빨리 돌려서 배포해야 하는 경우
2가지 경우 모두, 이전에 마지막으로 "체크인"했던 시점의 파일을 원하게 되는데요.
이를 해결하기 위해서, 솔루션 탐색기(또는 소스 컨트롤 탐색기)에서 오른쪽 마우스 버튼을 눌러서 "View History" 또는 "Get Specific Version..." 또는 "Get Latest Version" 등을 이용해서 해당 파일의 이전 체크인 시점을 선택하고 복원을 할 수 있습니다. 아마도 소스 컨트롤을 사용하면서 가장 빈번하게 사용하는 기능중의 하나일 것입니다.
Changeset 단위 복원
그런데, 파일 하나만이 아니고 체크인 했던 Changeset 전체를 제거하고 싶은 경우가 있습니다. 사실 개발하다 보면 이런 경우가 빈번하게 발생합니다. 왜냐하면 기능 하나를 구현하기 위해서 파일 하나를 수정하는 경우보다는 여러 개의 소스 코드를 같이 수정하게 되고, 이런 묶음을 같이 check-in 하기 때문입니다. (바로 이런 묶음 단위를 Changeset이라고 합니다.)
예제에서 설명해 보면, "Class1.cs" 파일과 "MyClass.cs" 파일을 한꺼번에 이전 시점으로 돌리고 싶은 경우가 이에 해당합니다. 즉, 원복을 하면 Class1.cs 파일은 편집이전의 상태로 돌아가고 "MyClass.cs" 파일은 프로젝트에서 삭제될 것입니다.
이런 때는, 지금까지 솔루션에 가했던 모든 Changeset을 확인하는 것이 도움이 되는데요. 일단, 솔루션 탐색기에서 "솔루션" 노드를 마우스 오른쪽 버튼을 클릭하고 아래와 같이 "View History"를 선택합니다.
위와 같이 하고 나면, "TestSolution.sln" 파일만 포함하는 Changeset 목록이 나옵니다.
이 때문에 전체 Changeset 목록을 확인하려면 다음과 같이 직접 "Source location"에서 "TestSolution.sln"을 없애고 "새로 고침"을 해주시면 됩니다.
(또는 소스 컨트롤 탐색기에서 해당 팀 프로젝트 노드를 클릭하고 "View History"를 실행하면 위와 같은 결과를 동일하게 볼 수 있습니다.)
자, 이 상태에서 "Changeset 51" 번을 선택하고 "Get This Version"을 실행해 주면 "Class1.cs" 파일은 편집 이전의 상태로 돌아가고, "MyClass1.cs" 파일은 프로젝트로부터 제거됩니다.
(2018-07-21: 아래의 기능은 이제 "Rollback..." 메뉴로 TFS에서 제공됩니다.)
그런데, "Get This Version"만 한 다음, Class1.cs (또는 이외의 솔루션/프로젝트) 파일을 선택하고 "최신 버전 가져오기"를 실행하면 Changeset 52번에서 적용한 내용으로 바뀌게 됩니다. 즉, 여전히 최신 버전은 Changeset 52번이고, 자신의 PC에만 원복한 것일 뿐이어서 다른 개발자들에게는 여전히 Changeset 52번으로 유지됩니다.
이유가 있어서 원복한 것인데, 이러면 곤란하죠.
그래서, 현재 상태를 최신 버전으로 만들어야 하는 데 이 과정이 다소 복잡합니다. ("Make this latest version"이라는 식의 메뉴가 있다면 좋을 텐데! ^^)
우선, "솔루션 탐색기"에서 해당 솔루션 이름을 선택하고 "Check Out for Edit" 메뉴를 실행해 주어서 전체를 체크아웃 시킵니다. (구체적으로 어떤 파일을 변경했는지 일일이 추적하는 것이 어려울 때(또는 귀찮을 때)를 기준으로 설명하는 것입니다.)
이때, 주의할 것은 다음과 같이 체크아웃 상자에서 "잠금 유형"을 "Check Out - Prevent other users from checking out and checking in"으로 설정해 주는 것이 좋습니다. (이유는 나중에 나옵니다.)
그다음 곧바로 다시 "체크인"을 하시면 다음과 같이 충돌을 감지해서 체크인을 할 수 없다고 나옵니다.
"확인" 버튼을 누르시면 아래와 같이 별도의 "Pending Changes" 창에 충돌된 목록이 나옵니다.
위의 화면에서 항목의 왼쪽에 있는 "아래로 향한 화살표"를 클릭하면 다음과 같이 상세 옵션 화면이 펼쳐집니다. 여기서 "Keep Local Version"을 선택해야 되고, 나머지 목록들의 파일들도 모두 동일하게 작업해 주시면 됩니다.
만약 이 과정에서 "잠금 유형"을 "Check Out - Prevent other users from checking out and checking in"으로 해주지 않았다면 누군가가 Changeset 52번으로 되어 있던 파일을 수정할 수 있고, 이렇게 되면 "Merge Changes In Merge Tool" 버튼으로 일일이 확인하면서 작업을 해주어야 합니다.
현실적으로 다른 사람이 작성한 소스를 함께 병합하는 것은 여간 귀찮은 작업이 아니기 때문에 차라리 애초부터 이를 방지하기 위해 잠금유형을 강하게 해서 체크아웃하시는 것이 좋습니다. (물론, 누군가가 체크아웃을 이미 했다면 그 개발자에게 이유를 설명하고 조치를 취하는 것이 편합니다.)
그렇게 모두 충돌을 해결한 다음 다시 Check-In을 시도하면 현재 버전으로 서버에 새롭게 Changeset이 53번으로 추가됩니다. 물론, 다른 개발자들도 최신 버전 가져오기를 하면 변경되기 이전의 Class1.cs 파일과 MyClass.cs 파일이 제거된 프로젝트로 돌아가게 됩니다.
아래는 최종 결과입니다.
일단, 이 정도로 Changeset에 대한 개념 및 활용은 설명이 끝난 것 같습니다. 다음은,
Shelveset에 대해서 알아보겠습니다.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]