1. Git
git은 협업에 있어 필수적이라 사용 방식을 익혀두어야 한다.
git의 영역은 크게 Local과 Remote 영역으로 나뉘는데 Local에서도 영역이 나뉜다.
그림을 보면 쉽게 이해가 될 것이다. 말하자면 working directory는 개발자가 코드를 작성하고 수정하는 내 컴퓨터의 폴더이고 local repository는 commit 이후에 Git이 관리하는 저장소이다. remote repository는 push를 하게되면 업로드 되는 GitHub라 할 수 있다. staging area는 커밋 전 대기 상태라고 보면 된다. 한 번 더 확인할 수 있어서 커밋을 더욱 깔끔하게 만들어준다.
$ git diff --staged위의 명령어를 사용하면 staging area에서 검토가 가능하다!
2. Git-Flow와 브랜치
Git-Flow는 브랜치 전략으로 협업 및 버전 관리를 체계적으로 관리할 수 있게 여러 브랜치로 나누어 구조한 것이다.
브랜치는 여러 개발자가 동시에 작업할 때 각자 독립적인 환경에서 개발할 수 있게 한다.
또한 기능(feature)개발, 버그 수정(hotfix), 배포 준비(release)등을 분리하여 관리할 수 있다.
main 브랜치는 항상 안정적인 상태로 유지를 하며 새로운 기능은 feature 브랜치에서 개발 후 합치는 방식이다.
주요 브랜치 종류에 대해 알아보자면
- main(기본 브랜치)
- 배포가 가능한 안정적인 코드가 있는 브랜치로 항상 안정적인 상태를 유지하며 직접 개발하지 않는다.
- feature, hotfix, release 브랜치에서 개발한 내용을 최종적으로 합치는 곳
git checkout main #main 브랜치로 이동
git pull origin main #최신 코드 가져오기
- develop(개발 브랜치)
- 개발자들이 기능을 추가하고 테스트하는 브랜치로 각 개발자는 feature 브랜치에서 작업 후 develop로 병합한다.
- develop가 충분히 안정화되면 main으로 병합한다.
git checkout -b develop #develop 브랜치 생성
git push origin develop #원격 저장소에 업로드
- feature (새로운 기능 개발 브랜치)
- 새로운 기능을 개발할 때 사용하는 브랜치로 각 개발자가 자신만의 feature 브랜치를 만들고 개발이 끝나면 develop에 병합한다.
- main이나 develop에 직접 작업하지 않도록 방지
#로그인 기능 개발
git checkout develop #항상 develop에서 새로운 브랜치를 만든다!!
git checkout -b feature/login #feature 브랜치 생성
git push origin feature/login #원격 저장소에 업로드#개발이 끝난후 develop 브랜치로 통합
git checkout develop
git merge feature/login #기능 개발 후 develop 병합
git push origin develop
- hotfix(긴급 버그 수정 브랜치)
- 배포된 코드에서 긴급한 버그를 수정하는 브랜치로 main 브랜치에서 직접 새로운 브랜치를 생성하여 버그를 숮어한다.
- 빠르게 수정 후 main에 병합하고 develop에도 반영한다.
git checkout main # 배포된 main 브랜치에서 시작
git checkout -b hotfix/urgent-bug # 긴급 버그 수정 브랜치 생성
git push origin hotfix/urgent-bug # 원격 저장소에 업로드#버그 수정 후 main과 develop에 반영
git checkout main
git merge hotfix/urgent-bug # main에 병합
git push origin main
git checkout develop
git merge hotfix/urgent-bug # develop에도 병합
git push origin develop#이후 hotfix/urgent-bug 브랜치 삭제
git branch -d hotfix/urgent-bug
git push origin --delete hotfix/urgent-bug
- release (배포 준비 브랜치)
- 배포 전 마지막 테스트 및 안정화 작업을 수행하는 브랜치로 develop에서 분기하여 배포를 준비한다.
- 최종적으로 main에 병합 후 develop에도 병합한다.
#배포 준비
git checkout develop # develop에서 분기
git checkout -b release/v1.0.0 # 버전명을 포함한 release 브랜치 생성
git push origin release/v1.0.0#최종 테스트 후 main과 develop에 병합
git checkout main
git merge release/v1.0.0 # main에 병합 (배포 완료)
git push origin main
git checkout develop
git merge release/v1.0.0 # develop에도 반영
git push origin develop#이후 release/v1.0.0 브랜치 삭제
git branch -d release/v1.0.0
git push origin --delete release/v1.0.0
여기서 git checkout이 헷갈릴 수 있는데 checkout은 브랜치를 이동하거나 새 브랜치를 만들 때 사용하는 것이다.
즉, 현재 작업할 브랜치를 바꾸는 명령어!
git checkout develop #develop 브랜치로 이동
git checkout -b feature/login #새로운 feature/login 브랜치를 만들고 이동
3. Pull Request
pull Request(PR)은 내가 만든 변경 사항을 다른 브랜치로 병합해달라고 요청하는 과정이다.
PR은 여러 개발자가 동시에 작업할 때 코드 충돌을 방지하고, 코드를 리뷰한 후 병합할 수 있도록 하기 위함이다.
직접 git merge하지 않고, 리뷰 후에 병합을 할 수 있도록 GitHub에 요청하는 방식!
즉, 내 로컬에서 작업한 기능을 feature 브랜치로 만들고 이를 develop 또는 main브랜치로 합치고 싶을 때 사용!
- GitHub에서 Pull Request 생성
- GitHub의 프로젝트 저장소로 이동
- "Pull Requests" -> "New Pull Request" 클릭
- 기준 브랜치(base): develop, 병합할 브랜치(compare): feature/login 선택
- PR제목과 설명을 작성(상세히 작성)
- 팀원에게 리뷰 요청 (Assign Reviewers)
- PR 생성(Create Pull Request) 버튼 클릭
- 팀원들이 코드 리뷰를 완료하면 "Merge Pull Request"버튼 클릭
- GitHub에서 feature/login -> develop로 병합
- 병합 후 feature/login 브랜치는 삭제가능 코드 리뷰 후 병합(Merge)
4. GitHub PR Template 사용하기
Creating a pull request template for your repository - GitHub Docs
When you add a pull request template to your repository, project contributors will automatically see the template's contents in the pull request body.
docs.github.com
- 프로젝트 하위에 .github 숨김 폴더를 만든 후 내용을 포함한 pull_request_template.md 파일을 생성한다.
- 파일을 먼저 target 브랜치에 반영해두면 source -> target으로 PR 적용된다.
