[25일차] 50일 포트폴리오 챌린지

본 포스팅은 패스트캠퍼스 환급 챌린지 참여를 위해 작성하였습니다.

https://bit.ly/43z0P6S 

패스트캠퍼스 [직장인 실무교육]

---

---

 

Git Flow 전략

Git을 사용하는 기본적인 명령어

• Commit
• Push
• Pull

Git Flow 전략

• Git을 사용하여 개발하는 환경에서
• Branch 간의 문제 없이 배포까지 안정적으로 할 수 있도록
• Branch를 관리하는 전략이다.

주요 Branch

1. Main(=Master): 배포(Release) 이력을 관리하기 위해 사용한다. 즉, 배포 가능한 상태만을 관리한다.
2. Dev: 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다. 즉, 모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 develop 브랜치를 ‘Main(=Master)’ 브랜치에 병합(merge)한다.평소에는 이 브랜치를 기반으로 개발을 진행한다.
3. Feature: feature 브랜치는 새로운 기능 개발 및 버그 수정이 필요할 때마다 ‘develop’ 브랜치로부터 분기한다. feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에, 자신의 로컬 저장소에서 관리한다. 개발이 완료되면 ‘develop’ 브랜치로 병합(merge)하여 다른 사람들과 공유한다.
   1. ‘develop’ 브랜치에서 새로운 기능에 대한 feature 브랜치를 분기한다.
   2. 새로운 기능에 대한 작업 수행한다.
   3. 작업이 끝나면 ‘develop’ 브랜치로 병합(merge)한다.
   4. 더 이상 필요하지 않은 feature 브랜치는 삭제한다.
   5. 새로운 기능에 대한 ‘feature’ 브랜치를 중앙 원격 저장소에 올린다.(push)
4. Release: 배포를 위한 전용 브랜치를 사용함으로써 한 팀이 해당 배포를 준비하는 동안 다른 팀은 다음 배포를 위한 기능 개발을 계속할 수 있다. 즉, 딱딱 끊어지는 개발 단계를 정의하기에 아주 좋다. 예를 들어, ‘이번 주에 버전 1.3 배포를 목표로 한다!’라고 팀 구성원들과 쉽게 소통하고 합의할 수 있다는 말이다.
5. Hotfix: 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, ‘main’ 브랜치에서 분기하는 브랜치이다. ‘develop’ 브랜치에서 문제가 되는 부분을 수정하여 배포 가능한 버전을 만들기에는 시간도 많이 소요되고 안정성을 보장하기도 어려우므로 바로 배포가 가능한 ‘main’ 브랜치에서 직접 브랜치를 만들어 필요한 부분만을 수정한 후 다시 ‘main’브랜치에 병합하여 이를 배포해야 하는 것이다.