[Git] Git 작업은 Branch에서!

minidoo·2021년 3월 5일
0

Git

목록 보기
2/3
post-thumbnail

Branch

독립적으로 어떤 작업을 진행하기 위한 개념
commit 사이를 가볍게 이동할 수 있는 어떤 포인터

  • 각 브랜치는 다른 브랜치의 영향을 받지 않기 때문에 여러 작업을 동시에 진행할 수 있음
  • 다른 브랜치와 병합(Merge) 함으로써 작업한 내용을 새로운 하나의 브랜치로 모을 수 있음
  • 작업의 기록을 중간 중간 남겨, 문제가 발생했을 경우 원인이 되는 작업을 찾고 대책을 세우기 쉬움 (작업 단위)

1. 브랜치(Branch) 의 동작원리

Git의 Commit은 변경사항을 기록하지 않고, 일련의 스냅샷으로 기록

git add README test.rb LICENSE		// staging area (add)
git commit -m "first commit"		// staged area	(commit)

  1. 추가된 파일들의 Blob 생성
    ( Blob ? 일련의 데이터를 처리하거나 간접 참조하는 객체 )
  2. 루트 디렉토리와 각 하위 디렉토리의 트리 개체체크섬과 함께 저장소에 저장
  3. 커밋 개체 생성
  4. 메타 데이터와 루트 디렉토리 트리 개체를 가리키는 포인터 정보(스냅샷)을 커밋 개체에 넣어 저장

⇒ 새로 생성된 현재 트리 개체(tree)부모 커밋 개체(parent)의 정보를 저장

* master → main

Git은 최초로 커밋하면 master 라는 이름의 브랜치를 만들어서 자동으로 가장 마지막 커밋을 가리킨다.

2020년 10월 이후 Github는 신규 repository의 기본 브런치를 main으로 사용한다.

$ git config --global init.defaultBranch main

* 작업 중인 브랜치 파악하기

Git은 HEAD라는 특수한 포인터가 존재하며, 이 포인터는 지금 작업하는 로컬 브랜치를 가리킨다.

변경된 브랜치에서 작업을 진행하면, 해당 브랜치는 독립적인 브랜치 히스토리를 갖게 된다.

2. 브랜치(Branch) 종류

master / develop / feature / release / hotfix

항상 유지일정 기간 유지
master : 제품으로 출시될 수 있는 브랜치
develop : 다음 출시 버전을 개발하는 브랜치
feature : 기능을 개발하는 브랜치
release : 이번 출시 버전을 준비하는 브랜치
hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

Master Branch

제품으로 출시될 수 있는 브랜치

배포(Release) 이력을 관리하기 위해 사용, 즉 배포 가능한 상태만을 관리한다.

Release 작업 끝난 결과물을 Master Branch에 합치는 것으로 코드를 수정할 일은 거의 없다.

주로 taging(ex. 버전별 관리)을 달아 놓는다.

Develop Branch

다음 출시 버전을 개발하는 브랜치 ( default )

기능 개발을 위한 브랜치들(feature)을 병합하기 위해 사용한다.

배포 가능한 안정적인 상태라면 develop 브랜치를 master 브랜치에 병합(merge) 한다.

Feature Branch

기능을 개발하는 브랜치

feature 브랜치는 새로운 기능을 개발할 때 마다 develop 브랜치로부터 분기한다.

Feature 브랜치는 협업하지 않는다면 로컬에서만 관리하며, 기능 개발이 완료되면 develop 브랜치로 병합(merge) 한다.

작업이 완료된 후에는 featrue 브랜치는 삭제하여 브랜치를 정리하는 것을 권장한다.

Release Branch

이번 출시 버전을 준비하는 브랜치

배포를 위한 전용 브랜치로 A팀이 해당 배포를 준비하는 동안 B팀은 다음 배포를 위한 기능 개발을 계속할 수 있다.

develop 브런치를 release 브런치에 병합하고, 최종적으로 master 브랜치에 병합하여 마무리한다.

Hotfix Branch

출시 버전에서 발생한 버그를 수정하는 브랜치

배포한 버전에서 긴급하게 수정을 해야할 필요가 있을 경우, master 브랜치에서 분기하는 브랜치이다.

⇒ 외부 API를 사용하는 경우, feature에 기능을 추가하고 master까지 병합했다고 가정해보자. 외부 업체는 테스트를 진행할 것이고, 문제가 있을 때마다 코드를 수정하고 다시 배포해야하는 불편함이 생길 것이다.

⇒ 따라서 브랜치는 팀, 프로젝트에 따라 운영방향을 잡아야 효율적으로 운영할 수 있다.


Thanks to 팀장님 🙂🙃🙂

0개의 댓글