TFS 소스 코드 관리 기능 (2) - Shelveset
Shelve라는 단어가 다소 낯설기도 하고, 실제로 쓰는 경우가 많지 않아서 기능 자체에 대해서 모르시는 분들도 계신데요. 사실 개념은 무척 간단합니다.
가상 시나리오를 설정해 보면,
- 소스코드를 변경하고 있는데, 다시 원복해야 하는 상황에서 지금까지 변경한 소스코드를 별도로 보관하고 싶은 경우
- 기능 추가를 위해 소스코드를 한창 변경하고 있는데, 급하게 버그 패치건이 들어와서 현재 작업을 보관하고 싶은 경우
이 외에도 Shelve를 코드 리뷰 용도로 활용하고 있다고 웹에서 읽은 적이 있습니다. (국내에서 이런 사례가 있다고는 들어본 적이 없습니다.)
즉, 개발자들이 변경한 코드를 곧바로 Check-in을 못하게 하는 대신 Shelveset으로 남기도록 합니다. 이후 관리자(또는 팀 리뷰 인력)에 의해서 해당 개발자가 Shelving 해놓은 "파일 목록"을 얻어내서 검사(예를 들어, 지난 버전과의 변경 사항 확인)를 진행하는 것입니다. 그렇게 해서 체크인할만한 수준의 코드라고 확정이 되면 그제서야 해당 Shelveset을 체크인 하도록 하는 것입니다. (실제로 이렇게 진행되는 프로젝트가 있다면 제품의 품질은 당연히 수준급이 될 수 있겠지요.)
지난 시간에 했던 예제 팀 프로젝트를 그대로 이어보겠습니다.
Changeset 53번에서 Class1.cs 파일을 변경하고, TestClass.cs 파일을 추가해서 다음과 같은 상태로 되었다고 가정하고.
위의 상태에서 갑자기 이전의 코드로 빌드된 배포버전에서 치명적인 버그가 보고되었다고 가정해 보겠습니다. 개발자는 판단을 해야 합니다. 구현하고 있던 기능을 마저 구현하고 버그를 수정하고 배포할 것인가? 구현하던 코드를 버리고(이전의 Changeset으로 원복하고) 버그를 수정하고 배포할 것인가? 마지막으로 구현하던 코드를 잠시 형상관리 서버에 별도 보관(Shelve)해 두고 이전 체크인 상태로 원복 후 버그를 수정할 것인가?
당연히 여기서는 Shelve를 선택한다고 보고.
솔루션 탐색기에서 마우스 오른쪽 버튼을 클릭해서 "Shelve Pending Changes..." 메뉴를 실행합니다.
다음과 같이 체크인과 비슷한 창이 열리는데, 특이하게 상단에 "Shelveset name" 입력란이 하나 더 있습니다.
또한, 하단에 "Preserve pending changes locally" 체크 박스를 해제하면 자동적으로 해당 파일들을 변경 이전의 Changeset으로 원복시켜 줍니다.
예상할 수 있듯이, 이러한 과정을 거쳐서 결국 Changeset 53번 소스 코드로 돌아가게 됩니다. 그런 다음 버그를 수정하고 체크인을 하면 이제 Changeset 54번이 최신 버전이 됩니다.
자, 이제 버그도 수정했으니, 다시 이전에 작업했던 코드를 이어서 작업하고 싶을 것입니다. 이전 단계에서 Shelving 해놓은 코드를 불러와야 하는데요. 해당 메뉴는 솔루션 탐색기에는 없고, "File" / "Source Control" / "Unshelve Pending Changes..." 경로로 선택할 수 있습니다. 그러면, 다음과 같이 이전에 보관해 두었던 Shelveset 목록이 나오고,
"Details..." 버튼을 누르면 선택된 Shelveset에 포함된 파일 목록을 얻을 수 있고, 특정 파일을 선택해서 지난 버전과 비교하는 것이 가능합니다.
"Delete" 버튼은 당연히 선택된 Shelveset을 삭제하는 것이고.
"Unshelve" 버튼은 보관되어 있던 것을 다시 현재의 프로젝트에 반영하게 됩니다.
여기서 유의할 사항이 하나 있는데.
위에서 설명한 시나리오에서는 Class1.cs, TestClass.cs 파일을 Shelve했고 버그 수정으로 Class1.cs 파일이 변경되고 다시 Unshelve 해서 Class1.cs, TestClass.cs 파일을 이전 버전으로 복원한 것입니다.
즉, 이렇게 되면 버그수정으로 인한 변경사항이 현재 로컬의 소스 파일에는 반영되어 있지 않은 것입니다.
그게 말이 되냐고요? ^^
흥분하지 마시고 ^^ 좀 더 지켜봐주세요.
물론, 말이 안됩니다. 이 때문에 그냥 이 단계에서 버그 수정 코드를 수작업으로 반영시켜주어도 되지만, 새로운 기능을 그냥 묵묵히 구현하셔도 상관없습니다.
왜냐하면, 그렇게 한 후 체크인을 하게 되면 그 시점에 다음과 같이 충돌로 인해 소스 코드를 체크인할 수 없다고 나온 후,
"확인" 버튼을 누르면 예의 그 "Pending Changes - Conflicts" 창을 열어줍니다. (
지난 Changeset 이야기에서 봤었죠.)
(이 예제에서는 충돌이 발생한 파일이 "Class1.cs"뿐이기 때문에 위의 목록에 항목이 하나 있습니다.)
만약, 버그 수정 코드를 수작업으로 로컬에 있는 Class1.cs 파일에 반영시켜주었다면 이 단계에서 그냥 "Keep Local Version" 버튼을 눌러서 진행하시면 됩니다.
당연히 "Take Server Version"을 눌렀다가는 "Changeset 54"의 Class1.cs 파일이 로컬에 덮어써지게 되고.
위의 이미지에서는 활성화되어 있지 않은데 만약 활성화가 되어 있다면 그냥 "AutoMerge" 버튼을 누르시면 자동으로 병합됩니다. (가끔, 자동병합을 믿을 수 없다고 무조건 수작업으로 하시는 분이 계신데... 이 단계에서 확신을 드리고 싶군요. ^^ 무조건 자동병합을 믿으셔도 좋습니다. Visual Studio는 단순 유형에 대해서 자동 병합할 뿐 복잡한 경우에서까지 스스로 추론하는 등의 무리수를 두지는 않습니다. 바로 그런 경우에 위와 같이 "AutoMerge"를 스스로 포기하는 것입니다.)
하지만, 위와 같이 비활성화되어 있다는 것은 프로그램적으로 병합할 수 없는 충돌이 있기 때문이어서, 이 경우에는 개발자가 직접 병합을 해야 합니다. 대신 "Merge Changes In Merge Tool" 버튼을 누르셔서 하시면 아주 편하게 진행하실 수 있습니다. 아래는 그 예제입니다.
화면이 상단 2개, 하단 1개로 이뤄져 있는데, 상단의 입체감있게 튀어나온 영역을 클릭하면 하단의 소스 코드에 반영이 됩니다. 또는 하단 영역은 직접 키 입력이 가능한 에디트 윈도우이기 때문에 거기서 수작업으로 타이핑 해서 수정하는 것도 가능합니다.
게다가 틀린 부분만을 "Previous Change", "Next Change" 버튼을 이용해서 편리하게 이동할 수 있어서 (이전에 버그수정해서) 변경된 코드 부분을 빠뜨리지 않고 작업하는 것이 가능합니다.
어쨌든, 적절하게 병합해서 "확인" 버튼을 누르시고. 충돌이 발생한 나머지 파일들도 있다면 동일하게 병합한 후 다시 체크인을 해주시면 됩니다. 그렇게 해서 다음과 같이 현재 작업한 기준으로 "Changeset 55"번까지 오게 되었습니다.
이 정도면, Shelve 기능에 대한 거부감이 줄어드셨겠죠! ^^
Shelve 기능은 꼭 위와 같이 형상관리 측면에서만 사용하는 용도를 넘어서, 보관하고 싶은 코드 조각들이 발생했을 때에도 그냥 임의로 사용하셔도 무방합니다. 사실, 방대한 changeset 코드 양에 비하면 여러분들이 아무리 많이 shelving해 놓아도 그 양은 거의 미미한 수준이라고 할 수 있기 때문에 전혀 부담갖지 않으셔도 됩니다.
그럼... 이 정도로 Shelving은 접어두고, ^^ 다음에는 "Label" 기능을 알아봅니다.
[이 토픽에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]