안녕하세요 가야태자 @talkit 입니다.

오늘은 앞에서 준비 과정중에 있던 SVN 사용하기를 실제로 해보겠습니다.

오늘을 위해서 SVN 호스팅 서버에 가입하고, TortoiseSVN도 설치를 진행 했습니다.

SVN을 위해서 알아야할 용어

우선 저장소에 연겨하기 전에 용어를 좀 살펴 보겠습니다.

우선 기본적으로

저장소 또는 리파지토리, 레포지토리 등은 궁극적으로 저장소를 말 합니다.

저희가 생성한 소스의 버전들이 들어갈 저장소가 리파지토리, 레포지토리가 됩니다.

저장소에 trunk, tags, branch 라는 하위 폴더를 가지거나 안가지게 할 수 있습니다.

trunk는 주 버전 저장소라고 부릅니다.

branch는 가지 저장소 입니다.

tags는 특정 포인트의 저장소라고 하겠습니다.

trunk, tags, branch

trunk는 메인 버전을 저장하는 곳이고,

솔루션을 만들어서 팔고 있는데

A사, B사 C사에서 커스트마이징 해달라고 한 버전이 있으면 해당 버전을 branch로 즉 지점으로 만들어서 저장하고 발전시켜 나갑니다.

tags는 주로 유지보수를 위해서 많이 사용합니다.

1.0 버전, 2.0버전, 3.0 버전 이런식으로 특정 버전의 태그를 만들어두고 해당 태그를 이용해서 유지 보수 합니다.

솔루션을 여러회사에 파는 개발사 같은 경우에는 브런치와 tags가 다 만들어 질 수 있습니다.

솔루션을 클라우드로 서비스하는 경우에는 tags가 주로 만들어 집니다.

정리

리포지토리, 레파지토리, 저장소

소스의 버전들이 저장되는 저장소를 말 합니다.

trunk - 주요 버전 저장소

메인 버전을 관리하는 저장소 입니다.

branches - 지점 버전 저장소

솔루션이 여러곳에 납품되고 해당 소스가 일부 다를 경우 branches를 이용해서 관리할 수 있습니다.

tags - 특정일이나 특정 버전 저장소

어떤 회사는 매달 1번씩 버전을 업그레이드 한다면, 태그를 일자로 찍을 수 있습니다.

버전이 올라갈때마다 해당 버전의 유지보수를 위해서 버전별로 태그를 찍을 수도 있습니다.

branch나 tag는 왜 쓰는가?

trunk만으로는 빠른 유지보수가 불가능 합니다.

회사의 메인 소프트웨어는 개발자들에 의해서 계속 발전하지만, 예를 들어 1월 1일에 고객에게 보여 줬습니다.

그런데 다른 요구사항에 의해서 2월 1일에 다시 보자고 합니다. ^^

branch나 tag를 안찍고 넘어갔다고 해보겠습니다.

고객이 변심해서 1월 1일 버전으로 변경해달라고하면?

끔찍합니다. 1월 1일의 소스 버전으로 trunk를 revert 해야 하기 때문에 T.T 이후 소스는 백업 해두고 잃어버릴 것인가가 문제 겠지요.

하지만, 1월 1일 기준으로 branch나 tag를 찍어 두었다면,

메인 trunk는 그대로 가고 해당 고객사는 1월1일에 찍어둔 버전을 이용해서 유지보수하면 됩니다.

물론 2월 1일에도 찍어 줘야 하겠지요.

버전관리 측면에서 알아야할 용어들

앞에서 말씀 드린 내용은 저장소 측면에서 알아야할 용어 들입니다.

아래는 버전 관리 측면에서의 내용들입니다.

Share/CheckIn - 공유

메인 개발자가 제일 처음에 다른 개발자들을 위해서 버전관리 소프트웨어에 공유하는 것을 CheckIn이라고 합니다.

프로젝트에서 한번 발생 합니다.

CheckOut - 가져오기

CheckOut은 메인 개발자가 공유 해 놓은 프로젝트의 소스코드를 메인 개발자 또는 다른 개발자의 개발 툴에 내려 받는 것을 CheckOut이라고 합니다.

이것은 뭐 장소가 변경된다던지, 개발자가 추가된다던지 하면 계속 일어나는 작업입니다.

Update

업데이트는 개발 과정에서 매우 중요한 과정입니다.
다른 개발자와 소소를 동기화 하는 과정입니다.

공통 소스의 경우는 수시로 공통 개발자와의 통신을 통해서 Update를 해야하고 지속적인 통합을 위해서 다른 개발자의 소스코드도 최고 하루에 한번은 업데이트를 하는 것을 예의로 합니다.

저는 AA 또는 PM으로 일을 할때 매일 아침에 한번은 무조건 Update부터 하고 작업하라고 이야기 합니다. ^^

Commit

커밋도 개발과정에서 매우 중요한 과정입니다.
이것 또한 다른 개발자와 소스를 동기화 하는 과정입니다.

자기가 개발한 소스코드를 버전관리 저장소에 올리는 작업을 Commit이라고 합니다.
이때 보통 저는 주석(Comment)을 잘 작성하라고 합니다.

추후에 자기 자신이 이때 뭘 했는지 알기도 쉽고 옆에 다른 개발자가 알기 쉽도록 말이죠.

Merge

머지는 update/commit 과정에서 거의 자동으로 이루어 집니다.

SVN은 라인단위의 비교툴을 이용하고 Merge를 진행하는데 같은 라인만 수정하지 않으면, 머지를 잘해 줍니다.

반대로 이야기하면 개발자 둘이 같은 라인을 수정하면 충돌이일어납니다.

Kiss라고 해서 뽀뽀마크가 보통은 보입니다.

이때 해결 방법은 ^^ 보통은 선임 개발자가 강제로 머지를 하고 후임 개발자가 다시 커밋을 하는 방법으로 이루어 집니다.

하지만, 제일 좋은 것을 두분 중에 코드가 긴 친구가 먼저 강제로 머지하고, 짧은 분이 다시 커밋 하는 방법을 저는 권장 합니다.

Override Update

위에서 설명드린 내용 중에 강제로 업데이트 하는 겁니다.

그래서 제 로컬에 있는 소스코드가 버전 저장소에 있는 소스코드로 바뀝니다.

Override Commit

오버라이드 업데이트와 반대 개념입니다.

저장소에 있는 코드가 제 로컬에 있는 코드로 강제로 바뀝니다. ^^

Revert

오버라이드 업데이트와 비슷한데, 오버라이드 업데이트는 최신 버전만 됩니다. ^^

그런데, Revert는 원하는 버전으로 내 로컬에 있는 소스코드와 원격지에 있는 소스코드를 변경할 수 있습니다.

결론

오늘은 원래는 저장소 연결하려고 했는데 용어 설명이 우선 되어야할 것 같아서 용어를 설명 드렸습니다.

다음 글에서 진짜로 저장소와 내 컴퓨터를 연결 해보겠습니다. ^^

감사합니다.

Posted through the ECblog app (https://blog.etain.club)