Git 정리 #1

깃에 대해 정리 해볼려 한다.

 

 

 

Git 이란?

소스코드를 효율적으로 관리하기 위해 개발된 분산형 버전 관리 시스템 이다.

 

Git이 필요한 이유는?

무분별하게 파일을 만들어놓거나 통일성 없이 코드를 관리 한다면 어느 파일이 최신인지 어떤 부분이 변경 되어있는지 파악하는데 어려움이 있기 때문에 필요하다 생각한다.

협업 시 여러 명이 동시에 편집하거나 기능을 추가 했을 때 혼돈의 카오스가 나타날 수 있기 때문에 필요하다고 생각한다.

 

Git을 왜 사용해야 하는지?

소스 코드가 변경된 이력을 쉽게 파악 할 수 있으며, 특정 시점에 저장된 버전과 비교하거나 특정 시점으로 되돌아 갈 수 있다.

개인 또는 협업 시 빠르게 파악할 수 있기 때문에 사용해야 한다고 생각한다.

 

 

Git의 저장소

Remote Repository

 - 파일이 원격 저장소 전용 서버에서 관리되며 여러 사람이 함께 공유하기 위한 저장소 이다.

 

Local Repository

 - 내 PC에 파일이 저장되는 개인 전용 저장소 이다.

 

 

 

브랜치(branch)란?

 - 독립적으로 어떤 작업을 진행하기 위핸 개념이다. 필요에 의해 만들어지는 각각의 브랜치는 다른 브랜치의 영향을 받지 않기 때문에, 여러  작업을 동시에 진행할 수 있다.

 

통합 브랜치(Integration branch)

 - 배포할 수 있는 버전을 관리하는 브랜치다. (안정적인 상태를 유지하는 것이 중요)

 - 일반적으로 저장소를 처음 만들었을 때에 생기는 master 브랜치를 통합 브랜치로 사용한다

 

토픽 브랜치(Topic branch)

 - 기능 추가, 버그 수정과 같은 단위 작업을 위한 브랜치이다.

 - 보통 통합 브랜치(master) 로부터 만들어 내며, 특정 작업이 완료되면 통합 브랜치에 병합(merge)하는 방식으로 진행된다. 이러한 토픽 브랜치는 피처 브랜치 라고 부르기도 한다.

 

브랜치 통합하기 (merge, rebase)

merge와 rebase는 통합 브랜치에 토픽 브랜치를 통합하고자 하는 목적은 같으나, 특징은 약간 다르다.

merge는 변경 내용의 이력이 모두 그대로 남아 있기 때문에 이력이 복잡해진다.

rebase는 이력은 단순해지지만, 원래의 커밋 이력이 변경된다. 정확한 이력을 남겨야 할 필요가 있을 경우에는 사용하면 안된다.

ex) 토픽 브랜치에 통합 브랜치의 최신 코드를 적용할 경우에는 rebase를 사용, 통합 브랜치에 토픽 브랜치를 불러올 경우에는 우선 rebase를 한 후 merge

 

 

A successful Git branching model

위 사진의 모델에서는 크게 4가지 종류의 브랜치를 이용해서 개발을 진행한다.

- 메인 브랜치 (Main branch)

- 피처 브랜치 (Feature branch) or 토픽 브랜치 (Topic branch)

- 릴리즈 브랜치 (Release branch)

- 핫픽스 브랜치 (Hotfix branch)

 

메인 브랜치 (Main branch)

 master 브랜치와 develop 브랜치, 이 두종류의 브랜치를 보통 메인 브랜치로 사용한다.

 

master

 - 배포 가능한 상태만을 관리한다. 커밋할 때에는 태그를 사용하여 배포 번호를 기록한다.

 

develop

 - develop 브랜치는 통합 브랜치의 역할을 하며, 평소에는 이 브랜치를 기반으로 개발을 진행한다.

 

피처 브랜치 (Feature branch) or 토픽 브랜치 (Topic branch)

 새로운 기능 개발 및 버그 수정이 필요할 때에는 develop branch 로부터 분기한다. 이 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 원격으로는 관리하지 않는다. 개발이 완료되면 develop branch로 병합하여 다른 사람들과 공유한다.

 

릴리즈 브랜치 (Release branch)

 버그를 수정하거나 새로운 기능을 포함한 상태로 모든 기능이 정상적으로 동작하는지 확인한다. 릴리즈 브랜치의 이름은 관례적으로 브랜치 이름 앞에 'release-' 를 붙인다. 이 때, 다음 번 릴리즈를 위한 개발 작업은 develop branch 에서 계속 진행해 나가면 된다.

릴리즈를 위한 최종적인 버그 수정 등의 개발을 수행한다. 모든 준비를 마치고 배포 가능한 상태가 되면 master branch로 병합시키고, 병합한 커밋에 릴리즈 번호 태그를 추가한다. 릴리즈 브랜치에서 기능을 점검하며 발견한 버그 수정 사항은 develop branch에도 적용해 주어야 한다. 그러므로 배포 완료 후 develop branch에 대해서도 병합 작업을 수행해야 한다.

 

핫픽스 브랜치 (Hotfix branch)

배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master branch에서 분기하는 브랜치이다. 관례적으로 브랜치 이름 앞에 'hotfix-'를 붙인다. 

예를 들어 develop branch 에서 개발을 진행하고 있는 도중에 이전에 배포한 소스코드에 큰 버그가 발견된다면?....문제가 되는 부분을 빠르게 수정해 안정적으로 다시 배포해야 하는 상황이다. develop branch에서 문제가 되는 부분을 수정하여 배포 가능한 배전을 만들기에는 상당한 시간이 소요되고 안정성을 보장하기도 어렵다. 때문에 바로 배포가 가능한 master 브랜치에서 직접 브랜치를 만들어 필요한 부분만 수정한 후 다시 master 브랜치에 병합하여 배포한다. (이 때 만든 핫픽스 브랜치에서의 변경 사항은 develop branch에도 병합하여 문제가 되는 부분을 처리해 주어야 한다)

 

 

작성한 코드 깃헙에 올리기

프로젝트가 있는 경로로 이동 후

git init
git remote add origin 주소
git add .
git commit -m "내용"
git push origin master

 

브랜치 만들고 브랜치 전환하기

git branch 브랜치이름
git checkout 브랜치

* -b 옵션을 넣으면 브랜치 작성과 체크아웃을 한꺼번에 실행할 수 있다

git checkout -b 브랜치이름

 

 

브랜치 병합하기

git checkout master
git merge 브랜치이름

 

브랜치 삭제하기

git branch -d 브랜치이름
git branch -D 브랜치이름

error: The branch '브랜치이름' is not fully merged. 블라블라~ 라고 나온다면 해당 브랜치가 아직 merge 하지 않은 커밋을 담고 있기 때문에 git branch -d 명령으로 삭제 되지 않는다. 따라서 merge하지 않은 브랜치를 강제로 삭제하려면 -D 옵션으로 삭제한다

 

 

여러 브랜치로 동시에 작업 충돌 해결하기

(같은 화면을 틀리게 작업 했을 때)

git branch test
git branch test1
git branch test2
test2 branch로 코드 작성 후
git add .
git commit -m "내용"
git checkout test1
test1 branch로 코드 작성 후
git add .
git commit -m "내용"
git checkout master

test2 merge

이렇게 하면 fast-forward 병합이 실행된다. 이번에는 test1 브랜치를 병합해 본다.

git merge test1

CONFLICT (충돌) 이라 나온다. 그 이유는 각각의 브랜치에 변경한 내용이 같은 행에 포함되어 있기 때문에 충돌이 일어난거다.

ex) test2 branch 10행에 a를 작성, test1 branch 10행에 b를 작성

 

충돌 후 IDE에서 나옴

충돌이 일어난 부분은 이렇게 나오게 된다. 충돌이 일어난 부분은 일일이 확인해서 수정해야 한다.

충돌 부분을 수정 후 다시 커밋하면 된다.

git add .
git commit -m "내용"

 

rebase로 병합하기

일단 이전에서 진행했던 병합을 취소한다.

git reset --hard HEAD~

test1 브랜치로 전환해 master 브랜치에 rebase를 시킨다

git checkout test1
git rebase master

merge 와 마찬가지로 충돌이 있기 떄문에 충돌난 내용을 변경한 후 진행

git add .git 
rebase --continue
git checkout master
git merge test1

 

 

커밋 변경하기

--amend

같은 브랜치 상에서 이전에 커밋했던 내용에 새로운 내용을 추가하거나 설명을 수정할 수 있다

ex) 누락된 파일을 새로 추가하거나, 기존의 파일을 업데이트 해야 할 때, 이전 커밋의 설명을 변경하고 싶을 때

 

revert

특정 커밋의 내용을 삭제할 수 있다. rebase -i, reset 명령어를 통해 커밋을 삭제할 수도 있지만, 해당 커밋이 이미 공개된 상태인 경우에는 이러한 삭제 작업을 함부로 하기 어렵다. 이럴 때 revert 명령어를 이용해서 특정 커밋의 내용을 지우는 새로운 커밋을 만들어 보다 안전하게 처리할 수 있다.

ex) 이전에 작성한 커밋을 안전하게 지우고 싶을 때

 

 

reset

더 이상 필요 없어진 커밋들을 버릴 수 있다.

 

ammend로 커밋내용 수정하기

코드 작성 후 
git add .
git commit "내용"
git log
(로그를 치면 커밋내용과 시간 정보등이 나옴)
git commit --amend
(vi 편집기에서 커밋 내용을 수정한 후 저장종료 한다)
git log
(변경완료)

 

 

revert 로 커밋내용 삭제하기

git revert HEAD
vi 편집기에서 삭제
git log
(변경완료)

 

 

참:https://nvie.com/posts/a-successful-git-branching-model/

A successful Git branching model

https://git-scm.com/book/ko/v2/

Git - Book

https://backlog.com/git-tutorial/kr/stepup/stepup7_1.html