밍개발일지

gitHubFlow 전략

미미_밍 2024. 12. 30. 16:05

효율적인 깃허브 저장소 관리를 위해 브랜치 생성에 규칙을 만들어서 사용하는 방법론을

깃허브 브랜치 전략이라고 한다.

 

📌gitHubFlow 전략

GitHub에서 제안한 브랜치 모델 gitFlow 보다 간단하고 소규모 프로젝트에 많이 이용

master 브랜치 만을 사용하여 개발 및 배포 하며

feature/기능별 브랜치를 만들어 master 와 머지가 완료되면 삭제한다.

하나의 버전이 만들어지면 바로 배포될 수 있다 !

 

 

 

어떻게 ?

  1. 이슈를 생성.
  2. 프로젝트에 이슈 할당.
  3. feature/기능이름#이슈번호 브랜치를 만든다.
  4. feature 브랜치에 파일을 추가하고 #이슈번호 를 붙여서 커밋을 한다.
  5. feature 브랜치를 원격 저장소에 Push한다.
  6. GitHub에서 푸시 된 feature/기능이름#이슈번호 브랜치를 Pull Request한다.
  7. GitHub에서 코드리뷰를 한다.
  8. GitHub에서 Merge한다.
  9. 해당 이슈 해결시, 만든 브랜치 삭제
  10. 로컬 저장소에서 원격 저장소에 머지된 내용을 Pull한다.
  11. 이슈 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 의 전 과정을 바탕으로 이슈생성, 프로젝트에서 이슈 관리, 코드리뷰 하는 방법을 알아보았다.

과정을 따라가면서 실습 해 보길 권장한다.