'2015/06/18'에 해당되는 글 1건

  1. 2015.06.18 Git에 대한 이해

Git에 대한 이해

Git 2015. 6. 18. 21:14

Git이 무엇인지는 알고 있었다. 

형상관리툴~?

그렇다면 Git과 SVN의 차이는 무엇일까?

Git은 Local Repository와 Remote Repository가 있다는  차이가 있단다. 

SVN은 원격지에 갱신만 한다는 의미인데.. 자세한 메커니즘과 구조에 대해서는 조금 더 알 필요가 있겠다.


Git에 대해서 간단히 정리해보겠다. 

참조 : http://www.slideshare.net/ibare/dvcs-git

버전관리를 들어본적 없는 사람들을 위한 DVCS - Git
git Learn DVCS For beginner Distributed Version Control System
www.slideshare.net

본문으로


텍스트 파일이 하나 있고 이 것을 그때그때 수정한 내용을 기록해두고 싶다. 

그렇다면 이 것을 수정할 때마다 새파일로 저장할 것인가? 

그렇다면 여러명이 참여하는 프로젝트에서 변동사항을 그때그때 저장할것인가?

=> 너무 파일들이 많아질 것이다. 나중에는 감당히 안 될 것이다. 


그래서 Git이 필요한 것이다. (물론 SVN, Bazaar, mercurial 등등의 많은 소프트웨어가 있다.)


Git의 


규칙 1

저장을 얼마에 한 번씩 해야 되는 것이냐?

SW개발자가 정해야 한다. 이 것이 Commit이다.

Commit => 이 파일의 의미있는 수준의 수정 작업이 끝났음


커밋 할때마다 커밋 메시지를 통해 기록해놓을 수 있다. 보통 어떤 부분이 수정되었는지를 기록할 것이다.


규칙 2

하나의 커밋(Commit)은 여러개의 파일이 포함 될 수 있다. 

커밋은 여러 파일에 동시에 영향을 가하는 것이다.

Commit1 => 월요일.txt, 화요일.txt [월요일 화요일 학습일정 추가]

Commit2 => 수요일.txt [수요일 학습일정추가]

Commit3 => 수요일.txt 목요일.txt, 금요일.txt [수요일 자율학습계획표, 목요일 금요일 학습일정 추가]


규칙3

파일을 수정하지 않고 새로운 실험을 해 볼 순 없을까?

월, 화, 수, 목, 금 시간표 파일이 있는데 이 파일들을 변경하지 않고 새로운 월, 화, 수, 목, 금 일정을 만들어보고 싶다. 가능할까?

상태를 저장하는 공간을 만들 수 있다. 

Branch

상태란 모든 것이다. 파일, 파일의 내용, 커밋 정보 등 git 이 관리하는 모든 것을 의미한다. 



Git의 시작

지정한 폴더의 변경 내용을 추적하기 위한 준비


init

선택된 폴더의 변경 내 용을 추적하기 위해 git저장소를 만든다. 저장소가 만들어지면 git은 지정한 폴더를 포함하여 하위 폴더의

모든 변경 내용을 커밋 단위로 추적한다. 

master

init명령으로 저장소가 만들어질 때 git은 master라는 이름의 브랜치를 기본으로 생성하고 이 후 커밋 내용을 브랜치 기준으로 저장한다.


완전히 독립된 브랜치 lab1

새로 만든 브랜치 lab1은 master와 완전히 동일한 상태를 가진 공간. lab1 브랜치에서 수정을 한 후 커밋하면 그 변경사항은 lab1에만 기록되며 master 브랜치에는 어떤 영향도 주지 않음


원하는 만큼 브랜치 생성 가능

git은 매우 빠르게 새로운 독립공간의 브랜치를 원하는 만큼 만들 수 있다. 브랜치 이름은 이름 정의 규칙내에서 사용자가 원하는 형태로 작명 할 수 있다.


실험 중 다른 브랜치로 돌아가야한다면?

checkout master

원한다면 언제든 다른 브랜치(작업공간)로 이동할 수 있다.

브랜치는 마지막 커밋 상태를 유지한다. 

작업 중인 위치를 가르키는 가상의 커서가 존재하는데 이를 git에서는 HEAD라 한다. 


브랜치를 이동하는 이유는 뭘까?

...시나리오...

새로운 실험을 하기 위해 lab1을 만들고 열심히 작업하고 있다. 그런데 master 브랜치에 내용을 변경할 일이 발생했다. 

어떻게 해야 할까?


정답 => master 브랜치로 이동하여 변경 작업을 처리한 후 커밋. 다시 lab1 브랜치로 돌아와 하던 실험을 계속한다.


실험종료.선택의 순간

실험 실패

lab1에서 진행했던 실험이 예상과 달리 필요없는 작업이 되었다. 어떻게 하면 될까?

정답

=> master로 이동 후 lab1 브랜치를 삭제한다. lab1의 모든 기록이 제거된다. 기록보관 차원에서 삭제하지 않아도 문제 없다.

실험 성공

lab1에서 진행했던 실험이 성공적으로 끝났다. 실험의 결과를 master브랜치에 옮기려한다. 어떻게 하면 될까?

=> lab1 브랜치의 내용을 마스터 브랜치와 병합(merge)한다.


브랜치와 브랜치의 병합(Merge)

merge lab1

병합결과

master브랜치에 lab1 브랜치를 병합하면 git은 lab1 브랜치의 내용과 master브랜치의 가장 최신 commit을 포함하여 두 브랜치를

병합한다.

변경 내용에 따라 파일 내용이 변경되고 때론 파일이 삭제될 수 있으며 추가될 수도 있다.


정리

commit => 수정 내역을 사용자 기준의 의미로 기록한다.

branch => 완전히 독립된 작업 공간을 만들 수 있다. 

checkout => 독립된 작업 공간인 브랜치를 자유롭게 이동할 수 있다. 

merge => 브랜치와 브랜치간 내용을 병합 할 수 있다. 


동료와 함께 작업하려면?

복사한다? usb에 받아서 복사한다. 

복사는 단방향이다. 한번 주고 동료가 작업한 경과를 돌려받기 위해선 너무나 많은 어려움이 예상된다.


git은 "리모트 저장소"를 지원한다.

리모트 저장소가 있다면?

리모트 저장소 또한 원본 git저장소와 동일한 저장소이다. 리모트 저장소를 경유하여 함께 작업할 동료도 완전히 동일한 저장소를 다운로드 받을 수 있으며, 동일한 방식으로 작업할 수 있다. 


리모트 저장소에서 저장소 다운로드

리모트 저장소에서 처음으로 git저장소를 다운로드 받는 것을 복사본을 만든다는 의미로 clone이라 한다.


clone remote.com/projectA


리모트 저장소의 변경 내용 업데이트

리모트 저장소의 변경된 내용을 로컬(내 컴퓨터) 저장소에 적용하는 작업을 Pull이라 한다. 이 때 브랜치 병합과 같은 병합이 발생한다.

pull origin


내 저장소(로컬저장소)의 변경 내용 리모트로 전송하기

로컬(내 컴퓨터) 저장소에서 작업한 내용을 리모트 저장소로 보내는 작업을 Push라 한다. 함께 작업하는 동료에서 변경상항을 전송하기 위해선 리모트 저장소를 경유해야 한다는 것을 알 수 있다. 

push origin

Posted by slender ankles
,