버전관리
버전관리(형상관리, VCS)
버전관리 시스템(형상관리)
• Configuration Management Systems
• Version Control Systems (VCS)
버전관리
• Source Data + History
• 협업, 작업추적, 복구 등이 가능
등장배경
- 등장 이전
- Source Folder + 실행파일을 버전별로 카피하여 관리
- 하루종일 개발한 코드가 컴퓨터 다운으로 날아가버림
- Local Version Control Systems
- 내 컴퓨터에서 버전관리 가능 -> 버전은 관리되지만, 협업은 여전히 어려움
- Centralized Version Control Systems
- 협업이 가능해짐
- commit 하는 순간 배포되어 다수에게 버그 유발 가능
- 인터넷이 안되면 작업 불가능
- 자신만의 version history를 가질 수 없음
- Distributed Version Control Systems(현재)
- commit 하더라도 개인저장소 내에 적용됨(다른 개발자에게 영향없음)
- 원하는 순간에 배표(Push) 가능
- 오프라인에서도 작업 가능
- 자신만의 version history를 가짐
버전관리 시스템의 종류
버전관리 시스템의 종류
• CVCS (중앙관리형) - CVS, SVN, etc.,
• DVCS (분산관리형) - Mercurial, Git, etc.,
CVS (몰라도 됨)
• 1980년대 만들어진 형상관리 시스템
• commit 중 오류 발생 시 Rollback 이 되지 않는 등의 문제
• 이후 SVN 으로 대체됨
SVN
• https://subversion.apache.org/
• 2000년대 만들어졌고, 현재까지 두루 사용 중
Git
• https://git-scm.com/
• SVN 보다 빠른 속도와 많은 기능을 지원
• 현재 많은 기업이 사용 중
요즘 기업들은...
• 대부분 SVN 혹은 Git 사용 중
Git 기반의 서비스
Github (일종의 클라우드)
• https://github.com
• Git 을 호스팅 해주는 웹 서비스, 협업을 위한 기능을 제공
• 참고 - 소스코드 보안이 중요한 경우 사용을 기피함
(최근에는 보완하는 버전이 나옴)
Gitlab
• https://gitlab.com
• 설치형 버전관리 시스템 - 소스코드 보안이 중요한 기업에서 주로 사용
• 클라우드 버전 관리 시스템 - 10명 이하 무료 (Github 와 유사)
• Issue tracker, Git Remote Repository, API, Team, Group 기능 제공
Installing Git
Installing on Windows
Git Download
• git-scm.com/download/win
git bash 는 관리자 권한으로 실행하자
- 모든 터미널 사용은 git bash 를 씀
GitHub 가입
GitHub 사이트
Git Global Configuration
Global Username & Email
- 터미널에서 입력
git config --global user.name <username>
git config --global user.email <email>
CRLF - Windows
참고 CRLF - Line ending
• Windows : CR (\r) + LF (\n)
• Unix or Mac : LF (\n)
• Windows 사용자와 Mac 사용자가 같은 Git Repository 를 작업할 때
코드에서 변경된 내용이 없어도 CRLF 차이로 인해 commit 이 발생할 수 있음
• 일반 파일에서는 보이지 않음
• 텍스트든 코드든 엔터를 치고 줄을 바꾸는 순간 줄바꿈 문자가 보이지 않게 추가가 되고 있고, 존재한다. 컴퓨터는 알고 있다
• 이 줄바꿈 문자가 윈도우에서는 CR 과 LF 두 문자로 이루어져 있다.
• 그런데 Unix or Mac 계열에서는 LF 한 문자로만 이루어져 있다.
• git은 파일에 다른 부분이 있으면 버전이 다르다고 인식함
• 그러면 git은 파일 내용이 바뀌었으니까(다른 버전이니까) 무언가 액션을 취하라고 함
• 그래서 줄바꿈 문자 떄문에 위와 같은 액션이 생기면 혼란이 발생함
• 그래서 윈도우 유저들은 설정을 따로 해줘야 함
해결 방법
- 서버에 LF로 저장되게 하는게 제일좋은 방법임
- CRLF - Windows
-> 서버에서 가져올 때 LF 를 CRLF 로 변경하고, 서버에 보낼때는 CRLF 를 LF 로 변경 (설치할때 이미 설정되어 있음, 한번 더 입력해서 실행해도 상관없음)
% git config --global core.autocrlf true
- CRLF - Mac
-> Mac - LF 만 사용
% git config --global core.autocrlf input
Editor
기본(디폴트) 에디터 설정
git config --global core.editor <editor>
- 예제
% git config --global core.editor vim
전체 설정 확인(빠져나오기 : Q)
git config --list
항목별 설정 확인
git config <key>
Git 기본 용어
Repository
• 소스코드가 저장되어 있는 여러 개의 Branch 가 모여있는 디스크상의 물리적 공간(일반 우리가 아는 컴퓨터 폴더와는 조금 다르다)
• Local Repository 와 Remote Repository 로 구분
(컴퓨터 공간과 서버 공간)
Checkout
• 특정 시점이나 Branch 의 소스코드로 이동하는 것을 의미
(버전관련 시스템은 Commit 을 통해서 계속 버전을 업데이트하고 있고, 특정버전에 Tag 할 수도 있다, 버전관리를 여러 Branch로 나누어서 할 수도 있다)
• 위처럼 했을 때, 그 시점의 코드들이 다양하게 존재함
• Checkout 대상 - Branch, Commit, Tag 할 수도 있다)
• Checkout 을 통해 과거 여러 시점의 코드로 이동이 가능
Stage
• 작업할 내용이 올라가는 임시저장영역
git은 3단계 영역으로 관리를 하는데,
1. working directory : 처음에 우리가 윈도우 폴더에 파일들을 모아두면 그건 working directory 라는 영역에 들어가 있는 상태이다
(우리가 눈으로 보는 파일들은 working directory 에 있는 상태다)
2. Stage : 거기에서 내가 어떤 파일들을 선정해서 git 에서 사용할거라고 등록을 해주는 단계가 있는데, 등록을 하게되면 Stage 공간에 들어간다.
3. Head : 수정을 해서 버전을 매기는 작업을 하면 Head 영역에 들어간다.
• 이 영역을 이용하여 작업한 내용중 commit 에 반영할 파일만 선별하여 commit 을 수행할 수 있음
Commit
- 버전을 매기는 행위
- 메시지는 최대한 자세하게(안그럼 코드를 다 뒤져야함)
• 작업할 내용을 Local Repository 에 저장하는 과정
• 각각의 commit 은 의미있는 변경단위이고, 변경에 대한 설명을 commit log 로 남김
• 권장 - commit 을 아끼지 마세요.
(게임의 save point, 아끼면 똥됩니다.)
• 참고 - commit 단위나 commit log format 을 정해놓은 회사나 팀도 있음 (빌드 서버를 사용하는 경우)
Tag
• 임의의 commit 위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표
(몇주 전 이런건 commit 으로 위치를 찾을 수 있지만, 몇달 전, 몇년 전 등 기간이 긴 경우에는 Tag 를 붙여놓는다)
• Tag 가 붙은 commit 은 commit id (version) 대신 tag name 으로 쉽게 checkout 가능
Push
• Local Repository 의 내용 중, Remote Repository 에 반영되지 않은 commit 을 Remote Repository 로 보내는 과정
• 권장 - Push 하는 순간 다른 개발자들도 영향을 받음. 검증되지 않은 코드는 Push 하지 않도록 함.
(local에서 commit은 자유롭게 하되, Push를 할 때는 실행이 되는 코드로 검증을 하고 Push 할 것)
Pull
• Remote Repository 에 있는 내용 중, Local Repository 에 반영되지 않은 내용을 가져와서 Local Repository 에 저장하는 과정
• 다른 팀원이 변경하고 Push 한 내용을 Local Repository 에 가져올 수 있음
• 참고 - Push 과정에서 Conflict (충돌)이 일어나서 Push 가 거절된 경우,
Pull 을 통해 Remote Repository 의 변경 내용을 Local Repository 에 반영하여 Conflict 를 해결 한뒤 다시 Push 를 시도해야 함.
Branch
• 특정 시점 (commit 단위) 에서 분기하여 새로운 commit 을 쌓을수 있는 가지를 만드는 것
(메인 가지에는 영향을 미치지 않음)
• 개발의 주축이 되는 branch 를 master branch (혹은 main branch) 라고 함
• 모든 branch 는 최종적으로 다시 master branch 에 merge (병합) 되는 형식으로 진행 됨
Merge
• Branch 의 반대개념으로 하나의 Branch 를 다른 Branch 와 합치는 과정
• Merge 되는 두 Branch 는 주종관계가 성립. 예 - dev branch 를 main branch 에 merge
• Merge 되는 과정에서 Confict (충돌) 이 발생하는 경우 Diff 를 수정하여 Conflict 를 해결한 뒤 Merge 를 진행 할 수 있음
