GitHub 협업 플로우
지금까지 Git에 대한 기본적인 이해는 되었길 희망합니다.
이번에는 여러 사람이 협업을 한다고 하면 큰 틀에서 규칙이 필요합니다.
아무리 좋은 버전 관리 시스템을 사용한다고 해도 충돌은 피할 수 없습니다.
이를 최소화하는 것이 중요하고 배포까지 고려한다면 개발 → 테스트 → 배포라는 과정에서 어떤 규칙하에 진행되어야 하는지는 중요한 부분이라고 할 수 있습니다.
SVN(Subversion)으로 버전 관리 시스템을 구성할 때에도 SVN의 기본 구성 요소인 trunk, branch, tag를 기반으로 trunk는 항상 안정적인 버전을 유지하고, 배포 후 tag를 달아 배포 버전을 관리하고, 실제 작업은 branch를 생성해 진행하는 큰 틀에서의 규칙을 만들고 세부 지침을 정하는 등이 협업 플로우를 계획하게 됩니다. 하나의 전략을 짜는 것입니다.
Git을 기반으로도 마찬가지입니다.
Git을 기반으로 하는 버전 관리 시스템 하에서 협업 플로우는 Git Flow, GitHub Flow, GitLab Flow 가 잘 알려져 있습니다.
아무리 잘 알려진 플로우라고 해도 프로젝트 성격에 따라, 회사에 따라 모두 다른 플로우를 가지고 있다고 할 수 있습니다. 그렇다고 해도 큰 틀에서 보면 어느 정도는 비슷한 플로우를 가지고 있습니다.
그래서, 협업 플로우는 정하기 나름입니다.
협업 플로우에서 규칙을 정할 때 핵심은 브랜치 구성을 어떻게 할 것인가?
배포를 위한 안정적인 코드는 어떻게 유지 관리되게 할 것인가?라고 할 수 있습니다.
이러한 전략을 브랜치 전략이라고 하는데 브랜치 전략은 서비스와 조직 구성에 따라 잘 고려되어야 하며 정답이 있는 것이 아니기 때문에 시행착오를 거치면서 단점을 계속해서 보완해 가며 완성되어 가는 것이라 생각합니다.
다음의 그림이 GitHub Flow를 제 나름대로 알기 쉽게 절차대로 나타내 본 것입니다.
메인 브랜치를 Master, 생성한 브랜치를 bugfix라는 가정하에 그려진 부분입니다.
위 흐름을 순서대로 설명하면 다음과 같습니다.
① Clone
최초 서버(원격) 저장소에서 자신의 작업 PC의 로컬 저장소로 프로젝트를 모두 내려받습니다.
② Branch 생성
메인 브랜치(여기서는 Master)에서 작업을 위해 새로운 브랜치(여기서는 bugfix)를 생성합니다.
③ 작업진행(Commit)
생성한 브랜치(bugfix)에서 필요한 작업을 수행합니다. 작업 과정에 커밋은 반복될 수 있겠습니다.
④ Push
새로운 브랜치(bugfix)에서 모든 작업이 완료되었으면 서버 저장소로 해당 브랜치를 push 명령을 통해 전송합니다.
지금까지 다시 정리해 보면 로컬 저장소에서 서버(원격) 저장소의 Master 브랜치의 내용을 Clone으로 내려받고, 로컬 저장소에서 작업할 브랜치를 생성한 후, 해당 브랜치(bugfix)에서 작업을 진행하고, 서버(원격) 저장소로 전송(push)까지 진행했습니다.
⑤ Pull Request 생성
GitHub에 접속해 Pull Request를 생성합니다.
이 때 공유하기 위한 작업 내용을 작성하게 됩니다.
push 후 GitHub에 접속하면 다음과 같이 [Compare & pull request]라는 버튼을 확인할 수 있습니다.
해당 버튼을 클릭합니다.
또는 “④ Push”를 실행한 결과 화면에서 pull request 할 수 있는 링크를 친절하게 보여줍니다.
다음 화면은 앞서 push 한 결과입니다.
파란색으로 표시한 부분이 pull request 할 수 있는 링크입니다.
해당 링크로 바로 접속해도 되겠습니다.
pull request 생성을 위해 들어가면
다음과 같이 “Open pull request”라는 페이지를 확인할 수 있으며,
제목과 설명에 작업 내용을 알 수 있게 작성합니다.
작성 후 [Create pull request] 버튼을 클릭하면 됩니다.
⑥ 코드리뷰 & 추가 작업
Pull Request 를 생성하면 다른 사람들이 코드를 확인하며 의견을 댓글 형식으로 작성할 수 있습니다. 자연스럽게 코드리뷰가 가능해집니다. 이때 리뷰에 따라 필요한 코드를 수정하고 다시 Push 하는 과정이 반복됩니다.
앞서 pull request 를 생성하면 다음과 같은 화면을 확인할 수 있습니다.
이 공간에서 코드를 확인한 후 의견을 자유롭게 작성할 수 있습니다.
또한 리뷰를 통해 도출된 내용으로 코드를 수정하고 커밋 및 push가 반복될 수 있습니다.
⑦ Merge pull request
모든 작업이 완료되면 GitHub 상에서 Merge pull request 를 실행합니다.
이를 통해 메인 브랜치인 master 브랜치에 머지(merge)하게 됩니다.
앞서 본 pull request 화면에서 다음의 내용을 확인할 수 있었습니다.
모든 리뷰와 코드 수정이 완료되면 [Merge pull request] 버튼을 클릭해 머지를 실행합니다.
GitHub의 메인 브랜치와 병합이 문제없이 완료되면, 배포를 진행할 수 있습니다.
⑧ Pull
GitHub(서버 저장소)의 머지된 내용을 로컬 저장소로 가져와 내용을 맞춰 두게 됩니다.
GitHub Flow에서는 서버(원격) 저장소의 메인 브랜치는 머지가 되면 바로 배포가 이뤄져야 한다고 얘기하고 있습니다.
하지만 반드시 그렇지 않아도 되며, 구성원들과 룰(규칙)을 어떻게 정하느냐에 따라 달라질 수 있습니다.
또한, 생성한 브랜치는 메인 브랜치에 머지가 되면 삭제하는 것을 원칙으로 합니다.
그렇지 않으면 이후 삭제되지 않은 브랜치로 인해 문제가 발생할 가능성이 커지기 때문입니다.
이 또한 히스토리 관리 차원에서 남겨두는 경우도 있습니다.
이상 GitHub 협업 플로우에 대해 알아봤습니다.
감사합니다.
'코딩해보니 > Git' 카테고리의 다른 글
| 특강 - Git을 활용한 웹 개발과 실무의 이해 (2) | 2024.11.07 |
|---|---|
| [Git_58] 알아 두면 유용한 Git (.gitignore, blame) (0) | 2023.12.05 |
| [Git_56] 태그(Tag) - 삭제하기 & 브랜치 (1) | 2023.05.14 |
| [Git_55] 태그(Tag) - 서버(원격) 저장소와 태그 정보 동기화 (0) | 2023.05.13 |
| [Git_54] 태그(Tag) - 상세 정보 확인 (0) | 2023.05.12 |
댓글