해당 글은 제로베이스데이터스쿨 학습자료를 참고하여 작성되었습니다
Configuration Management Systems(CMS) = 형상관리시스템
Version Control Systems(VCS) = 버전관리시스템
Source Data + History
협업, 작업추적, 복구 등이 가능
모든 실행 파일별로 카피하여 관리 -> 용량문제
프로그램이 팅기면 작성자료 손상 -> 정신적 타격, 시간 및 비용 손해
개인 컴퓨터에서 버전 관리 -> 하드 손상시 데이터 손실
버전은 관리되지만, 협업은 여전히 어려움
협업 가능
commit하는 순간 배포되어 다수에게 버그 유발 가능
인터넷이 안되면 작업 불가능
자신만의 version history를 가질 수 없음
Systems commit 하더라도 개인저장소 내에 적용됨 (다른 개발자에게 영향 없음)
원하는 순간에 배포(Push) 가능
오프라인에서도 작업 가능
자신만의 version history를 가짐
CVCS - CVS, SVN, etc.
DVCS - Mercurial, Git, etc.
1980년대 만들어진 형상관리 시스템
commit 중 오류 발생 시 Rollback이 되지 않는 문제
CVS 저장소의 파일들은 이름을 바꿀 수 없다. 제거하고 나서 다시 추가해야 한다.
CVS 프로토콜은 디렉터리의 이동이나 이름 변경을 허용하지 않는다. 서브 디렉터리의 파일은 모두 지우고 다시 추가해야 한다.
이후 SVN으로 대체됨
2000년대 만들어졌고, 현재까지 두루 사용 중
SVN 보다 빠른 속도와 많은 기능을 지원
현재 많은 기업이 사용 중
요즘 기업들은 대부분 SVN 혹은 Git을 사용중이다.
Git 을 호스팅 해주는 웹 서비스, 협업을 위한 기능을 제공
Github는 오픈소스생태계 매우 잘 구축되어있음 -> 모든 코드가 공개
코드가 클라우드에 있음
참고 - 개인 또는 소수의 개발자가 오픈소스에 접근하기 쉬움
설치형 버전관리 시스템 - 소스코드 보안이 중요한 기업에서 주로 사용
클라우드 버전 관리 시스템 - 10명 이하 무료 (Github 와 유사)
Issue tracker, Git Remote Repository, API, Team, Group 기능 제공
참고 - 회사 같은 영리단체에서 자신들만의 생태계 구축
git config --global user.name 유저명
git config --global user.email 메일
git config --global core.autocrlf true
Windows : CR(\r) + LF(\n)
Unix & Mac : LF(\n)
따라서 각 사용자의 OS가 다른 경우 문제가 발생할 수 있음
Windows - 가져올 때는 LF -> CRLF로 변경하고 보낼 때는 CRLF -> LF로 변경
※설치과정에서 설정해주었으나 한번 더 입력해도 무관
git config --global core.editor <editor>
git config --list
git config <key>
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git --version
git version 2.39.2.windows.1
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config --global user.name InSung-Na
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config --global user.email lht98323@gmail.com
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config --global core.editor vim
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config --global core.autocrlf true
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config --list
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.smudge=git-lfs smudge -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
http.sslbackend=openssl
http.sslcainfo=C:/Program Files/Git/mingw64/ssl/certs/ca-bundle.crt
core.autocrlf=true
core.fscache=true
core.symlinks=false
pull.rebase=false
credential.helper=manager
credential.https://dev.azure.com.usehttppath=true
init.defaultbranch=master
core.autocrlf=true
core.editor=vim
user.name=InSung-Na
user.email=lht98323@gmail.com
HPcom@DESKTOP-TJ3L1B9 MINGW64 ~
$ git config core.autocrlf
true
소스코드가 저자오디어 있는 여러 개의 Branch가 모여있는 디스크상의 물리적 공간
내 컴퓨터의 공간(Local Repository)와 서버의 공간(Remot Repository)로 구분
특정 시점이나 Branch의 소스코드로 이동하는 것
Checkout 대상 - Branch, Commit, Tag
Checkout 을 통해 과거 여러 시점의 코드로 이동이 가능(버전변경)
작업한 내용이 올라가는 임시저장영역
이 영역을 이용하여 작업한 내용 중 commit에 반영할 파일만 선별하여 commit을 수행할 수 있다.
작업한 내용을 Repository에 저장하는 과정
각각의 commit은 의미있는 변경단위이고, 변경에 대한 설명을 commit log로 남김
권장 - commit 을 아끼지 마세요.(게임의 save point)
참고 - commit 단위나 commit log format 을 정해놓은 회사나 팀도 있음
임의의 commit 위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표
Tag가 붙은 commit은 commit id (version) 대신 tag name으로 쉽게 checkout 가능
Local Repository의 내용 중, Remote Repository에 반영되지 않은 commit을 Remote로 보내는 과정
권장 - push 하는 순간 다른 개발자들도 영향을 받음. 검증되지 않은 코드는 push하지 않도록 함
Remote에 있는 내용 중, Local에 반영되지 않은 내용을 가져와서 Local 에 저장하는 과정
다른 팀원이 변경하고 push 한 내용을 Local 에 가져올 수 있음
참고 - push 과정에서 conflict(충돌)이 일어나서 push가 거절된 경우, pull을 통해 Remote의 변경 내용을 Local에 반영하여 conflict를 해결한 뒤 다시 push를 시도해야 함
특정 시점에서 분기하여 새로운 commit을 쌓을 수 있는 가지를 만드는 것
개발의 주축이 되는 branch를 master branch (혹은 main branch)라고 함
모든 branch는 최종적으로 다시 master branch에 merge(병합) 되는 형식으로 진행됨
branch의 반대개념으로 하나의 branch를 다른 branch와 합치는 과정
merge 되는 두 branch는 주종관계가 성립. 예 - dev branch를 main branch에 merge
merge 되는 과정에서 conflict(충돌)이 발생하는 경우, diff를 수정하여 해결 후 merge 진행