Git : 분산형 버전 관리 (Distributed Version Control)
(분산) 버전 관리 시스템
먼저 버전 관리란 다들 경험해 본적 있을 것이다. 특히나 원래 전공이 건축공학과인데, 과제하면서 3D Revit 파일을 다루다 보면 용량이 적게 50Mb, 높게는 300Mb 까지 본 적 있다. 일반적인 텍스트 파일이 아니라 이미지와 랜더링된 객체를 이루고 있기 때문에 용량이 기본적으로 높은 편인데, Develop을 하다보면 파일이 깨지는 경우가 간혹 있거나 Ctrl + Z가 먹히지 않아 뒤로가기가 되지 않는 경우가 종종 있다. 이 때문에 사이사이에 업데이트된 요소를 갱신하기 위해 꾸준히 저장을 눌러주는 것과 동일하다. 다행히 자동으로 날짜 + 저장시간을 저장이름에 넣음으로서 내가 언제까지 하던 파일인지 롤백하기 쉽다. 다만 제목을 최종 / 최최종 / 최최최종 / 이제그만 최종 / 이제 더이상 안함 최종 등등 생각나는 대로 적었던 기억도 난다.
개인적인 이야기를 하다보니 길어졌는데, 다들 이런 경험들이 있을 것이다. 사소하게는 과제부터, 적어도 자기소개서 정도는 다루었을텐데, 중간중간 저장을 해두는 것을 알 것이다. 다만, 한 파일에 변화된 기록까지 한번에 저장하는 사람들이 대부분일 것이다.
따라서 버전 관리란 변화를 기록하고 추적하는 것이다. 다만 위에서 해온 저장들은 변경사항이 아닌 부분까지 저장하여 효율이 떨어진다. 극단적인 예시로는 졸업작품을 진행하면서 3D프로그램을 300MB 라고 했는데, 10번만 저장해도 3GB가 되어버리는 것을 알 수 있다. 과연 바뀌지 않은 부분도 저장해야만 할까?
분산 (버전 관리 시스템)
버전 관리 시스템에는 중앙, 분산으로 2가지 종류가 있다.
그림으로 보면 확연한 차이를 볼 수 있다. 중앙 집중식 버전 관리 시스템은 버전을 중앙 서버에 저장되며, 파일을 가져오는 식, 재 업로드 하는 식이다. 반면 분산식은 굉장히 복잡해 보이지만 데이터 관리 입장에서는 버전을 여러 개의 복제된 저장소에 저장 및 관리하는 것이다.
우리나라에서는 중앙 집중식 버전 시스템의 불편함을 모두 겪었는데, 2022년 10월 15일 경기도 성남시 분당에 위치한 에스케이씨앤씨(SK C&C) 데이터센터가 화재가 나면서 카카오톡이 먹통이 된 경험은 모두 있을 것이다. 꽤나 긴 시간동안 정상화(최대 6시간)가 되지 않아 답답했던 적이 있었는데, 카카오톡은 중앙 집중식 관리를 하고 있었고 하필 데이터 센터가 화재가 났기 때문에 이용자 모두 영향이 갔던 것이다.
만약 분산식을 했다면 메인 센터가 화재가 났더라도 백업이 잘 되어있기 때문에 정상화 까지의 시간도 짧았을 것이다. 이 예시로 중앙 서버 관리는 단점을 확실하게 알 수 있다.
분산식 버전 관리 시스템의 장점
- 중앙 서버에 의존하지 않아도 동시작업을 진행 할 수 있다 (개발자들 간의 충돌 감소 및 효율성 증가)
- 중앙 서버의 장애 또는 사고에 대비해 백업을 빠르게 진행할 수 있다
- 인터넷에 연결되지 않은 환경에서 변경 이력과 코드를 개인 로컬 저장소에 기록후에 추후 중앙 서버 동기화가 가능하다
GIT (분산 버전 관리 시스템)
코드의 버전(히스토리)를 관리하고 개발되어 온 과정을 파악할 수 있으며 이전 버전과 변경 사항을 비교할 수 있다
개발자의 입장에서 코드의 '변경 이력'을 기록하고 '협업'을 원활하게 하는 도구
Working Directory : 현 컴퓨터로 작업중인 저장소를 의미하며 파일들이 위치하는 영역
Staging Area : Working Directory에서 변경된 파일 중 선택적으로 추가하거나 제외 할 수 있는 중간 준비 영역 (주로 가상)
Repository : 버전(commit) 이력과 파일들이 영구적으로 저장되는 영역. 모든 버전(commit)과 변경 이력이 기록되어 있음
Commit
사전적 의미는 약속, 서약 등이 나오지만 소프트웨어에서의 commit은 코드 변경 사항을 저장하고 고정하는 것을 의미한다. 마치 사진 찍듯이 기록을 하는 것과 유사하여 'snapshot'이라고도 한다. 개인 취미로 카메라 촬영이 있는데, 여기서 보니 또 반갑다.