목적
- 많은 사람들과 함께 개발을 하게되면 형상관리시스템은 필수이므로 형상관리시스템에 대해 학습하자.
- 현재 가장 각광받고있는 버전관리시스템이며 앞으로 사용하게 될 git에 대해 알아보자.
형상관리시스템
형상관리 시스템이란 소프트웨어의 변경사항을 체계적으로 추적하고 통제하는 것으로, 형상 관리는 일반적인 단순 버전관리 기반의 소프트웨어 운용을 좀 더 포괄적인 학술 분야의 형태로 넓히는 근간을 이야기한다. (출처. 위키피디아)
-- 참고로 여기서는 소프트웨어 측면에서만 형상관리시스템을 다룰것이다.
형상관리시스템은 왜 나오게 되었을까?
프로젝트를 진행하다보면 다양한 문제와 불편함에 직면하게 된다.
- 변경사항이 있을 때 마다 이유를 알고 있어야한다.
- 작업하던 파일을 날라가는경우
- 다양한 사람들과 작업을 하면 신경써야할게 많다.
- 최종.html, 진짜 최종.html, 진짜진짜이건정말최종.html...
- 변경했던것을 다시 되돌리고 작업해야 하는 경우등등
이를 예방하거나 해결하기 위해 형상관리시스템, 즉 버전관리시스템이 나오게 되었다.
버전관리시스템에는 크게 3가지가 있다. 이에 대해 알아보자.
LVCS - Local Version Control System
CVCS - Centralized Version Control System
DVCS - Distributed Version Control System
LVCS 로컬버전관리시스템
하나의 디렉토리에서 작업을 하던 중 발생한 문제로인해 개발되었다.
- 작업하던 디렉토리를 삭제
- 파일을 잘못 변경
위를 포함한 다양한 문제가 발생했을 때 로컬DB에 버전들이 저장되어 있어서 되돌릴 수 있다.
한계: 로컬DB이기에 멀리 떨어진 다른 작업자들과 함께 작업하기가 힘들다.
CVCS 중앙집중식버전관리시스템
프로젝트를 다른 개발자들과 함께 작업해야하는 경우에 생기는 문제들 때문에 개발되었다. 파일을 관리하는 서버가 별도로 있고 클라이언트가 중앙 서버에서 파일을 받아 사용한다.
관리자는 모든 클라이언트의 로컬DB가 아닌 하나의 CVCSA만 관리하면 되기에 훨씬 효율적이다.
한계: 중앙서버에 문제가 발생하면 답이없다.
- 중앙서버가 다운되면 그 동안 다른 작업자와 협업이 불가능
- 중앙DB데이터가 날라가면 프로젝트의 모든 히스토리도 날라간다.
이 때문에 밑의 DVCS가 나오게 되었다.
DVCS 분산버전관리시스템
위의 모든 단점, 문제를 개선하고자 나온것이 DVCS다. 대표적으로 git이 있다.
메인 서버 뿐만이 아니라 클라이언트의 컴퓨터에도 버전이 저장되어있어서 메인서버에 문제가 생겨도 클라이언트로부터 서버를 복원할 수 있다. 또한 메인서버가 다운되어있어도 자신의 DB에도 버전이 있기에 이를 이용하여 작업을 할 수가 있다. 추후에 비교하며 변경사항들을 합치면 되기 때문이다.
Git
컴퓨터 파일의 변경사항을 추적하고 여러 명의 사용자들 간에 해당 파일들의 작업을 조율하기 위한 분산 버전 관리 시스템이다.(출처. 위키피디아)
리누스 토발즈가 CVCS중 하나인 Subversion을 쓰다가 열받아서 2주만에 만든 결과물이기도 하다...
위의 설명만으로는 부족해서 추가설명을 해보면 원래대로라면 메인서버와 수많은 작업자들이 있을테지만 간단하게 메인서버와 A,B작업자가 있다고 해보자. 작업을 하기 위해 작업자 A,B는 메인서버로부터 1.ver의 파일을 내려받아 각자 로컬DB에 저장을하고 각자 자신 컴퓨터에서 작업을 한다. 그러면 각자 로컬에 1-a.ver, 1-b.ver의 버전들이 생기고 그 후에 자신들이 작업한 것을 변경내역과 함께 메인서버로 보내면 바로 합치는 것이 아니고 관리자가 검토후에 작업한 것들을 합쳐서 2.ver로 갱신을 한다. 그러면 메인서버에는 1.ver, 2.ver와 작업자들이 변경한 기록들이 남아있게 되고 작업자들은 2.ver을 서버로 부터 받아서 다시 자기 로컬에서 작업을 하고 이런식이다. 그렇다고 해서 모든 작업다가 2.ver을 내려받을 필요는 없다. 변경사항이 자신의 작업과 무관하면 작업후에 합치면 되니깐. 예를 들어 작업자 A가 작업을 한 번 더해서 1-aa.ver이 되어도 메인서버로 보내면 관리자가 검토후에 합치면 된다. 이것이 바로 메인서버에 실시간으로 연결되어 있지 않아도 자신의 로컬에서 계속 작업을 해 나갈 수 있다는 것이 git의 큰 장점이다. 또한 메인서버가 날라가도 작업자들 로컬DB에 1-a.ver 1-b.ver이 남아있으니 이를 통해 복원 할 수 있다. 보다 자세한 설명은 이쪽을 참고.
Branch
git을 사용하고 보다 잘 이해하려면 branch의 이해가 필수다.
branch : 1. 나뭇가지 2. 지사, 분점 (출처. 네이버사전)
위의 사전 뜻대로 버전관리를 나뭇가지 형태로서 한다는것이다. 가지처럼 필요없는 가지는 자르거나 가지의 시작부분인 분기점형태를 만들어서 말이다. 밑의 그림을 보자.
일반적으로 위의 그림처럼 버전을 4단계에 나누어서 관리한다. 밑에 있는 branch일수록 많은 변경이 일어나고 변경사항들을 취합하여 윗단계로 넘기면 검토후 취합하고 최종적으로 main으로 넘기게 된다. 이 과정에서 branch를 말 그대로 가지치기하듯이 되돌리기도 한다. -> hotfix 라고 급하게 바꿔야 하는경우 Release를 이용하지 않고 바로 Main으로 넘기는 경우도 있다.
GitHub
깃허브는 분산 버전 관리 툴인 깃 저장소 호스팅을 지원하는 웹 서비스이다.(출처. 위키피디아)
git과 github는 다른것이다. 헷갈리면 안된다!!
- git: DVCS
- github: git저장소의 호스팅 웹 서비스
GitHub에 git저장소를 만들어보자
- GitHub에 가입한다. GitHub로 이동하여 Sign Up 클릭
- Repository를 생성한다. 생성할 때 이름은 편한대로 해도 된다. 체크하지 않은 나머지들은 지금은 당장 중요하지 않지만 살펴보자.
- Description: 생성할 Repository에 대한 간단한 설명
- Add a README file: Project에 대한 길게 쓸 수 있는 설명파일
- Add. gitignore: Repository에 올라갈 파일중 무시할 템플릿을 설정(비밀번호같은게 올라가면 곤란하니까)
- Choose a license: 라이센스를 선택, 다른 라이센스를 가져다 쓰거나 본인이 쓴 코드는 이러이러한 라이센스를 따른다고 알리기 위한 것.
- 짜잔 원격저장소 역할을 하는 github repository 를 만들었다. 이제 여기는 위 DVCS의 서버 컴퓨터의 저장소 역할을 할 수 있다. 즉 git을 이용하여 파일을 repository에 올리고 버전관리를 할 수 있다는 뜻이다.
- 깃허브는 단순히 저장소 호스팅을 지원 하는것 이외에도 다양한 기능이 있다. 이는 추후에 알아보자.
출처
https://github.com/Knowre-Dev/WebDevCurriculum
https://git-scm.com/book/ko/v2
