Configuration Management

Git (브랜치, 태그)

알로그 2020. 11. 7. 23:07
반응형

Git 브랜치와 태그에 대해 알아보자.

 

브랜치(Branch)

말그대로 하나의 가지(Branch)를 쳐서 독립적으로 개발을 진행하기 위한 방법이다.

예를들어, 메인 브랜치(보통 master or develop)이 있고 개발자 A는 Feature1에 관한 기능을 개발하고 개발자 B는 Feature2에 관한 기능을 개발한다고 가정하자. 

 

그럼 각 개발자들은 메인 브랜치를 기반으로 새로운 브랜치를 생성해서 작업을 한다.

해당 기능 개발이 완료되면 다시 메인 브랜치로 커밋하는 구조이다.

 

 

이때, 서로 독립적인 기능을 개발한다면 상관이 없지만 겹치는 소스코드가 있다면 충돌(Conflict)가 날 가능성이 있다.

충돌이 날 경우 Git에서 충돌난 부분을 알려주기 때문에 해당 영역 소스코드를 수정해서 다시 커밋을 하면 된다.

 

예) 충돌 난 경우 표시

<<< HEAD (본인이 수정한 소스코드)

충돌난 코드

======

충돌난 코드

>>> 다른 브랜치 (다른 사람이 수정한 소스코드)

 

 

<브랜치 기본 명렁어>

# 현재 브랜치 확인
git branch

# 브랜치 생성
git branch "branchname"

# 브랜치 이동
git checkout "branchname"

# 브랜치 생성과 이동 동시에 진행
git checkout -b "branchname"

# 브랜치 간 병합
git merge "branchname"

# 브랜치 삭제
git branch -d "branchname"

# 브랜치 rebase 병합
git rebase "branchname"

* merge와 rebase의 가장 큰 차이는 브랜치간 병합할 때, 히스토리 관리를 어떻게 하느냐이다.

이 부분에 대해서는 별도의 포스팅으로 설명하는것이 좋을 것 같다.

 

 

브랜치를 어떻게 운용할 것인가에 대해서는 완벽한 정답은 없다.

각 팀마다 리소스나 정책이 다르기 때문에 가장 적합한 브랜치 운용 정책을 가지는 것이 중요하다.

아래는 성공적으로 브랜치 운용을 하기 위한 모델에 대한 설명인데 도움이 될 것 같다.

 

메인 브랜치인 master 브랜치가 있고, 해당 브랜치에서는 태그만 등록한다.

실제 주 개발 브랜치는 develop 브랜치를 운용하고 각 feature담당자마다 feature 브랜치를 가지고 개발이 완료되면 develop 브랜치에 merge 한다.

 

그리고 제품을 릴리즈 하기위한 release 브랜치가 따로 존재하고, 긴급한 이슈가 생겼을 때 운용되는 hotfix 브랜치가 존재한다.

 

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

 

A successful Git branching model

In this post I present a Git branching strategy for developing and releasing software as I’ve used it in many of my projects, and which has turned out to be very successful.

nvie.com

 

태그(Tag)

# 태그목록 확인
git tag

# 태그 생성
git tag "tagname"

# 태그 삭제
git tag -d "tagname"
반응형

'Configuration Management' 카테고리의 다른 글

repo 명령어 정리  (0) 2021.02.20
새로 생성한 파일까지 git diff로 patch 생성  (0) 2020.11.07
Git (설치, 기본 명령어)  (0) 2020.11.07
Git (이론)  (0) 2020.11.07
코드 품질 분석기  (0) 2018.07.01