2. 버전 관리 시스템이란?
일반적인 경우, 작업한 파일의 최종본만을 가지고 있게 되지만, 버전 관리 시스템
사용시 파일의 변경 이력도 보존 가능. (파일 복원 가능.)
저장소(레파지토리)라고 불리는 일종의 데이터베이스에 파일과 변경내역을 저장.
이전 버전(변경 전)의 파일 히스토리까지 보존하고 관리할 수 있어 여러가지 이점이
생김.
3. 버전 관리 시스템 사용시 장점
소스 파일을 서버에 안전하게 보관.
팀끼리 소스 공유 및 협업이 편리.
작업하다 아니다 싶으면 이전 버전의 소스로 복원 가능.
특정 시점의 소스, 고객사별 소스를 별도로 관리하지 않아도 됨. (통합 관리 및 복원
가능)
변경 내역 확인 가능. (예: 특정 기간동안 소스의 수정된 부분들을 확인하여 버그 발
생 부분을 찾는데 용이)
5. 로컬 저장소와 원격 저장소
각 개발자 컴퓨터에도 로컬 저장소가
있는 것이 차이!
로컬 저장소
원격 저장소
6. 기본적으로는 로컬에서 작업
기본적으로는 로컬에서 (로컬저장소와) 작업을 한다고 생각하면 된다.
그리고 필요할 때만 (다른 개발자와 변경된 소스를 공유할 필요가 있을 때) 원격 저
장소와 동기화.
그래서 사용하게 되는 대부분의 명령어가 로컬 저장소를 대상으로 한 명령.
서버와 동기화를 위한 명령은 Push(로컬 저장소 => 원격 저장소), Pull (원격 저장소
=> 로컬 저장소) 정도.
(기존에 SVN을 사용해 봤다면 SVN의 서버 저장소가 Git의 로컬 저장소라고 생각
하면 편하다. 거기에 원격 저장소라는 단계가 하나 더 추가된 꼴.)
7. 로컬 저장소를 두는 장점
인터넷이 안되는 상황 (출장 등)에서도 버전 관리가 가능.
주로 로컬 저장소에서 작업을 하므로 속도가 월등히 빠름.
일단 로컬 저장소를 대상으로 작업하기 때문에 비교적 마음 편하게 버전 관리가 가
능.
원격 저장소의 데이터가 소실되었을 때, 로컬 저장소를 이용하여 복원 가능.
전세계에 걸친 오픈소스 개발에 적합. (Git은 리눅스 커널 개발을 위해 리누스 토발
즈가 개발한 것.)
혼자서 버전 관리하기도 편함.
8. 우리가 사용하는 Git 호스팅 서비스는?
비트버킷!
(Bitbucket)
https://bitbucket.org
11. 커밋과 커밋 식별자
변경사항을 로컬 저장소에 올리는 것도 커밋이라고 하고, 그 결과물인 해당 시점의
데이터도 커밋이라고 부름.
커밋을 식별하기 위해 SVN은 리비전 번호를 사용. (일련 번호)
예: 789
Git은 SHA-1 해시값 사용. (문자+숫자)
예: 24b9da6552252987aa493b52f8696cd6d3b00373
너무 길다? 앞부분만 적어도 가능.
12. 최초로 원격 저장소 받아오기 (복제)
원격 저장소가 이미 구성되어 있다면, 최초에 한번 (그리고 로컬 저장소를 날린 경
우) 받아와야 한다.
Clone
원격 저장소를 로컬 저장소로 복제해 오므로, 명령어 이름을 Clone 이라고 한다.
원격 저장소의 최신 상태를 가져오는 게 아니라, 기존의 히스토리까지 모두 복사해
오므로 복제이다!
13. 워킹 디렉토리 / 스테이징 영역 / 로컬 저장소
워킹 디렉토리 : 개발자 실
제 디스크에 보이는 파일들
스테이징 영역 : 로컬 저장
소에 커밋할 대상이 되도록
추가한 파일들이 위치한 영
역 (논리 영역)
로컬 저장소 : 말그대로. (해
당 프로젝트의 .git 디렉토리)
16. 기존의 시스템(SVN 등)은 파
일이 변화되면 파일의 변경된
내용 부분만 저장
Git은 '스냅샷'이라고 해서 변
화된 파일은 통째로 저장
장점 : 속도가 빠름, 비교적 버
전/브랜치 이동 및 병합이 잘
됨
스냅샷
17. Commit 시 유의할 점
가능하면 단일 작업 단위별로 커밋한다. (기능 한가지 추가, 버그 한가지 수정)
(스테이징 기능을 이용하면 편리.)
커밋 메시지(커밋 로그)를 잘 작성한다. (나중에 가장 많이 보게 될 내용이므로)
18. Push / Pull
Push
내 로컬 저장소에 추가한 커밋들을 원격 저장소에 올린다.
Pull
원격 저장소에 변경된 내용을 내 로컬 저장소로 받아온다.
Push 하기 전에 원격 서버에 변경된 사항이 있으면 먼저 Pull 해와서 병합한 후, Push
하도록 강제되어 있다. (그래서 Push 하기 전에는 Pull을 먼저 하는 습관을 들이는 것
이 좋다.)
19. 작업내용 되돌리기 (복원)
방금 한 커밋이 잘못 되었다면?
덮어서 커밋 가능 (amend 옵션을 준 커밋) (커밋 메시지 수정, 빠트린 파일 추가)
특정 커밋의 내용으로 이동하기
체크아웃! (워킹 디렉토리의 파일들이 해당 커밋으로 변경됨. 주로 조회용.)
특정 커밋의 내용으로 원복하기
리셋! (주로 최신 커밋으로만 리셋. 임시 작업 내용을 날릴때.)
위의 명령어는 모두 로컬 저장소를 대상으로 함.
20. 태그
특정 커밋에 태그를 남김. (중요함을 나타내는 일종의 책갈피?)
주로 새 버전이 릴리즈 될 때마다 해당 커밋에 태그를 남김.
태그를 이용하여 해당 릴리즈 버전의 소스를 찾아 복원하기 편함. (다시 빌드, 수정)
태그명 예: v1.0
21. 브랜치와 병합 #1
소스의 히스토리를 일종의 나무(트리)라고 본다면 갈래가 나눠져 나온 것을 가지(브랜치)
라고 함.
따로 브랜치를 생성하지 않으면 메인 브랜치만 존재. (기본 메인 브랜치명: master)
브랜치로 나누면 충돌없이 동시에 작업이 가능.
예) 메인 브랜치: 프로덕션 코드 / 브랜치 A: 기능 추가 / 브랜치 B: 버그 수정 / 브랜치 C:
특정 고객사 커스터마이징
브랜치로 나누다가 작업이 완료되면, 메인 브랜치에 합침. 이를 병합(Merge)라고 함.
브랜치를 따서 작업하고 병합하는 것을 반복하며 개발.
Git은 브랜치를 적극적으로 사용할 것을 권장. 기존 시스템에 비해 브랜칭과 머지 잘됨.
23. 체크아웃
로컬 저장소로부터 특정 시점의 커밋(소스 파일)을 끌어오는 개념이라고 이해하면
편함.
같은 브랜치 내의 특정 시점의 커밋을 체크아웃하면 해당 파일들이 워킹 디렉토리
에 복원됨.
다른 브랜치를 체크아웃하면 해당 브랜치의 파일들이 워킹 디렉토리에 복원됨.
그래서 과거 커밋의 소스 파일을 살펴보거나, 브랜치를 전환하여 작업할 때 사용.
기존의 버전 관리 시스템과 달리 Git은 물리적인 파일들이 순식간에 교체된다.
(브랜치를 별도의 하위 디렉토리로 관리하는 방식이 아니다.)
24. 충돌 (Conflict)
기본적으로는 Git 시스템이 알아서 변경된 부분들을 병합을 해주지만, 병합에 실패
하여 충돌(Conflict)가 나는 경우들이 생김.
저장소로부터 파일을 받아왔을 때, 내 워킹 디렉토리에 수정한 파일이 있고, 두 파
일의 같은 부분이 수정되어 있을 경우 발생.
뭔가 짜증나고 곤란한 상황.
같은 부분이 수정되었기 때문에 논리상 어쩔 수 없다. 알아서 해줄 방법이 없다. 수
동으로 해결.
알아서 하거나, 수정을 한 상대방과 논의하여 병합.
25. 물론 버전 관리 시스템(Git)의 사용법을 익히고 적응하는 것도 쉬운 일은 아니지만,
어떤 규칙과 정책으로 소스와 버전을 관리해 나갈지가 중요하고도 어려운 문제. (특
히 브랜칭 정책.)
소프트웨어의 버전 관리를 어떻게 할 것인가가 버전 관리 시스템 운영과도 연관됨.
의미 있는 단위로 변경 이력을 남긴다는 측면을 유의하는 게 좋음. (커밋 단위를 좀
더 의미있게. 과거 커밋들을 날리는 작업은 지양.)
그럼에도, 일단 서버에 소스를 백업하고 팀과 공유한다 정도로 생각하고 시작해도
충분.
향후 관건
