Git-Flow & Commit message & Issue 이용해서 협업하기

u-nij·2022년 4월 6일
github
3
post-custom-banner

Git-Flow 전략은 프로젝트 동아리에서 부트캠프 활동을 하면서 접하게 된 내용 중 하나입니다. 혼자서 작업했던 토이 프로젝트라 브랜치들이 깔끔해보일 뿐이었는데, 동기들과 졸업 프로젝트를 진행하면서 정말 요긴하게 쓰였던 기억이 납니다😀! 협업 과정에서 유용하게 & 곧잘 쓰이는 Git-Flow 전략과 GitHub의 기능들을 정리해봤습니다!

Git-Flow

브랜치 종류

  • master : 프로젝트가 최종적으로 배포되는 중심 브랜치입니다.
  • develop : 개발이 진행되는 브랜치입니다. develop 브랜치가 배포할 수준의 기능을 갖추면 release 브랜치로 머지됩니다.
  • feature : 기능을 개발하는 브랜치입니다. develop 브랜치에서 파생되는 브랜치이며, develop 브랜치로 머지됩니다.
  • release : 개발된 내용을 배포하기 위해 준비하는 브랜치입니다. 충분한 테스트를 통해 버그를 검사하고, 배포할 준비가 되었다고 판단하면 master로 머지해 배포합니다. 버그 수정 내용을 develop 브랜치에도 반영하고, 최종적으로 master 브랜치에 머지합니다.
  • hotfix : 출시 버전(master)에서 버그를 수정하는 브랜치입니다. master 브랜치에서 생성되며, 수정이 완료되면 develop, master 브랜치에 수정 사항을 반영합니다.

브랜치 네이밍

  • master와 develop은 일반적으로 본래 이름 그대로 사용합니다.
  • feature : feature/{기능 요약} 혹은 feature/{issue-number}-{기능 요약}
  • release : release-{버전} 혹은 release/{버전}
  • hotfix : hotfix-{버전}

과정

  1. master 브랜치에서 개발을 시작한다.
  2. 기능 구현 및 버그가 발생하면 깃헙에 'Issue'를 작성한다.
  3. develop 브랜치로부터 feature 브랜치를 파생하고, feature 브랜치에서 기능을 구현한다.
  4. 팀원들의 리뷰를 거친 후에 feature 브랜치에서 develop 브랜치로 merge한다.
  5. 개발이 끝나면, develop 브랜치로부터 release 브랜치를 생성해 최종 테스트를 진행한다.
  6. 테스트가 성공하면 release 브랜치에서 master 브랜치로 머지한다.
  7. master 브랜치에서 버전 태그를 추가해 배포한다.
  8. master 브랜치에서 버그가 발생하면 hotfix 브랜치에서 버그를 수정한다. 버그 수정이 끝나면 develop, master 브랜치에 merge하고, master 브랜치에서는 버전을 추가해 배포한다.

Commit message

구조

<type>(<scope>): <subject>	# 헤더
<BLANK LINE>
<body>						# 본문
<BLANK LINE>
<footer>					# 바닥글
  • <type> : 해당 commit의 성격을 나타냅니다. 아래 중 하나입니다.

    Feat : 새로운 기능에 대한 커밋
    Fix : 버그 수정에 대한 커밋
    Build : 빌드 관련 파일 수정에 대한 커밋
    Chore : 그 외 자잘한 수정에 대한 커밋(rlxk qusrud)
    Ci : CI 관련 설정 수정에 대한 커밋
    Docs : 문서 수정에 대한 커밋
    Style : 코드 스타일 혹은 포맷 등에 관한 커밋
    Refactor : 코드 리팩토링에 대한 커밋 test : 테스트 코드 수정에 대한 커밋
    Test : 테스트 코드 수정에 대한 커밋

  • <body> : 헤더에서 생략한 상세한 내용을 작성합니다. 헤더로 충분한 표현이 가능하다면 생략이 가능합니다.
  • <footer> : 어떤 이슈에서 왔는지와 같은 참조 정보를 추가하는 용도로 사용합니다. 예를 들어, 특정 이슈를 참조하려면 close #{이슈번호}와 같이 추가하면 됩니다.

규칙

  1. 제목과 본문을 빈 행으로 구분한다
  2. 제목을 50글자 내로 제한
  3. 제목 첫 글자는 대문자로 작성
  4. 제목 끝에 마침표 넣지 않기
  5. 제목은 명령문으로 사용하며 과거형을 사용하지 않는다
  6. 본문의 각 행은 72글자 내로 제한
  7. 어떻게 보다는 무엇과 왜를 설명한다

Issues

깃허브 저장소 페이지의 Issues 탭에서 이슈를 생성할 수 있습니다.

이슈 템플릿 생성하기

Settings 탭 - General - Features - Issues 에서 Set up templates 버튼을 클릭합니다.

간단한 템플릿 작성을 위해 Custom template을 선택합니다.

Preview and edit 버튼을 눌러 템플릿을 편집합니다.

Perpose changes 버튼을 눌러 (템플릿 생성에 대한) 커밋 메세지를 작성하고, Commit changes 버튼을 눌러 생성을 완료합니다.

이제 이슈를 생성할 때 템플릿을 골라 사용할 수 있습니다.

Assigness, Labels 등을 선택해 이슈에 대한 옵션을 줄 수도 있습니다.

Assigness : 담당자
Labels : 성격
Milestone : 이슈가 속한 파트
Linked pull requests : PR 중 이슈와 연결되는 브랜치 작업을 선택할 수 있습니다.

키워드를 사용해 PR을 이슈에 연결하기

Linked pull requests을 통해 수동으로 작업하는 것 말고도,
PR 혹은 commit message에서 키워드를 사용해 이슈에 연결할 수 있습니다.

  • close
  • closes
  • closed
  • fix
  • fixes
  • fixed
  • resolve
  • resolves
  • resolved

'{키워드} #{이슈 넘버}'이라고 적으면 이슈가 연결됩니다. (ex. close #1)

관련된 GitHub Docs를 참고하면, 기본 브랜치에 merge될 경우에는 참조된 이슈가 자동으로 close 됩니다.

실습

git-flow 전략에 쓰일 브랜치들을 생성하고, 이슈를 작성한 후 PR까지 해보겠습니다. 😀

브랜치 & 깃 상태 확인

git branch	# 전체 브랜치 목록 확인
git status # 현재 브랜치 위치 확인 및 commit 상태 확인

# 변경 사항이 있을 경우 혹은 브랜치를 파생할 때
git pull origin {현재 브랜치}

이슈 생성

이슈를 간단하게 작성해주었습니다. 이슈번호가 #1로 생성됐습니다.

develop & feature 브랜치 생성

git branch develop	# develop 브랜치 생성
git checkout develop # develop 브랜치로 전환
git pull origin main	# 현재 브랜치(develop)로 리모트 레포지토리의 main(상위) 브랜치 가져오기
git push origin develop	# 새롭게 만든 브랜치를 리모트 레포지토리로 push

fatal: couldn't find remote ref develop

git pull 명령어에서 오류가 났을 경우 : 리모트 레포지토리에 없는 것에 대해 pull 할 수 없습니다. default 브랜치의 이름이 'main'인지 'master'인지 확인해주세요!

develop 브랜치가 생성된 것을 확인할 수 있습니다. 똑같은 방식으로 feature 브랜치를 생성해주겠습니다. 

git branch feature/1_test	# feature 브랜치 생성 : issue #1의 작업임을 의미
git checkout feature/1_test
git pull origin develop		# 상위 브랜치인 develop 브랜치 가져오기
git push origin feature/1_test

feature 브랜치까지 생성되었습니다.

작업(기능 구현) - commit - PR(Pull Request)

'feature/1_test' 브랜치에서 'develop' 브랜치로 PR하는 과정입니다.

1. 작업(기능 구현)

git status	# 현재 git 상태 확인
git add .	# 모든 파일(.)을 stage 상태로 전환시킵니다.
git status

2. commit

커밋을 해보겠습니다. 두 가지 방법으로 할 수 있습니다.
1) 간단하게는 git commit -m "commit message" 명령어를 사용할 수도 있고,
2) 혹은, 위에 commit message 규칙을 적용해보려면 git commit 명령어를 입력해줍니다. 입력하게 되면 아래와 같은 화면으로 이동합니다.
commit message를 작성해주겠습니다. (vim 환경과 똑같이 i를 입력해 편집을 시작할 수 있습니다.)
작성을 완료하고 Esc를 누른 후, :wq를 입력해 commit message를 저장하고 빠져나오면 커밋이 완료된걸 볼 수 있습니다.

3. PR (Pull Request)

git push origin feature/1_test
터미널에서 git push 명령어를 입력하고, 깃 저장소에 가면 PR 알림이 보입니다.
commit message가 입력한대로 올라온 것을 확인할 수 있습니다. base branch를 develop 브랜치로 변경하고 Create pull request를 누릅니다.
이슈를 확인해보면 연결되었음을 확인할 수 있습니다.

브랜치를 merge해주고, 이슈 또한 close 해주겠습니다.

master 브랜치로 merge

같은 방법으로 이슈를 생성하고 PR을 생성합니다. PR에 close #3을 입력하고 merge해보겠습니다.

main 브랜치는 기본 브랜치이기때문에 자동으로 이슈가 close됩니다.

태그(tag) 추가하기

tag를 붙이게 되면 수정이 불가능하며, 특정 시점으로 롤백하거나 배포 버전을 생성하는 등의 용도로 tag를 사용 가능합니다. main 브랜치에서 아래 명령어를 실행합니다.

git tag 1.0.0
git show 1.0.0
git push origin 1.0.0

Reference

우린 Git-flow를 사용하고 있어요
누구나 쉽게 이해할 수 있는 Git 입문
GitHub Docs : Linking a pull request to an issue
Git 브랜치의 종류 및 사용법

profile
u-nij
삶은 달걀이다
이전 포스트

Spring Boot + AWS RDS (MySQL) 연동하기

다음 포스트

Spring Boot + Nginx 연동해서 배포하기

post-custom-banner

0개의 댓글