- Git
1-1) 버전관리
버전관리 시스템(=형상관리) 중 하나
- Configuration Management Systems
- Version Control Systems(VCS)
버전관리
- Source Data + History
프로그램을 짜면 소스데이터가 나옴(.py 파일들).
작업하는 동안 늘어나고 수정되는 것을 이력이라고 부름 - 협업, 작업추적, 복구등이 가능
파일의 데이터와 이력을 기반으로 가능
1-2) Git 등장 배경
아주 오래전
- source folder + 실행파일을 버전별로 카피해서 관리(ex. 최종, 최최종, 진짜 최종 같은 느낌)
- 하루종일 개발한 코드가 컴퓨터가 다운되면 날아감
Local Version Control Systems
- 내 컴퓨터에서 버전 관리 가능 -> 하드가 날아가면 코드 사라짐
- 버전은 관되지만, 협업은 안 됨
Centralized Version Control Systems
- 협업 가능.
- 중앙에서 관리해서 서버에 접속해야만 관리 가능
- commit 하는 순간 배포돼 다수에게 버그 유발 가능(서버로 바로 commit), 완료되지 않은 상태에서 올렸을 때는 버그
- 인터넷이 안 되면 작업 불가
- 자신만의 version history를 가질 수 없음.
(현재) Distributed Version Control Systems
- commit 하더라도 개인 저장소 내에 적용됨(다른 개발자에게 영향 없음)
- 원하는 순간에 배포(push)가능
- 오프라인에서도 작업 가능. 서버랑 연결 안 돼도 작업가능
- 자신만의 version history를 가짐
1-3) 버전관리 시스템의 종류
버전관리 시스템의 종류
- CVCS(중앙관리) - CVS, SVN, etc.,
- DVCS(분산관리) - Mercurial, Git, etc.,
CVS
- 1980년대 만들어진 형상관리 시스템
- commit중 오류발생 시 rollback이 되지 않는 등의 문제
- 이후 SVN으로 대체됨
SVN
- https://subversion.apache.org/
- 2000년대 만들어졌고, 현재까지 두루 사용중
중앙관리이긴한데, git처럼 분산관리로도 사용됨
Git
- https://git-scm.com/
수시로 들어가서 document참고할 것 - SVN보다 빠른 속도와 많은 기능을 지원
- 현재 많은 기업이 사용 중
요즘 기업들은...
- 대부분 SVN 혹은 Git 사용 중
1-4) Git 기반의 서비스
Github
- https://github.com
- Git을 호스팅해주는 웹 서비스, 협업을 위한 기능을 제공 = 서버가 클라우드에 있다.
- 참고: 가업 등 소스코드 보안이 중요한 경우 사용을 기피함
Gitlab
- https://gitlab.com
- 설치형 버전관리 시스템 - 소스코드 보안이 중요한 기업에서 주로 사용
- 클라우드 버전 관리 시스템 - 10명이하 무료(github 와 유사)
- issue tracker, Git Remote Repository, API, Team, Group 기능 제공
--
참고 - lind ending
- windows : CR(\r) + LF(\n)
- MAC : LF(\n)
--> WINDOWS: 가져올때는 LF를 CRLF로 변경하고, 보낼 때는 CRLF를 LF로 변경
%git config -- global core.autocrlf true
Editor
%git config -- global core.editor
- 예)
%git config -- global core.editor vim
전체설정 확인
git config -- list
항복별 설정확인
git config
- 예) git config user.name
$ git config --global user.name haeun71
$ git config --global user.email dlvmsl66@naver.com
$ git config --global core.autocrlf true
$ git config --list
- Git 기본용어
- Repository
- 소스코드가 저장돼있는 여러개의 branch가 모여있는 디스크상의 물리적 공간
- local Repository 와 remote Repository로 구분(분산처리 하기 때문에 서버도, 로컬에도 있음)
- checkout
- 특정 시점이나 branch의 소스코드로 이동하는 것을 의미
- checkout 대상 - Branch(버전관리를 여러개로 나눠서 가능), Commit, Tag
- checkout 을 통해 과거 여러 시점의 코드로 이동이 가능
- stage
- 작업할 내용이 올라가는 임시저장영역
관리하는 단계 중 하나 - 이 영역을 이용해 작업한 내용 중 commit에 반영할 파일만 선별해 commit을 수행할 수 있음
- commit
버전을 매기는 행위
- 작업할 내용을 local Repository에 저장하는 과정
- 각각의 commit은 의미있는 변경단위이고, (버전)변경에 대한 설명을 commit log 로 남김
- 권장: commit을 아끼지 마세요(게임의 sava point. 아끼면 똥 된다)
- 참고: commit 단위나 commit log format을 정해놓은 회사나 팀도 있다.(빌드 서버를 사용하는 경우)
- tag
- 임의의 commit위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표
- tag가 붙은 commit은 commit id(version)대신 tag name으로 쉽게 cheak out 가능
- push
- local repository의 내용 중, remote repository에 반영되지 않은 commit을 remote repository로 보내는 과정
- 권장: pust 하는 순간 다른 개발자들도 영향을 받음. 검증되지 않은 코드는 push 하지 않도록 함
= 로컬에서 commit은 자유롭게 하되 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되는 과정에서 conflict(충돌)이 발생하는 경우, Diff를 수정해 conflict를 해결한 뒤 merge를 진행할 수 있음
