목표 : 깃 전략 사용하기

사용할 깃 전략 : 간략화된 Git-flow 전략

Master Branch

• 실제로 완성된 버전의 브랜치.
• 오류가 (거의) 없는 안정된 버전이다.
• 특정한 시점의 Develop 브랜치를 Master 브랜치와 머지해서 만든다.
• 마스터 버전의 오류가 심각하다 & 디벨롭과 많이 차이가 크다면 핫픽스 브랜치를 적용 할 수도 있음
  • 근데 그냥 마스터 수정해서 올려도 되므로 핫픽스 브랜치를 굳이 안 나눠도 되긴 함..
• 기본적으로 마스터 브랜치는 직접적으로 수정하지 않는다.
  • 리포지토리 소유자를 제외하고 마스터 브랜치 수정권한을 빼도록 설정 (?)

Develop Branch

• 개발중인 Feature 들을 모아서 테스트 해볼 수 있도록 중간 작업물들을 올리는 브랜치 이다.
• Feature 브랜치를 만들때 기본이 되는 브랜치 이다.
• Feature 브랜치들과 주기적으로 머지가 일어 날 수 있음.
• Master 브랜치에 수정사항이 생긴다면 마스터의 변동사항을 바로 반영해 줘야 한다.
• Develop 브랜치의 직접적인 수정은 가급적이면 하지 않는다.
  • PR이 있을때만 수정할수 있도록 설정할 수도 있음 (깃헙 무료는 되려나..?)

Feature Branch

• 특정한 기능 / 내가 따로 구현하는 것들을 별도 브랜치로 분리하고 싶을때 적용한다.
• Feature 브랜치는 최신화된 Develop 브랜치에서 만든다.
• Feature 브랜치의 이름은 feature/(name) 으로 만든다.
  • 브랜치의 name은 영문 혹은 숫자로 쓴다.
  • ex) feature/wheel, feature/ksc/map999
• 필요하다면 Develop 브랜치를 자유롭게 머지하여 쓴다.

그림으로 보는 우리의 Git-Flow전략

1. 동그라미가 하나의 커밋을 의미한다.
2. 가로 화살표는 브랜치 병합 혹은 브랜치 생성을 의미한다.
3. 세로 화살표는 브랜치의 시간 흐름을 나타낸다.

최초 세팅

디벨롭 브랜치 생성

피쳐 브랜치 생성

개발중

푸시 요청

자신 브랜치에 머지 및 수정

맵 제작자도 병합

신규 브랜치 생성 및 디벨롭 최신 버전 푸시

마스터 브랜치 머지

장점?

• 안정된 Master 버전을 얻을 수 있다.
• Develop 에서 다양한 테스트 / 중간 결과물을 볼 수 있다
• Feature 에서 유연하게 쓸수있는 브랜치를 얻을 수 있다.

단점?

• 이해가 복잡한 깃 전략에 적응하기 어려울 수 있다..
• 깃 커밋 하나 하는데 복잡한 절차가 필요하다.
• 모든 사람이 같은 규약을 따라야 한다.
  • ex) 병합시 모두 머지 사용, 브랜치 전략 이해하고 쓰기 등

기본적인 깃 규약

1. 실행이 안되는 코드들(컴파일 안되거나, 테스트 중인 코드)은 디벨롭 & 마스터에 푸시 하지 않는다
   • 개인이 작업하는 피쳐 브랜치라면 상관없음
2. 피쳐 브랜치에서 디벨롭 브랜치로 병합 할 때는 merge를 사용한다. (Rebase는 쓰지 않도록)
   • 병합할때 Rebase 쓰지 않는 이유는 궁금하면 이야기해드림….
   • https://kghworks.tistory.com/133 아님 이거 참고
3. 가급적이면 피쳐 브랜치를 길게 가져가지 않도록 한다. (권장)
   • 내가 작업한 피쳐 브랜치가 머지 되었다면?
   • 가급적 로컬 브랜치를 지우고, 디벨롭 브랜치에서 피쳐 브랜치를 새로 만든다.
   • 작업이 안 끝난 브랜치를 테스트용으로 올려줬다. 이런건 굳이 새로 만들지 않아도 되긴 함.
4. 용량이 매우 큰 에셋 혹은 저작권이 걱정되는 파일들은..?
   • BigAssets 폴더에 올리고, 별도 구글 드라이브로 공유한다.
   • .gitignore 설정 및 폴더 설정 해둘 예정