이 글은 코드프레소 Java 웹 개발 체험단 활동 중 실무자가 알려주는 Git 활용한 프로젝트 관리 강좌를 기반으로 작성하였습니다.
코드프레소 URL: https://www.codepresso.kr/
강의 목차
먼저 강의 목차는 아래 그림과 같이 구성되어 있습니다.
Git 브랜치의 이해
두 번째 챕터 Git 브랜치의 이해에서는 Git 브랜치의 개념을 설명하고 실습을 통해 브랜치를 활용하는 법을 배웁니다.
브랜치(branch)
- 본래의 소스코드로 부터 파생한 독립적인 작업 공간
- 최신 커밋을 가리키는 일종의 포인터
- 매우 가볍다.
- 생성, 이동, 병합(merge)이 매우 쉽다.
Git 브랜치 실습을 위한 디렉토리 생성
master 브랜치
- Git은 기본적으로 master 브랜치를 생성한다.
- 현재 작업중인 브랜치를 확인하는 명령어
$ git branch
=> master 브랜치는 첫 번째 커밋을 만들어야 생성된 커밋을 가리킬 수 있기 때문에 git init 후 git branch 명령어를 사용해도 아무것도 출력이 안된다.
위 그림과 같이 commit 후 git branch 명령어를 사용하면 master브랜치를 가리킴을 볼 수 있다.
HEAD
- 현재 브랜치를 가리키는 일종의 포인터
- 현재 브랜치의 마지막 커밋에 대한 스냅샷
브랜치 생성
$ git branch (생성할 브랜치명)
- 브랜치 생성과 동시에 이동(checkout)
$ git checkout -b issue
브랜치 이동
$ git checkout (이동할 브랜치명)
- HEAD는 checkout 대상 브랜치로 이동한다.
- 로컬저장소의 상태는 HEAD가 가리키는 마지막 커밋이 최신이 된다.
- 작업 디렉토리의 파일 상태도 변경된다.
브랜치 병합
(1) 기준이 되는 브랜치로 이동해서 병합해야 한다.
issue 브랜치 -> master 브랜치
$ git check out master
(2) 합쳐질 브랜치를 병합한다.
$ git merge issue
Fast-forward Merge
브랜치의 위치만 최신 커밋으로 이동시키는 방식
3-way Merge
아래 3개 커밋을 모두 고려하여 병합하는 방식으로 3-way Merge의 결과는 새로운 커밋으로 생성됨
1) master와 feature-login 브랜치의 공통 부모 커밋
2) master 브랜치의 최신 커밋
3) feature-login 브랜치의 최신 커밋
브랜치 삭제
더 이상 사용되지 않는 브랜치는 삭제하기
$ git branch -d issue
변경사항의 충돌(conflict)
개발하는 기능의 목적에 맞게
어떤 변경사항을 어떻게 반영할지를 결정하고
수정하여 반영하는 것을
conflict을 해결하는 과정이라 한다.
1) 직접 merge 하기
2) 툴을 이용해서 merge 하기
Git에서 태그란?
- 태그는 특정 시점의 소스코드 정보를 기록함
- 프로젝트 진행중 의미있는 시점의 커밋을 태깅한 것
- 의미있는 시점이란?
- 1차 목표 기능 개발 완료되었을 때,- 매우 중요한 이슈가 해결되었을 때,
- 기능 개발 완료 및 테스트까지 모두 완료하여 통과하였을 때,
- 고객에게 소프트웨어를 배포할 때,
Git 태그의 종류
-
Lightweight 태그
버전명과 같은 태그명만 남기는 태그 -
Annotated 태그
Git 데이터베이스에 태그를 만든 사람의 이름, 이메일, 태그 생성 날짜, 태그 메시지 등을 저장한 태그
Git 태그 생성하기
-
Lightweight 태그 생성
$ git tag [태그명] -
Annotated 태그 생성
$ git tag - a [태그명] -m [태그 메시지]
특정 시점의 커밋 태그
1) 태깅하고자 하는 커밋의 ID 값 확인
$ git log --oneline
2) 커밋 ID 값을 인자로 태깅하기
$ git tag -a v0.1 [커밋ID] -m "fix issue number-1"
태그 활용 전략
- Git을 이용한 태그 생성 시점은 조직마다 다를 수 있다.
- 태그 생성 시점?
- 태그명 규칙?
- 태그 메시지 규칙중요한 것은 소스코드의 효율적인 관리를 위해
태그 생성 시점과 방법에 대해서 일관성 있는 규칙(프로세스)을 정해
프로젝트 팀원 모두가 준수할 수 있도록 정책화 해야 한다.
Git 브랜치 활용
세 번째 챕터인 Git 브랜치 활용에서는 Git 브랜치에 대한 활용을 위한GitFlow 모델의 개념을 알려주고 실습을 통해 GitFlow 모델을 배웁니다.
브랜치가 필요한 이유?
- 소프트웨어는 지속적으로 변경된다.
소프트웨어에 대한 변경은 개발 진행중에 또는 개발이 완료되어 사용 중인 제품에서 발생하는 문제점을 해결하거나 개선하기 위해 발생할 수 있다.
브랜치 활용 전략
- Git을 이용한 브랜치 활용 방식은 개인/조직마다 다를 수 있다.
- 브랜치 활용 전략은 소스코드의 효율적인 관리를 위해
프로젝트의 모든 리스크를 최소화하는 방향으로
일관되고 생산적인 방식으로 조직에 맞게 프로세스화 시켜야 한다.
Git Flow 모델
아래 브랜치를 활용하여 변경점을 관리하는 모델
- master branch
- develop branch
- feature branch
- release branch
- hotfix branch
master branch
- 실제 고객에게 릴리즈되는 브랜치(production)
- 모든 변경사항은 결국 master로 최종 반영되어야 함
develop branch
- 실제 개발의 중심이 되는 브랜치
- 즉, 모든 기능이 추가되고 버그가 수정되고,
고객에게 배포 가능한 수준이 되면
develop의 내용은 master에 최종 반영되어야 함 - 다음 배포할 기능 개발하는 브랜치
feature branch
- 기능을 개발하는 브랜치
- develop 브랜치로부터 분기되어 사용됨
(feature 브랜치의 단위? 기능, 스프린트 주기 등) - 기능 개발이 완료되거나 스프린트 주기가 종료되면
develop 브랜치로 내용 merge 후 브랜치 삭제됨
release branch
- 배포를 준비(검증, 이슈 수정 등) 하는 브랜치
- 배포 가능한 상태가 되면 master 브랜치로 병합
- release 브랜치에서 기능 점검시 발견한 이슈에 대한 수정사항은 반드시 develop에 병합해야 함
- 배포 준비가 완료되면, 최종 master로 병합하고 tag를 명시해야 함
hotfixs
- 배포한 버전에서 긴급하게 수정이 필요한 장애 및 버그 발생시 대응하는 브랜치
- hotfixs는 master로 부터 분기되며, 이슈가 수정되면 수정 사항은 master, develop 브랜치에 최종 반영되어야 함
