※ 이 글은 코드프레소 체험단 활동을 하면서 만들어졌습니다.
※ 실무자가 알려주는 Git 활용한 프로젝트 관리 강의입니다.
※ 코드프레소 바로가기

Git 브랜치

브랜치란?

• 기본 브랜치로부터 파생한 독립적인 작업 공간
• 최신 커밋을 가리키는 일종의 포인터
• 매우 가벼움
• 생성, 이동, 병합(merge)이 매우 쉬움

master브랜치

• Git은 기본적으로 master브랜치를 생성한다.
• master브랜치는 첫 번째 커밋을 만들어야 생성된 커밋을 가리킬수 있다.

Head

• 현재 브랜치를 가리키는 일종의 포인터
• 현재 브랜치의 마지막 커밋에 대한 스냅샷
  

새로운 기능 개발이 시작되면?

• 브랜치는 목적에 따라 분기할 수 있다.
• 브랜치 분기 전략은 조직에 따라 달라진다.
  

브랜치 이동(checkout)

$ git checkout 이동할 브랜치명

• Head는 checkout대상 브랜치로 이동한다.
• 로컬 저장소의 상태는 Head가 가리키는 마지막 커밋이 최신이되고,
• 작업 디렉토리의 파일 상태도 변경된다.

개발중 이슈가 발생하면?

• master브랜치에서 issue 라는 새로운 브랜치 생성
  $ git barnch issue
  $ git checkout issue
• 이후 이슈가 있는 파일을 고치고 add하고 commit 한다.

이슈 해결이 완료되면? - 브랜치 병합(merge)

• 기준이 되는 브랜치로 이동해서 병합한다.
  - issue브랜치에서 master브랜치로 이동
  - $ git checkout master
• 합쳐질 브랜치를 병합한다.
  - $ git merge issue
• 더이상 사용하지 않는 브랜치는 삭제하기
  - $ git branch -d issue

기능 개발이 완료되면?

모든 브랜치 병합한다.

3-way Merge

• 아래 3개 커밋을 모두 고려하여 병합하는 방식
• 3-way merge의 결과는 새로운 커밋으로 생성됨

브랜치 병합은 항상 성공하는가?

• 아니다! 머지해야하는 파일의 내용이 다를경우 병합되지 않는다
  

변경사항의 충돌(conflict)

• 개발하는 기능의 목적에 맞게 어떤 변경사항을 어떻게 반영할지 결정하고 수정하여 반영하는것을 conflict을 해결하는 과정이라 한다.

충돌의 해결

• 직접 merge하기
  - vi로 파일을 직접수정한다.
• mergetool 사용하기
  - 개발자의 의도대로 수정하고
  - conflict 기호 제거
  - 수정이 완료되면 저장후 종료
  - 나머지 3-way 창은 수정 없이 종료
• 병합이 제대로 되었는지 확인후, commit 생성

Git의 Tag

Git에서 태그란?

• 태그는 특정시점의 소스코르 정보를 기록함
• 프로젝트 진행중 의미있는 시점의 커밋을 태깅한것
• 의미있는 시점이란?
  - 1차 목표 기능 개발이 완료되었을때
  - 매우 중요한 이수가 해결되었을때
  - 기능 개발 완료및 테스트를 모두 통과하였을때
  - 고객에게 소프트웨어르 배포할때 등등..
  

Git 태그 종류및 생성하기

• Lightweigh 태그
  - 버전명과 같은 태그명만 남기는 태그
  - $ git tag 태그명
• Annotated 태그
  - Git DB에 태그를 작성자의 이름, 이메일, 태그생성날자 등을 저장하는 태그
  - $ git tag -a 태그명 -m 태그메세지

특정 시점의 커밋 태그하기

• 태깅하고자 하는 커밋의 ID값 확인
• 커밋 ID 값을 인자로 태깅하기
• $ git -a 태그명 커밋ID -m 태그메세지

Git 브랜치 활용 - GitFlow 모델

• master branch
• develop branch
• feature branch
• relese branch
• hotfix branch

master branch

• 실제 고객에게 릴리즈 되는 브랜치(production)
• 모든 변경사항은 결국 master로 최종 반영되어야 함

develop branch

• 실제 개발의 중심이 되는 브랜치
• 즉, 모든기능이 추가되고 버그가 수정되고, 고객에게 배포가능한 수준이 되면 develop의 내용은 master 에 최종 반영되어야 함
• 다음 배포할기능 개발하는 브랜치

feature branch

• 기능을 개발하는 브랜치
• develop브랜치로부터 부닉되어 사용됨
• 기능 개발이 완료되거나 스프린트 주가가 종료되면 develop브랜치로 내용 merge후 브랜치 삭제됨

relese branch

• 배포를 준비(검증,이슈수정 등) 하는 브랜치
• 배포가 가능한 상태가 되면 master 브랜치로 병합
• relese 브랜치에서 기능 점검시 발견한 이슈에 대한 수정사항은 반스시 develop에 병합해야함
• 배포 준비가 완료되면, 최종master로 병합하고 tag를 명시해야 함

hotfix branch

• 배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생시 대응하는 브랜치
• hotfix는 master로부터 분기되며, 이슈가 수정되면 수정사항은 master, develop브랜치에 최종 반영되어야 함