버전관리

git 이란, 버전관리 시스템의 한 종류

버전관리란?

버전관리 시스템 (형상 관리)

• congifuration Management Systems
• Cersion Control Systems

버전관리를 하는 이유는?

• Source Data(예 .py) + History
• 협업, 작업 추적, 복구 등이 가능

Git 등장 배경

아-주 오래전부터 필요성이 대두되어왔음
혼자 또는 협업 해야할 경우 버전관리가 안되어오면 작업하기 너무 어려웠음
이제는 없으면 협업하기 힘든정도임

아주 오래전..

• Source Folder + 실행 파일을 버전별로 내 컴퓨터에 카피하여 관리
• 저장을 하지 않고 하루 종일 개발한 코드가 컴퓨터가 다운되면 날아감 😱

그래서 파일의 버전을 관리하고..

local version control systems

• 내 컴퓨터에서 버전 관리 가능 -> 내 컴퓨터 하드가 날아가면 전체 코드 사라짐 😱
• 버전은 관리되지만, 동시 관리가 안되니 협업은 여전히 어려움

역시 이것도 부족해

그러면 중앙에서 관리해보자

중앙에 버전 파일들을 두고
가져가서 작업해 그리고 작업하는 동안 버전은 계속 업데이트되어서 중앙에 보내질거야

Centrallized Version Control Systems

• 협업이 가능해짐
• commit 하는 순간 배포되어 다수에게 버그 유발 가능 (서버로 바로 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보다 빠른 속도와 많은 기능 지원
• 현재 많은 기업 사용 중

git 기반의 서비스

github

• https://github.com
• git을 호스팅해주는 웹서비스, 협업을 위한 기능 제공
• 참고 : 소스코드 보안이 중요한 경우 사용 기피

gitlab

• https://gitlab.com
• 설치형 버전 관리 시스템 - 소스코드 보안이 중요한 기업에서 주로 사용
• 클라우드 버전관리 시스템 - 10명이하 무료 (github와 유사)
• issue tracker, git remote repository, api, team, group 기능 제공

git기본용어

repository

소스 코드가 저장되어있는 여러개의 branch가 모여있는 디스크상의 물리적 공간
local repository와 remote repository로 구분

주로 프로젝트 단위로 구성됨👩‍💻👨‍💻
폴더와는 조금 다름

checkout

특정 시점이나 branch의 소스코드로 이동하는 것을 의미
checkout 대상 - Branch, commit, tag
checkout을 통해 과거 여러 시점의 코드로 이동 가능

stage

작업할 내용이 올라가는 임시저장영역
이 영역을 이용하여 작업한 내용 중 commit에 반영할 파일만 선별하여 commit을 수행 할 수 있음

commit

작업할 내용을 local repository에 저장하는 과정
버전을 올리는 것과 같음
각각의 commit은 의미있는 변경단위, 변경에 대한 설명을 commit log로 남김
메세지에 변경에 대한 내용을 담아야함. 의미있음
권장 : commit을 아끼지 말기 (아끼똥, save point)
참고 : commit 단위나 commit log format을 정해놓은 회사나 팀 도 있음 (빌드 서버를 사용하는 경우)

tag

임의의 commit 위치에 쉽게 찾아갈 수 있도록 붙여놓은 이정표
tag가 붙은 commit은 commit id(version)대신 tag name으로 쉽게 checkout가능

push

local repository의 내용 중 remote repository에 반영되지 않은 commit을 remote로 보내는 과정
권장 : push하는 순간 다른 개발자 들도 영항을 받음. 검증되지 않은 코드는 push하지 않도록 함.

pull

remte에 있는 내용 중 local에 반영되지 않는 내용을 가져와서 local에 저장하는 과정
다른 팀원이 변경하고 push한 내용을 local로 가져옴
참고 : push 중 conflict(충돌)이 일어나서 push가 거절된 경우, pull을 통해 remote의 변경내용을 local에 반영하여 conflict를 해결한 뒤 다시 push해야함

branch

특정 시점(commit단위)에서 분기하여 새로운 commit을 쌓을 수 있는 가지를 만드는 것
개발의 주축이 되는 branch를 master branch 혹은 main branch라고 함
모든 barnch는 최종적으로 다시 master branch에 merge 가능

merge

barnch의 반대 개념으로 하나의 branch를 다른 branch와 합치는 과정
merge 되는 두 branch는 주종 관계가 성립. 예)dev branch를 main branch에 merge
merge 되는 과정에서 conflict가 발생할 경우 diff를 수정하여 conflict를 해결한뒤 merge를 진행할 수 있음

local repository

local repository 구성

working directory 작업 공간 : 아직은 git이 관리하는 영역은 아님 그러나 git명령어로 add 하는 순간 stage로 올라감. 버전 관리가 안됨
index(stage) stage area : 역시나 버전관리는 안되지만 여기서 commit하는 순간 버전이 매겨짐

local repository 생성

git init

git init

폴더에서 git을 초기화하는 명령어로, 사용하면 해당 폴더를 git이 관리하기 시작

git status

git status

git에 존재하는 파일 확인

master 브랜치에 있고
commit은 없어
워킹디렉토리에는 있는데 stage에 add되지 않은 파일은 있어 그건 test.txt파일이야

git add

git add <filename>

working directory에서 변경된 파일을 index stage에 추가

commit 가능한 파일이 있어 그건 test.txt파일이야

git commit

git commit -m 'commit에 대한 설명' <filename>

remote repository 생성

깃허브 에서 생성

local에 remote 등록

 git remote add origin https://<username>:<toeken>@github.com/<remote repository>.git

remote 정보 확인

git remote -v

remote에 변경내용 push 하기

local head에 반영된 변경된 내용을 remotre에도 반영하기 위해서는 push 해야함

git push origin <branchname>

remote에 pull 하기

remote에만 있고 local에는 없는 상황
local에도 가져오는 pull 하기

git pull origin <branchname>