[Git] Git을 활용한 프로젝트 관리

코드프레소 Java 웹 개발 체험단 활동을 1주차 하면서 Java와 Git의 개념을 다시 잡고 새로운 지식도 습득해서 많은 공부가 되고 있다. 현재 실무자가 알려주는 Git 활용한 프로젝트 관리 강의를 듣고 있는데 이번 강의는 Git Flow의 전반적인 내용을 수강하고 있다.

 

이번엔 Git 브랜치 전략 및 실습 관련 포스팅을 하려 한다.

 

 

출처: codepresso

브랜치(Branch)

• 본래의 소스코드로부터 파생한 독립적인 작업 공간
• 최신 커밋을 가리키는 일종의 포인터
• 매우 가볍다.
• 생성, 이동, 병합(merge)이 매우 쉽다.
• Git은 기본적으로 master 브랜치를 생성한다.

현재 작업중인 브랜치를 확인하는 명령어

$ git branch

$ git branch -v

• -v 옵션은 브랜치들의 버전을 볼 수 있다. 
• master 브랜치는 첫 번째 커밋을 만들어야 생성된 커밋을 가리킬 수 있다.

개인적으로 -v 옵션을 붙이는 걸 선호한다. 프로젝트를 하면서 해당 브랜치 버전을 확인하면서 작업하는 것이 조금 더 가시성이 좋다고 생각했다.

HEAD

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

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

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

브랜치 생성

$ git branch 생성할 브랜치명

출처: codepresso

브랜치 이동

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

$ git checkout feature/login

$ git branch

$ git log

 

출처: codepresso

이렇게 HEAD가 master가 아니라 feature 브랜치를 가리키게 된다.

 

feature 브랜치에서 작업하고 커밋 작업을 하게 되면

출처: codepresso

위와 같은 모습이 된다.

 

master 브랜치로 이동

$ git checkout master

$ git branch -v

$ git log

개발 중 이슈가 발생하면?

master 브랜치에서 issue 브랜치를 생성해 수정하고 반영하는 가이드 한다.

 

issue 브랜치를 생성과 동시에 이동

$ git checkout -b issue

 

이후 branch에서 코드를 수정 후, add와 commit 작업을 하게 되면

출처: codepresso

이와 같이 HEAD는 issue, issue는 commit 5를 가리키게 된다.

 

브랜치 병합

기준이 되는 브랜치로 이동해서 병합해야 한다.

$ git checkout master

합쳐질 브랜치를 병합한다.

$ git merge issue

$ git merge feature/login

 

Fast-forward Merge

브랜치의 위치만 최신 커밋으로 이동시키는 방식

 

출처: codepresso

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

1. master와 feature/login 브랜치의 공통 부모 커밋
2. master 브랜치의 최신 커밋
3. feature/login 브랜치의 최신 커밋

브랜치 삭제

더 이상 사용되지 않는 브랜치는 삭제

$ git branch -d issue

 

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

서로 다른 파일의 병합은 성공할 수 있다. 그러나 같은 파일에서 코드를 수정하고 커밋한 다음 병합을 진행하면 충돌이 발생된다.

Merge 충돌

두 개의 변경점이 합쳐질 때 변경점 자체가 서로 충돌한다.

출처: codepresso

 

변경사항의 충돌(conflict)

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

1. 직접 merge 하기
2. 툴을 이용해서 merge하기

직접 merge하는 방법은 merge를 한 브랜치에서 충돌이 일어난 파일을 vi 에디터로 수정하여 저장하면 된다.

mergeTool은 $ git mergetool 명령어로 들어가서 vimdiff로 충돌을 해결할 수 있다.

총 4개의 view가 있다 왼쪽 1번째 기준으로

1. master 브랜치 변경점
2. 두 브랜치의 공통 분모
3. feature/login 브랜치 변경점
4. 실제 working directory에 있는 파일 상태 출력 및 수정

 

만약 vimdiff 입력 시 아래 메시지가 발생하면 아래 설정 후 재시도

bc is not available 메세지

코드를 수정 후 마찬가지로 add, commit 작업을 하면 

출처: codepresso

현재와 같은 상태가 된다.

 

Git Tag

특정 브랜치 위에서 생성이 된다. 특정 시점에 태그라는 꼬림표가 달리는데 태그 안에는 특정 정보가 담겨져 있다.

• 특정 시점의 소스코드 정보를 기록한다.
• 프로젝트 진행 중 의미있는 시점의 커밋을 태깅한 것

의미있는 시점이란?

• 1차 목표 기능 개발 완료되었을 때, 
• 매우 중요한 이슈가 해결되었을 때,
• 기능 개발 완료 및 테스트까지 모두 완료하여 통과하였을 때,
• 고객에게 소프트웨어를 배포할 때,

Git 태그의 종류

• Lightweight 태그

버전명과 같은 태그명만 남기는 태그

$ git tag [태그명]

 

• Annotated 태그

Git 데이터베이스에 태그를 만든 사람의 이름, 이메일, 태그 생성 날짜, 태그 메세지 등을 저장한 태그

$ git tag -a [태그명] -m [태그 메세지]

 

git show [태그명]을 하면 기존의 커밋 id아닌 태그명으로 쉽게 log를 조회할 수 있다.

 

특정 시점의 커밋 태그하기

커밋 ID 값을 인자로 태깅하기

$ git tag -a v0.1 [커밋ID] -m "fix issue number-1"

$ git log --oneline

 

태그 활용 전략

Git을 이용한 태그 생성 시점은 조직마다 다를 수 있다.

• 태그 생성 시점?
• 태그명 규칙?
• 태그 메세지 규칙?

 

※중요한 점은 소스코드의 효율적인 관리를 위해 태그 생성 시점과 방법에 대해서 일관성 있는 규칙을 정해 프로젝트 팀원 모두가 준수할 수 있도록 정책화 해야 한다.

 

 

 

 

 

코드프레소 URL: https://www.codepresso.kr/

프리미엄 IT 교육 서비스 - 코드프레소