[git / flow 전략] git 브랜치 따기 / 운영전략 (develop / feature)

git 원격저장소에 레파지토리를 만들면 

master 브랜치가 생성된다.

주된 브랜치로, 얘가 가장 큰 줄기. 기둥이라고 보면 된다.

 

그런데, 나같은 꼬꼬마가 기능개발을 완료했다고 마스터에 몽땅 푸쉬를 해버리면

마스터 브랜치 자체를 롤백해야 되는 부담스러운 상황이 연출 될 수 있다.

 

그것은 안될말.

최대한 안전하게 마스터 브랜치를 보호하고자

이런저런 브랜치를 따서 형상관리 하려는 전략이 바로 git flow 전략이다.

 

일단 마스터에는 꼬꼬마가 접근 못하게 하려는게 원칙이다.

근데, 생각해보니 이것도 조금 불안한 것 같아 개발용 브랜치를 서브로 하나 더 따려고 한다. 여기서는 꼬꼬마들이 작업한 내용을 올려서 즈들끼리 병합하고 스테이징 하는 용도로 사용할 것이다. 

이것이 새로 생성할 master의 브랜치 "develop"브랜치이다.

그럼 꼬꼬마들은 어디다가 개발하느냐?

이 develop 브랜치의 브랜치를 새로이 따서 거기에 하면 되는데, 이 브랜치를 보통 feature/forest 이런식으로 이름 짓는다.

그리고 이 feature 단위의 브랜치들은 구현하려고 하는 "기능"별로 브랜치를 새로 생성했다가 지웠다가 하게 된다.

 

예를 들어, 우리 프로젝트에서 로그인기능, 카운트 기능을 구현하려고 한다면

master의 브랜치인 develop 브랜치에서

feature/forest 브랜치를 새로 따서 로그인 기능만 구현한 뒤, develop 브랜치에 머지하고 feature/forest 브랜치를 홀랑 지워버린다.

feature/soo 브랜치를 새로 따서 카운트 기능만 구현한 뒤, develop 브랜치에 머지하고 feature/soo 브랜치를 또 홀랑 지워버리는 것이다.

develop 브랜치에서 각각의 기능별 feature브랜치들을 다 병합한 뒤에 굴러가는데 문제가 없다~~~ 싶으면

최종적으로 master에 머지하고 푸쉬해주면 되는 것이다.

 

 

이제 테스트를 해보자. 

일단 내가 가지고 있는 브랜치가 뭐가 있는지 보겠다.

 git branch  //현재 원격 저장소에 있는 브랜치 확인

 

** 출력내용 **

 

마스터밖에 없다.

여기서부터 시작하자.

 

1. develop 브랜치 만들기

git branch develop  // 만들어라 브랜치. develop 이라는 이름을 가진.

 

깃 브랜치 리스트르 확인해보면

develop과 master 두개가 나타난다.

그중에 현재 작업중인 브랜치는 왼쪽에 *로 표시된다.

나는 *master 에서 작업중이라는 것을 알 수 있다.

 

이제 develop으로 옮겨가 보자.

git checkout develop  // 옮겨라. develop으로

터미널을 보면, () 내부가 마스터에서 디벨롭으로 변한것을 알 수 있다.

또 깃 브랜치 내역을 확인해 보아도 * 표시가 디벨롭 브랜치로 옮겨 붙어있다.

우리는 지금 develop 브랜치로 이동을 한 것이다.

 

그렇다면 develop에 있는 상태에서 브랜치를 더 따자. 나는 두개를 따볼것이다. (그냥 연습이니까)

하나는 feature/forest1, 다른 하나는 feature/forest2로 만들것이다.

보이는가!? 두개의 브랜치가 새로이 생성되었다.

feature/~ 에서 작업을 하고

develop에서 모두 병합을 한 뒤에

master에 최종 반영 할 것이다.

 

기능구현은 컴포넌트별로 할 것이므로 

구별하기 쉽기 위해 다음과 같이 파일을 구분 해보았다.

index - 마스터 브랜치

sub1 - develop 브랜치

sub2 - feature/forest1 브랜치

sub3 - feature/forest2 브랜치

 

구분해놓는 이유는 그냥 보기 편하라고.

이제 기능 구현을 해보도록 하겠다.

sub3 페이지에 아무거나 써주도록 하자.

개발을 완성했다 치자.

 

이제 feature/forest2 에서 

develop에 머지해주도록 한다.

 git checkout feature/forest2    //forest2 브랜치로 가자.
 
 git add .    // 저장소에 더할 파일이 있다.
 git commit -m "feature/forest2 test"    //로컬에 저장을 하겠다.
 
 git checkout develop   // develop브랜치로 가자. 
 git merge feature/forest2  // forest2 브랜치를 develop 브랜치에 합쳐라.

 

feature/forest1 로 브랜치를 옮겨보면

sub3에서 수정하고 develop에 merge 했던 내용이 반영이 안되어있다.

feature/forest1 에서는 sub2 파일에다가 기능구현 해주도록 하자.

앗! 완성됐다.

이제 똑같이 develop에 합병해주도록 하자.

합병할 때, feature/forest2  에서 변경한 내용도 합병해줄 거냐고 묻는다.

합병 해주면 된다.

그런데 이런 게 부담되면 내꺼 커밋하기 전에 git pull 한번 땡기고 시작하면 된다.

일단은 수신된 내용을 수락하고 병합을 완료 한다.

 

 

--------> 현재 상태 : feature/forest2 와 feature/forest1 에서 모두 기능개발을 마친 후 develop 브랜치에 합병함.

이제 feature/forest2 와 feature/forest1 브랜치는 쓸모를 다했다.

기능개발이 끝났기 때문이다.

feature 브랜치는 각각의 기능을 개발하는 동안 존재하기 때문에 그 쓸모가 다하게 되면 지워주는 것이 좋다.

기능 구현 할 때 생성하고 완료되면 지우기를 반복하는 것이다.

 

둘다 삭제해보자.

병합이 안되어서 지워지지 않는다고 할 때에는 

병합 -> 커밋까지 완료 한 뒤에 지워주면 된다.

 

 

정리하기 

(develop) git branch feature/forest    //깃 브랜치 작업자용으로 생성
(develop) git checkout feature/forest  //깃 브랜치 작업자용으로 변경


개발 완료 후 
(feature/forest) git add .
(feature/forest) git commit -m "기능 구현 완료"


브랜치 병합
(feature/forest) git checkout develop
(develop) git merge feature/forest

브랜치 삭제
(develop) git branch -d feature/forest

 

푸쉬는 내가 안함

주로 책임님이 해주실 예정

git commit 까지만 완료해주면 된다.

 

 

 

 

끗!