gitHubFlow 전략
효율적인 깃허브 저장소 관리를 위해 브랜치 생성에 규칙을 만들어서 사용하는 방법론을
깃허브 브랜치 전략이라고 한다.
📌gitHubFlow 전략
GitHub에서 제안한 브랜치 모델 gitFlow 보다 간단하고 소규모 프로젝트에 많이 이용
master 브랜치 만을 사용하여 개발 및 배포 하며
feature/기능별 브랜치를 만들어 master 와 머지가 완료되면 삭제한다.
하나의 버전이 만들어지면 바로 배포될 수 있다 !

어떻게 ?
- 이슈를 생성.
- 프로젝트에 이슈 할당.
- feature/기능이름#이슈번호 브랜치를 만든다.
- feature 브랜치에 파일을 추가하고 #이슈번호 를 붙여서 커밋을 한다.
- feature 브랜치를 원격 저장소에 Push한다.
- GitHub에서 푸시 된 feature/기능이름#이슈번호 브랜치를 Pull Request한다.
- GitHub에서 코드리뷰를 한다.
- GitHub에서 Merge한다.
- 해당 이슈 해결시, 만든 브랜치 삭제
- 로컬 저장소에서 원격 저장소에 머지된 내용을 Pull한다.
- 이슈 close
차례대로 따라가면서 실습 해 보자.
📌이슈(Issue) 란 ?
프로젝트에서 작업해야할 단위
개발해야하는 기능 발생, 수정해야할 사항 버그 발생, 리팩터링 해야하는 코드 발생
등 프로젝트에서 발생되는 작업들을 이슈로 생성하여 관리한다. 쉽게말해 기능 모음집이라 생각하면 된다.
1.이슈생성

올가니제이션에서 new 이슈 클릭

내용을 작성하고 ,
Assigness = 책임자
라벨(해당이슈가 버그인지 기능구현을 위한 이슈인지 등을 표기한다.)
Project 설정(차후에 설명하겠다.) 등을 설정해준다.
이때 이슈 내용에 #5 등으로 다른 연관있는 이슈를 태그할 수 있다.

제목#7 이름으로 이슈가 생성된다.
📌프로젝트
앞에서 설명했듯 이슈는 프로젝트에서 작업해야 할 단위이다.
깃허브 내에서는 노션처럼 프로젝트를 만들어 이슈를 관리할 수 있는 기능을 지원한다. (관리차원, 코드와 무관)
1.프로젝트에 이슈 할당

프로젝트를 하나 만들고 이슈를 등록 해 준다. ( 앞선 이슈 생성시 프로젝트가 생성돼 있는 상태라면 그때 등록해 줘도 무관하다. )
status 로 진행 상태와 assigness 책임자 프로젝트 사이드 등을 표시할 수 있다. 이 이외에 컬럼을 추가하여 다양한 정보를 입력할 수 있다.
지금은 해당 이슈가 진행중인 이슈로 가정하고 in Progress 상태를 할당 해 주었다.
2.feature 브랜치 생성/commit/pr



gitHubFlow 전략에서는 기능별로 브랜치를 만들고 구현이 완료되면 삭제한다.
우리는 기능별로 이슈를 관리함으로 브랜치 역시 하나의 이슈라 생각하며,
feature/기능이름#이슈번호 브랜치를 만들어 준다.
기능을 넣고 등록한 이슈를 commit 해 보자. 기능 구현이 완료되었다고 가정하고 진행한다.
feat:test기능구현#7 로 commit 메세지를 날려 해당 브랜치에 push 해 주었다.

이슈목록에서 #7 로 들어가면 커밋 내역이 뜨는것을 볼 수 있다.
이때 해당 이슈가 완전히 끝나서 이슈를 닫고싶을때 close#7 을 붙여서 커밋하면 닫아진다.
이후 이슈는 수정이 불가하다. (깃허브 내에서도 이슈 클릭해서 닫을 수 있으니 꼭 커밋으로 닫을 필요는 없다.)

commit 내역을 확인했으니 main 브랜치에 pr 요청을 보내 보자.
이때 사이드의 리뷰어, 책임자,라벨 (기능, 버그 등 성격 명시), 프로젝트 를 지정해 준다.
이때 사이드의 리뷰어, 책임자,라벨 (기능, 버그 등 성격 명시), 프로젝트 를 지정해 준다.
📌코드리뷰
pr 내역에 대해 코드리뷰를 작성 해 보자. commit 내역을 바탕으로 이전 버전과 바뀐 코드를 보여준다.
문제가 있는 코드는 클릭 → 코멘트를 남겨주면 된다.
1.코드리뷰 작성

pr 목록에서 pr클릭 후 files changed 로 바뀐 코드를 확인한다.
코드에 마우스를 갖다대면 + 가 나온다 클릭 후 리뷰를 작성 해 주면 된다.

다 작성한 후 Review changes 를 누르면 ? 마치는 말이 나온다.
심심한 위로의 말을 적은 후 Approve 로 승인 해 준다. (앞서서 리뷰어로 지정해주지 않은 사람이 코멘트를 남긴다면 Commnet 창만 활성화 된다.)
- Comment: 명시적인 승인이 아닌, 단순히 코드에 대한 피드백이나 질문을 남길 때만 사용, 리뷰제출용
- Approve: 리뷰를 제출하고 현재 pr 을 승인
- Request changes: 병합거부, 병합 전에 꼭 해결 해야 하는 리뷰를 제출.

완료하면 해당 pr 에 이렇게 리뷰가 뜬다.
📌브랜치 삭제


merge 완료시, 완료되었다는 글이 delete branch 버튼과 함께 뜬다. 이때 pr 한 기능이 기능구현이 완료된 이슈
라면 버튼을 눌러 브랜치를 삭제 해 주면 된다. (따로삭제 할 필요 없음)

이슈생성 → commit → pr 까지 했으니, 앞서 만들어둔 프로젝트에 들어가 보자.
머지가 완료되었다고 2번에 자동으로 pr 내용이 만들어 진다. 누르면 해당 pr 을 볼 수 있다.
📌이슈 close

머지 후 브랜치 삭제까지 했으니 해당 이슈는 완료된 이슈다. 이슈를 닫아 주자! commit 메세지로 닫지 않았다면 해당 이슈로 들어가서 close 시켜주면 된다.

close 시 마찬가지로 이슈가 Done 상태로 변한다.
지금까지 gitHubFlow 의 전 과정을 바탕으로 이슈생성, 프로젝트에서 이슈 관리, 코드리뷰 하는 방법을 알아보았다.
과정을 따라가면서 실습 해 보길 권장한다.