게시판 프로젝트 github flow

종드·2022년 8월 15일

gitflow github

게시판_프로젝트

목록 보기

3/4

1. github flow 설명

아래 블로그들을 통해 github flow에 대한 부분을 많이 배웠다.

github 하나로 1인 개발 워크플로우 완성하기

github flow는 쉽게 말해서 github 사이트의 issue 기능을 적극 활용하여 기존의 git flow의 복잡한 브랜치 구조를 단순화 하는 것이다.

(여기서 issue는 '해야 할 일'과 같은 의미다. 앞으로 개발해야 할 기능이나 해결해야 하는 버그 따위가 될 수 있다.)

flow는 아래와 같다.

github flow는 시시각각 master에 머지될 때마다 배포가 이루어지는 것이 좋다.
따라서 CI/CD를 통한 배포 자동화를 적용하는 것이 좋다.
브랜치 전략이 단순해 master 브랜치에서 pull 하고, 기능 구현하고, 머지하는 일의 반복이다.
pull request에서 팀원간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 자체에서 버그가 발생할 수 있으므로 주의해야 한다.

그런데 나는 아직 CI/CD를 할 줄 모른다. 그래서 그냥 배포 가능한 수준인지 수동으로 확인해보고 master로 merge할 것이다.
(프로젝트를 진행하면서 CI/CD도 공부하게 된다면 그때 배포 자동화를 적용해보겠다.)
- 2022.08.16

실전

1) issue 생성

'New issue' 버튼을 누른다.

아래는 생성된 issue의 정보창이다.

(1) issue 번호

(2) 이 issue와 관련된 이벤트 (여기서는 Labels, pinn 관련 이벤트가 있었음을 알 수 있다.)

(3) Labels 지정

(4) Projects 지정

2) 로컬 저장소에 작업 브랜치 생성

& 새 브랜치(issue 브랜치)를 원격 저장소(github)로 push하기

(intellij 환경이다)

새 브랜치의 이름은 'issue번호-기능명' 양식으로 작성한다.

github에서 확인해보면 새 브랜치가 제대로 push된 것을 알 수 있다.

3) 필요한 작업 진행

4) 작업을 테스트

5) 수정 사항을 commit & push

github flow의 경우 push를 자주 해주는 것이 좋다고 한다.
(다른 참가자가 실시간으로 인지할 수 있도록 말이다.)

아래 사이트에서 좋은 커밋 메시지를 참고했다.

좋은 commit message

[결과]

그런데 위처럼 commit message를 작성하는 것은 github flow에 좋지 않다.

커밋 메시지에 '#issue번호' 형식을 넣어 주면 훨씬 좋다. 그러고 push를 하면 github에서 알아서 인식하여 해당 issue의 이벤트 로그에 커밋 정보를 띄어준다.

아래는 두 번째 커밋이다. 커밋 메시지에 '#1'이라고 이슈 번호를 지정해줬다.

이제 github의 issue #1번 창에 들어가보자.

빨간색으로 표시한 부분을 보면 커밋 메시지가 로그에 띄어진 것을 알 수 있다.

이렇게 각 이슈 페이지마다 나의 작업을 타임라인 형식으로 묶어내는 게 이슈 기반 버전 관리(github flow)의 핵심이다.

6) '작업 -> commit -> push'의 반복

7) issue가 완전히 해결되면 pull request

(pull request: github에서 issue 브랜치를 master 브랜치에 병합하는 작업)

나는 커밋 'add footer'를 마지막으로 작업이 끝났다.

이제 pull request를 통해 원격 저장소(github)의 master 브랜치에 issue 브랜치를 병합해보자.

빨간색으로 표시한 부분
: '특정 키워드 #이슈번호'를 명시해주면 issue를 알아서 닫아준다. 여기서 키워드는 아래와 같다.

close
closes
closed
fix
fixes
fixed
resolve
resolves
resolved

또 pull request는 Reviewers 를 지정할 수 있다.
Reviewers를 지정하면 그 사람이 코드를 검토하고, 원하는 코드 라인에 댓글(comment)도 달고 승인(approve)하거나 재검토(request changes)하라고 할 수 있다.

나는 1인 개발이기 때문에 무시한다.

이제 create 버튼을 누르면 아래와 같은 창으로 넘어간다.

merge하려는 브랜치의 커밋 로그를 볼 수 있다. 또 좌측 하단의 빨간색 표시를 보면 'resolve #1'이 제대로 인식되었음을 알 수 있다.

아래로 스크롤을 내리자.

conflicts가 없음을 알 수 있다. 또 merge 옵션이 세 가지가 있는데 각 내용은 아래 블로그를 참고하면 된다.
merge 옵션

나는 create a merge commit을 선택했다.

confirm을 누른다.

1-index.html 브랜치는 필요 없으므로 바로 delete 버튼을 누른다.

github의 브랜치 네트워크를 보면 병합이 잘된 것을 알 수 있다.

물론 issue #1도 잘 closed 되었다.

추가로 github의 project(칸반 보드)에서도 issue가 Done으로 이동된 것을 확인할 수 있다.

8) 로컬 저장소 업데이트하기

pull request가 끝나면 원격 저장소(github)는 정리가 끝나지만 로컬 저장소의 경우 아직 issue 브랜치와 master 브랜치가 분기한 상황이다.

아래는 현재 로컬의 브랜치 상황이다.

여기서 현재 원격 저장소(github)의 상태와 동기화해보자.

intelliJ를 사용하기 때문에 여기서 제공하는 기능으로 설명한다.

화면 상단의 update project를 클릭한다. 그러면 원격(origin) 브랜치가 업데이트된다. (origin/issue 브랜치와 origin/master 브랜치가 병합되고 origin/issue 브랜치가 제거된 상황을 말한다.)
로컬 master 브랜치를 직접 update한다. 그러면 origin/master 브랜치와 동일한 상태가 된다.
로컬 issue 브랜치를 수동으로 delete한다. 이때 master 브랜치로 checkout 되어있어야 한다. (현재 checkout하고 있는 브랜치는 제거할 수 없기 때문.)

이렇게 정리가 끝나면 아래와 같이 원격 저장소(github)와 동일한 상태가 된다.