깃에서 브랜치를 만들어 작업하는 방법은 매우 중요합니다. 브랜치 작업에서 중요한 것은 언제 브랜치를 만들고 어떤 브랜치에서 만드는지 정하는 일입니다. 이것을 정의하는 것을 브랜치 전략이라고 합니다. 브랜치 전략에 대해 생각해보고 github에서의 워크플로를 알아보도록 하겠습니다.
브랜치 전략 정의하기
특정 규칙 없이 프로젝트에서 작업하는 많은 사람이 브랜치를 만들고 다수의 브랜치를 통해 변경 작업을 해올 수 있습니다. 브랜치에서 작업하는 것은 좋은 일이지만 어떤 지점에 무엇이 있는지 파악하기 어려울 수도 있습니다. 따라서 브랜치 전략을 정의하는 것이 좋습니다.
브랜치 전략은 브랜치를 사용하여 작업하는 방법을 정의하는 일련의 규칙입니다. 우리는 브랜치를 만들 때 규칙에 의거해서 새 브랜치를 생성할지 생성할지 말아야 할지 결정할 수 있습니다. 예를 들어 새로운 기능을 만들거나 버그를 수정할 때 새 브랜치를 생성한다고 규칙을 정의할 수 있습니다. 또 머지할 위치와 브랜치를 나누는 곳을 지정하는 규칙도 필요합니다.
대부분 프로젝트에서는 브랜치 작업을 위한 워크플로를 정의하고 있으며 팀원에게 브랜치 작업에 대해 정의된 전략을 제공합니다. 모든 팀원이 쉽게 이해할 수 있도록 가능한 한 간단하게 유지하는 것이 좋습니다.
git branch 전략들
일반적으로 사용되는 몇 가지 전략의 워크플로를 살펴보겠습니다.
1. Centralized workflow
중앙 집중식은 git과 같은 분산 소스 관리 시스템으로 작업할 때는 약간 이상해 보일 수 있습니다. 중앙 집중식의 워크플로는 모든 변경 사항이 하나의 브랜치로 커밋되고 작업합니다. 예전부터 써왔던 방법이고 많은 개발자에게 익숙하지만, git으로 작업할 때 최고의 솔루션은 아닙니다.
2. Gitflow workflow
두번째는 Gitflow를 사용하는 것입니다. Gitflow는 복잡하고 많은 분기를 사용하게 됩니다. 일반적으로 수명이 긴 두 가지 브랜치 main과 development를 사용합니다. main은 production에 안정적인 버전을 반영하는 곳이고, development 브랜치는 개발이 일어나는 곳입니다. 개발 자체는 여러 다른 브랜치를 이용해서 개발하게 됩니다. 예를 들어 feature 브랜치는 특정 기능의 롤백이 작동하도록 생성하는 브랜치입니다. release 브랜치는 릴리스를 준비하는 데 사용하는 브랜치이며, hotfix브랜치는 이미 프로덕션에 있는 코드에 대한 수정을 수행하는 데 사용합니다. gitflow의 아이디어는 여러 작업을 동시에 수행할 수 있다는 것입니다.
3. Forking workflow
포크(Fork)는 리포지토리의 복사본입니다. 각 개발자는 리포지토리를 복사해서 자신만의 복사본에서 작업하게됩니다. 그런 다음 개발자는 변경사항을 자신의 서버 측 복사본으로 푸시하고 변경사항을 원래 리포지토리의 소유자에게 푸시할 수 있습니다. 이러한 접근 방식은 종종 오픈 소스 프로젝트에서 사용합니다.
4.Github 워크 플로
마지막으로 소개할 전략은 Github 워크플로 입니다. 다수의 브랜치에서 작업하고, 풀 리퀘스트를 이용한 리뷰와 브랜치의 병합을 이용하는 작업 흐름이 됩니다. 이번 포스트의 메인 주제이므로 아래에서 이어서 자세히 소개하겠습니다.
Github 워크 플로 이해하기
Github의 워크플로는 다른 워크플로에 비해 매우 가벼운 흐름입니다. 당연히 Github에서 선호하고 있습니다. 이 워크플로 역시 브랜치를 기반으로 하고 있습니다.
우리는 일반적으로 버그를 수정하거나 새기능 만들기와 같이 여러 작업을 동시에 진행하기 위해 브랜치를 만듭니다. 이 브랜치에서 새 파일을 만들거나 파일 편집, 파일 삭제 등과 같은 변경사항을 수행합니다. 이러한 모든 것은 자신의 로컬 브랜치에서 하고 있기 때문에 이것은 다른 사람들의 작업에 영향을 미치지 않습니다.
작업이 진행됨에 따라 여러 커밋을 만들 수 있습니다. 그리고 풀 리퀘스트(pull request)라는 것을 생성하게 됩니다. 풀 리퀘스트는 좀 더 주의깊게 살펴봐야 합니다.
pull request 란?
각 개발자들이 개인 브랜치에서 작업이 끝나면 변경사항을 메인 브랜치와 통합하는 시점에 도달하게 됩니다. 메인 브랜치와 병합하기 위해서 해야 할 일이 풀 리퀘스트를 생성하는 것입니다.
pull request, 줄여서 pr은 우리가 별도의 브랜치에서 작업해서 변경했다는 사실을 다른 사람들에게 알리는 것입니다. 풀 리퀘스트를 만들 때 이러한 변경사항을 알리고 토론 혹은 리뷰를 위해 공개합니다. 풀 리퀘스트를 만들면 우리가 만든 변경사항을 검토할 수 있고 추가로 다른 커밋이 동일한 풀 리퀘스트에 추가될 수도 있습니다. 풀 리퀘스트가 승인된 후에는 브랜치가 다른 브랜치에 merge(병합)하게 됩니다.
풀 리퀘스트를 지원하기 위해 github에서는 pull 리퀘스트 생성 및 병합 흐름을 지원하는 여러 기능이 존재합니다. 또한 공동작업자 pull requst를 리뷰하고 주석을 추가하는 등의 인터페이스가 포함되어 있습니다.
위 캡처가 github에서 풀 리퀘스트를 작성할 때 볼 수 있는 인터페이스입니다. 변경 사항, 레이블, 이정표 등 개요를 입력할 수 있습니다.
github 워크 플로 개요
여기 아래 작업 흐름이 있습니다. 먼저 작업을 하는 특정 지점에서부터 시작하게 됩니다.
이 시점에서 새로운 기능을 만들거나 버그를 수정하라는 요청을 받았습니다. 요청받은 작업을 하기 위해 초기 브랜치에서 새로운 브랜치를 생성하게 됩니다.
이 브랜치를 생성할 때 메인 브랜치에는 어떠한 영향도 미치지 않습니다. 오직 변경사항을 메인 브랜치에 합치라고 명시적으로 요청할 때만 영향이 있습니다. 이제 브랜치가 생겼고 로컬에서 코딩을 합니다. 로컬에서 git으로 작업하고 여러 커밋을 추가하게 됩니다. 이 모든 것들이 로컬의 브랜치에서 발생합니다. 그리고 작업이 마무리되면 변경사항에 대해 피드백을 받고 싶을 것입니다.
브랜치에서 작업했던 기능이 준비됐다고 생각하는 시점에 풀 리퀘스트를 생성할 수 있습니다.
풀 리퀘스트가 생성되면 변경사항에 대해 토론 혹은 코드 리뷰가 진행됩니다.
풀 리퀘스트를 통해 수정 사항을 확인하고, 누락사항이 있는지 등을 표시할 수 있습니다. 이 시점에 추가 커밋을 풀 리퀘스트에 추가할 수 있습니다.
작업에 대한 리뷰가 통과되면 메인 브랜치로 병합(merge) 될 준비가 된 것입니다.
작업한 코드는 메인과 병합되었으니 이제 작업자의 feature 브랜치를 삭제할 수도 있습니다.
여기까지 github에서 pull request를 사용하는 워크 플로의 개요를 살펴봤습니다.
여기까지 수고하셨습니다. 다음 포스트에서는 실제로 github에서 풀 리퀘스트를 하는 과정을 살펴보도록 하겠습니다..
'프로그래밍 > Git' 카테고리의 다른 글
| github 리포지토리 포크(fork)하기 (1) | 2022.09.20 |
|---|---|
| github, pull request 만들고 merge하기 (1) | 2022.09.16 |
| git branch 이해하기 (0) | 2022.09.10 |
| 깃 작업 흐름, github clone부터 push까지 따라하기 (0) | 2022.09.07 |
| github 리포지토리 이해하기 (0) | 2022.09.04 |
댓글