익명의 개발노트

[Wecode 45일차] git flow, unit test, git-rebase 본문

코딩일기/TIL

[Wecode 45일차] git flow, unit test, git-rebase

캡틴.JS 2019. 7. 16. 21:09
반응형

1. 깃 플로우

1) 마스터 브랜치는 최종 배포에 사용한다. 실제관리는 아키텍트나 PM들이 관리한다.

2) 통상 개발자는 develop 브랜치에서  feature브랜치를 따서 작성 후 develop 브랜치에 push한다. 

3) 마스터 브랜치에서 릴리즈 브랜치로 푸시하는 경우는 실제 배포할 상태가 된 경우에 생성하는 브랜치이다. 마스터 브랜치에서

    배포가 이루어 지므로, 릴리즈 브랜치를 마스터 브랜치로 merge한다.  나중에 이 배포버전을 찾기 쉽도록 태그를 만들어 현재

    병합되는 커밋이 뭔지 마킹해놓는다. 이 때 배포된 기능에 반영 될 수 있도록 develop 브랜치에도 함께 merge한다.

4) hot-fix 브랜치는 배포 후 운영 버전에 버그 발생시 긴급하게 버그를 수정해야할 경우에 만든다. 마스터 브랜치에 만들어둔

     태그로 부터 만든다.

 

2. unit test

   소프트웨어를 테스트하는 방법은 크게 3가지가 있다.

   1) E2E : (end to end) 처음부터 끝까지 하는 테스트다. 프론트, 백 등 모든 서버 가동시켜서 진행하며, 공수가 가장 크게 들고,

                 전체 테스트에서 10%만 하도록 권장한다. 여기서 이루어지는 테스트는 최종테스트이며, 궁극적으로는 사람눈에 보이는 것

                 들을 테스트 한다.

   2) Intergration :  한쪽만 구동하고 메세지 던져서 응답값 확인하는 방법, 여전히 비싸다.

   3) 유닛테스트 : 내 코드에서 테스트 할 수 있는 가장 작은 단위의 테스트이다. 어떤걸?? 함수를 테스트한다. 이것은 사람이 손으로

                               할 수 있으며, 코드로 코드를 테스트 할 수 있다.

  

   유닛테스트를 위한 툴이 있다. 백엔드 장고의 경우에는 unittest가 내장되어있고, 파이썬 같은 경우 파이테스트 라이브러리를 사용

   하면 된다.  프론트엔드의 경우에는 Mocha, chai, Jest 등이 있는데, 주로 Jest 를 사용한다.

 

3. git-rebase

    정의 : 커밋날짜 순으로 merge를 하며, 새로운 베이스에 새로운 순서대로 커밋 후 올리는 것이다.  

 //브랜치 예시
 
 0-0-0-0-a-b-c   
        \e-f-g

커밋한 날짜 순서 :  a > e > b > f > c > g 일 경우

그냥 merge 하면 a-e-b-f-c-g로 되어버린다.

이렇게 될 경우 큰 문제가 발생한다.

 

1. revert(되돌릴때)할 때 문제가 됨.

2. 깃 히스토리보기가 어려워짐.

 

왜냐면, 브랜치하나당 기능하나이다. 기능이 나눠서 사이사이에 들어가면 코드는 문제가 없겠지만, 되돌릴 때 많은 공수가 들어간다.

ex) 카카오 카풀기능, 택시반대로 결국 철회. 

 

체리픽도 공수가 크게 작용해서 의미가 없다.

 

가장이상적으로 만들기 위해서는 아래와 같이 만들어야 한다.

0-0-0-0-e-f-g-a-b-c

이것보다도 a-b-c 커밋을 하나의 커밋 d로 만들면 히스토리 관리도 쉬울 것이다.

0-0-0-0-e-f-g-d

a-b-c를 하나의 커밋으로 만드는 과정을 squash 라고한다. 

git rebase -i master
//master 자리는 리베이스의 기준이 되는 브랜치를 의미

리베이스는 합쳐질때 하나씩(한커밋) 합쳐진다. 합쳐질때마다 커밋 메세지를 남겨야한다.

 

위의 명령어를 치면면 어떤 브랜치를 pick, squash 할지 나온다. 

 

맨위꺼(가장 최신)만 pick이고, 나머지는 squash로 하면 하나씩 합쳐진다. 메세지는 처음꺼만 잘써놓으면 나머지는 메세지

 

안남겨도 된다.(어차피 하나로 합쳐지기 때문).

 

리베이스를 하고 하나씩 합쳐질때 충돌날 수도 있다. 

 

이러한 이유때문에 feature브랜치 하나당 기능하나로 사용하는게 맘편할 듯하다.

 

TIP : 중간중간 커밋은 WIP라고 남긴다.(work in progress 의미, 마지막 리베이스 할때 메세지만 잘쓰면됨.)

 

앞으로는 리베이스는 커밋 후 푸시 전에 합치고 푸시한다.

 

요약 : 깃 리베이스는 pull 하기 전에 리베이스를 먼저하고 pull을 하거나, pull후 커밋한 번 후 리베이스 한다.

반응형
Comments