20. 효과적인 버전 관리

모든 것은 변할 뿐, 사라지지 않는다.   - 오비디우스

 

버전 관리는 일련의 파일들의 여러 버전을 관리하는 체계다. 해당 파일들은 보통 소프트웨어 시스템의 소스 파일이다. 혹은 문서의 개정판들을 쉽게 관리하기 위한 용도이거나, 파일 시스템에 저장하는 또 다른 무엇일 수도 있다.

버전 관리의 이점

•         협업의 중심으로서 개발자들 간의 협력을 조율한다.

•         최신의 상태를 정의하고 게재한다.

•         프로젝트 내에서 이루어진 작업들의 기록을 유지하고, 각 배포 버전에 포함되어야 하는 정확한 콘텐츠들을 모아 둔다.

•         특정 기능을 구성하는 변경 사항을 확인하기 위해 파일들의 변경 내역을 추적할 수 있다.

•         작업에 대한 중추적 백업 도구로서의 역할을 한다.

•         개발자에게 안전망을 제공한다. 새로운 도전에 대한 두려움으로부터 이길 수 있게 해준다.

•         작업에 운율과 박자를 부여한다. ( 리듬감 있는 작업을 할 수 있게 도와 준다. )

•         하나의 코드베이스에서 동시에 여러 방향으로 개발을 수행하는 동안 서로의 작업이 꼬이지 않게 해준다.

•         작업을 되돌릴 수 있다. ( 작업 사항이 잘못된 것으로 판명된 경우, 작업 기록 중 그와 관련된 부분을 찾아 되돌릴 수 있게 해준다. )

 

사용하거나 잃거나

버전 관리의 가장 중요한 법칙은 적용하라 는 것이다. 프로젝트의 시작 시점부터 버전 관리를 적용하자. 예외는 없다.

소프트웨어는 본질적으로 안전하지 않다. 디스크상의 소스코드는 손짓 한 번으로도 너무 쉽게 ㅏ라지는 디지털 연기와 다를 바 없다. 버전 관리 도구를 사용하면 이런 문제를 해결할 수 있다. 적절하고 가벼운 버전 관리 도구를 통해 작고 빈번한 소스 체크인을 수행하면, 자신의 우둔함으로 인한 결과를 충분히 예방할 수 있다.

 

무엇이든 하나를 골라라

수년간 다양한 버전 관리 도구가 등장했다. 어떤 도구들은 유료이고 어떤 것들은 오픈 소스다. 라이센스, 가격, 편의성, 지원 플랫폼, 성숙도, 확장성, 기능이 서로 다르다.

가장 큰 차이점은 작동 방식이다. 전통적인 중앙 집중화 도구들은 모든 통신을 중앙 관리 서버를 통해 수행하고, 중앙 관리 서버에서 버전 관리 중인 모든 파일을 담고 있는 저장소를 관리한다. 간단한 방식이지만 그 어떤 작은 작업에서도 서버와의 통신이 필요하다.

그러나 가장 최근에 등장한 버전 관리 도구는 분산 방식, 즉 p2p 방식으로 각 개발 머신에 별도의 저장소를 두고 있다. 이를 통해 더 강력한 작업 흐름이 가능하고, 네트워크에 접속해 있지 앟더라도 저장소를 통해 작업할 수 있다.

수많은 버전 관리중 가장 최근에 각광 받고 있는 것은 Git 이다. 분산 버전 관리 도구를 사용하면 더욱 가용성 있는 작업 흐름이 가능한 만큼 쓸모가 많기 때문이다. 하지만 적절히 이용하려면 비용을 지불해야 한다. Git을 적절히 사용하기 위해서는 가파른 학습 곡선을 거쳐야 한다.

 

적절한 것 저장하기

개발자는 작업 과정에서 많은 파일을 직접 만들어낸다. 소스파일, 설정파일, 바이너리 자원, 빌드 스크립트 파일, 중간 빌드 파일, 객체 파일 바이트코드 파일, 컴파일된 실행파일 등 이렇게 많은 것들 중 어떤 것을 버전 관리 도구에 포함시켜야 할까?

1.     모든 것을 저장하자

소프트웨어를 다시 만들 수 있도록 필요한 모든 파일을 저장해야 한다. 바이너리든  소스파일이든 상관없다. 모든 파일을 버전 관리하자. 좋은 버전 관리 도구는 큰 바이너리 파일도 적절한 방식으로 처리할 수 있으므로, 바이너리 파일을 다루는 것에 대해 걱정할 필요는 없다.

알맞게 설정한 빌드 머신과 적절한 OS 및 컴파일 환경에서, 한 번의 간단한 체크아웃 만으로도 빌드 가능한 형태로 전체 파일들을 받을 수 있어야 한다.

2.     가능하면 적게 저장하자

혼란을 초래하고 쓸데 없이 용량을 늘리거나 방해가 되는 불필요한 것까지 포함해서는 안 된다. 저장소를 가능한 한 간결하게 유지하자.

-      IDE 설정 파일이나 캐시 파일을 저장하지 말자. 미리 컴파일된 헤더 파일이나 동적으로 생성된 코드 정보, ctags 파일, 사용자 설정 파일 등을 체크인 하지 말자.

-      자동 생성된 파일을 저장하지 말자. 빌드 절차의 결과물인 객체 파일, 라이브러리 파이르 애플리케이션 바이너리 파일을 체크인할 필요는 없다.

-      자동 생성된 파일을 체크인할 때도 있다 생성하기 어렵거나 생성하기까지 오랜 시간이 걸리는 경우에 한정된다.

-      프로젝트의 일부가 아닌 것들을 저장하지 말자. 개발 도구의 설치 파일이나 빌드 서버의 운영 체제 설치 파일 등

-      테스트 보고서나 버그 보고서를 체크인 하지 말자.

-      흥미로운 프로젝트 관련 이메일도 저장하지말자

-      개인적 설정을 저장하지 말자.

-      언젠가는 필요할 것이라 여겨지더라도 저장소에 저장하지 말자. 현재의 프로젝트 상태와 관련이 없다면 버전 관리 도구상에서 삭제해도 된다.

3.     소프트웨어 배포본 저장하기

배포본은 소스 파일과는 상관 없으므로 보통 별개의 배포본 저장소에 저장한다.

배포본들을 단순히 어딘가의 폴더에 저장하는 방식도 고려하자. 덜 동적인 파일 구조를 저장할 때는 버전 관리 도구가 그리 매력적이지 않다. 그때는 파일 저장 서버를 사용하는 편이 더 편리할 수 있다.

4.     저장소의 내부 배치

내부 배치에 대해 주의 깊게 생각하자. 디렉터리 구조가 명확해지도록 코드의 형태를 드러내자, 최상위 디렉터리에 도움이 되는 ‘read me’ 문서를 포함 시키자.

복제는 철저히 피해야한다. 코드에서 복제 때문에 버그가 생기듯이, 저장소에서 파일을 복제하는 경우에도 버그는 발생한다.

서드파티 파일을 주의 깊게 관리하자. 직접 만든 소스파일과 분리하여 관리하자. 명백히 표시된 위치에 두자. 이는 자신이 만든 파일과 햇갈리는 일 없이 변경 사항을 추적하기 위험이다.

적절하지 않은 파일은 무시하도록 설정해 두자.

 

버전 관리 도구를 잘 활용하자.

1.     원자적 커밋을 수행하자.

이해하기도, 적절성을 판별하기도 더 쉽다. 한꺼번에 체크인 하면 다양한 문제를 일으킨다.

-      코드에 발생하는 변경 사항을 추적하기 어렵다.

-      본인이 작업했던 체크인과 현재 작업 중인 체크인 사이에 다른 사람들에 의해 많은 변경이 이루어졌을 수 있다.

-      주변 환경이 변한다면 더 많은 충돌이 있을 수 있다.

원자적 커밋은 응집성 있고 일관되어 있어서 서로 연관된 변경 사항들을 하나의 단계로 나타낸다. 한 번에 두 가지 이상의 변경 사항을 다루는 체크인을 해서는 안 된다.

 

2.     적절한 메시지 보내기

커밋에 적절한 메시지를 포함시키자. 변경된 내용이 무엇인지를 표현하는 간결한 요약을 하나의 간결한 문장으로서 메시지의 첫 부분에 넣자. 그 다음 변경에 대한 이유를 작성하자.

메시지는 명확하고 간결하며 모호하지 않게, 좋은 코드를 작성할 때처럼 작성하자.

첫 문장에서 변경 사항을 요약하는 메시지를 작성하는 것을 목표로 하자. 자장소의 과거 기록을 검색하는 과정에서 큰 도움이 될 것이다.

3.     좋은 커밋을 고안하자

빌드를 깨뜨리지 말자, 코드를 체크인하기 전에 자장소에서 최신 버전을 체크아웃하고 통합한 뒤 테스트 해야 한다.모든 사람이 동의하지 않는 이상 어떤 파일이든 삭제하거나 이동시키지 말자.

편집기에서 줄마침 문자 때문에 혼란이 일어나지 않도록 하자.

 

브랜치 : 숲을 보기 위해 나무 보기

브랜치는 버전 관리 도구에서 근본적이고 중요한 기능이다.

각 작업 단위별로 코드베이스를 복제하여 사용할 수 있어서 서로 다른 기능에 대한 작업을 동시에 진행할 수 있다, 그 과정에서 상호 작업 간에 소스가 꼬이는 일이 없다. 하나의 작업을 완료한 후에는 각 브랜치를 주 작업 분기를 통합하고, 주 작업 분기에서 분기한 각각의 브랜치에 대해 동기화를 수행할 수 있다.

브랜치는 개인 작업을 위해 사용할 수 있고, 팀 협업을 위해서도 사용할 수 있으며, 배포 관리를 위해서도 사용할 수 있다.

브랜치는 여러 막강한 기능을 가지고 있으나 어떠한 상황에서든 적합한 도구는 아니다. 떄로는 다중으로 작업을 동시 진행하지 않는 편이 좋다. 주 작업 분기 내에서 단순히 기능을 켜고 끄는 접근 방식이 좋을 수도 있다.

 

코드의 고향

버전 관리되는 저장소는 코드의 고향이다.

큰 규모의 프로젝트들을 충분히 경험하다 보면, 어느 정도 복잡한 프로젝트의 소스 코드는 버전 관리 도구에 단순히 저장되기보다는 버전 관리 도구 안에서 통합된다는 것을 알 수 있다.

이러한 현상은 프로젝트와 그 주변 기반 즉 인프라가 성장하면서 나타난다. 코드가 유아기에서 청소년기로 성장함에 따라 빌드 스크립트와 배포 도구도 저장소에 더 깊이 통합된다.

버전 관리 도구 사이를 자주 옮겨다녀서는 안 된다. 저장소에 기록되는 리비전 기록은 가치 있기 때문이다. 이동이 가능하기는 하나, 대부분의 경우 잃는 것이 많고 복잡한절차를 거쳐야 한다. 이것이 프로젝트 초기에 적절한 버전 관리 도구를 선택해야 하는 핵심 이유이다.

 

버전 관리는 핵심적인 소프트웨어 개발 도구중 하나이다. 모든 프로그래머가 강력한 소소 코드 편집기를 다루는 지식을 반드시 가져야 하듯, 버전 관리 도구를 잘 다루는 방법도 반드시 알아야 한다.