[Git & GitHub] -14- 협업 워크플로우

Shy·2023년 3월 14일

목록 보기

12/13

이 섹션에서 가장 중요한 것

Critical!	Important	Nice To Have
The Problems With Working On A Single Branch
Feature Branch Workflow
Pull Requests
	Branch Protection Rules
Forking
Fork And Clone

중앙 집중형 워크플로우의 함정

제일 먼저 다룰 협업 워크플로우는 중앙 집중형 워크플로우이다.
공식 명칭은 아니지만, 협업 워크플로우중 단연 최악의 워크플로우이다.
그래도 소개해주는 이유는 중앙 집중형 워크플로우의 단점이 앞으로 다룰 다른 워크플로우에서는 커바가 되기 때문이다.
그러면, 다른 워크플로우가 더 복잡하지만 사용해야만 하는 이유가 납득이 된다.

이 것은, 모두가 master branch(혹은 메인branch)같은 한 브랜치에서 작업을 한다.
그러므로 제일 단순한 형태의 워크플로우이다.
그러므로, 다른 브랜치에서 작업하거나 병합하지 않는다.

세 사람이 같은 repo에서 clone을 했다.

데이빗이 열심히 개발하고 2개의 새로운 커밋을 마스터 브랜치에게 한다.

데이빗이 그것을 푸쉬했다.

파멜라도 열심히 개발을 했다.

파멜라는 푸쉬를 하지만, 실패했다.
푸쉬 메시지를 확인하니, '브랜치 끝이 리모트브랜치보다 뒤에 있어 업데이트가 거부 된다. 푸시하기 전에 업데이트 사항을 확인해라.'

pulls를 한다. 그런데, 이렇게 merge를 하면 충돌이 일어날 수도 있음.

이제 푸쉬에 성공을 했다.
이제 깃헙에 4개의 커밋이 있다.

David은 홀로 개발을 하고 있었는데, 기능이 제대로 작동을 하지 않는다.
반 정도만 개발을 한 상태이고, 중요 코드를 삭제하고, 코드 일부분을 주석 처리를 해서 엉망이 되어버렸다.
그래서, 동료들에게 도움을 받고 싶었다.
지금까지 작업한 것을 로컬에서 커밋했다.

이 엉망진창인 코드를 푸쉬하기 위해, 깃허브의 마스터 브랜치에 반영해 놓은 내용과 merge해야만 그제서야 푸쉬를 할 수 있다.

데이비드는 코드 베이스를 건드려 버렸다. (미완인 상태로)
때문에 모두가 미완 상태인 코드를 가지게 돼버렸고, 실로 분노를 금할 수 없는 상황이 되었다...
유일한 브랜치인 마스터 브랜치를 엉망으로 만들어 버렸기 때문이다.

개발자들 모두가 충돌 해결에 오랜 시간이 걸린다.
머지에도 오랜 시간이 걸린다. (충돌)
그 누구도 기본 코드를 건드리지 않고 작업을 할 수 없다.

이 방법을 해결하기 위해선, 마스터 브랜치에 완벽하게 완성되고 검증된 코드만 푸시하지 않는 이상 협업할 수 있는 방법이 없다.

팀이 작고, 실험적인 작업을 하지 않는다면... 써도 되지만 웬만해선 쓰지 않는 게 좋다.

참고할만한문서

중앙 집중형 워크플로우 데모

중요한 Feature Branch 워크플로우

작업을 각자의 개별 브랜치에서 하고, 나중에 마스터브랜치(메인브랜치)에서 병합한다.

누군가가 자기 코드가 검증된 코드라 착각하고 마스터나 메인 브랜치에 머지하지 않는 이상 마스터나 메인 브랜치는 훼손되지 않는다.

세 사람 모두 같은 깃헙을 클론했다.

다 같은 저장소를 클론했다.

David는 자신이 한 일이 add-dark theme이다.

일이 어느정도 진행 된 상태에서 일을 공유한다. (개별 브랜치에)

Pamela도 자신의 일을 개별 브랜치에서 진행한다.

David에게 슬랙 메시지가 왔는데, 자신이 한 작업을 Pamela에게 확인해 달라며 브랜치 이름(dark-mode)을 가르쳐준다.
Pamela는 David가 말한 브랜치를 Pull해서 당겨 간다.
Pamela는 하던 일을 멈추고 자신의 작업을 다른 브랜치로 머지할 필요가 없었다.
본인이 작업하단, animated-scroll 브랜치를 그대로 둘 수 있었다.
본인 코드를 아직 공유할 수 없었으니, 데이비드의 브랜치를 그냥 Pull한다.
(리모트 브랜치로 전환하고, Fetch하면 로컬엔 없지만 추가된 브랜치가 있는지 확인하고, 그 중 한 브랜치로 전환 할 수 있었다.)
Pamela는 add-dark-theme 브랜치를 가지고 온다. 이 과정 중에서 마스터 브랜치나 파멜라의 animated-scroll브랜치는 어떤 영향도 받지 않는다. 즉, 두 브랜치가 공존할 수 있다.

Pamela는 일부 개선하고, 해당 피처 브랜치에 커밋을 한다.
기존에 커밋은 3개였지만 4개가 된다.

Pamela는 자신의 일(add-dark-theme)브랜치를 Push하고, 데이비드에게 코드를 추가하고 깃헙에 올렸으니 업데이트 버전을 가지고 가라 한다.

데이빗은, 일에 돌아오고 나서, 원래 일을 하려 한다.
지금 데이빗의 로ㅓㄹ에는 3개의 커밋이 있다.

파멜라가 올려놓은 코드를 가지고 와서 일에 복귀한다.

기능 구현을 완료하면, 데이비드는 자신의 코드를 마스터브랜치로 머지한다.
나름 규모가 있는 회사에서는 아무도 자기 코드를 마스터 브랜치로 머지하겠다고 스스로 결정하지 않는다.
보통 절차를 따르고, 리뷰를 받은 다음에야 코드를 머지할 수 있다.

마지막으로, 머지한 것을 푸쉬한다.

Feature Branch 워크플로우 데모

스티비, 콜트가 협업을 한다고 가정하자.

먼저, 스티비가 클론을 하고 작업을 한다. 메인 브랜치에서 작업을 하는 것이 아니라, (add-navbar)라는 브랜치로 작업한다.

우선, git switch -c navbar 로 만든다.

로컬에서 작업을 하다가, 문제가 발생해서 다른 사람과 문제를 공유하기 위해, push를 한다.

git add index.html
git commit -m "add broken navbar"
git push origin navbar

그 동안 콜트는 자신의 작업을 한다.
그 전에 항상 확인할 것은, 메인 브랜치에 변경사항이 있는지 확인하는 것이다. (항상 메인 브랜치를 최신 상태로 유지해야 한다.)

git pull origin main (변경사항이 없음을 확인)
git switch -c pricing-table

이제 새 브랜치에서 작업을 한다.

git add index.html
git commit -m "pricing table"
git push origin pricing-table

이제 두 브랜치가 생겼는데, 보통, 작업을 할 때 피처 브랜치가 셀 수 없이 생성되지만, 메인이나 마스터 브랜치에 푸시하더라도 머지가 완료되면 그 브랜치는 삭제 된다. 머지가 됬다면 남아있을 이유가 없기 때문이다.

아무튼, 콜트로 돌아와서, 콜트는 스티비에게 슬랙 메시지를 받는다.
스티비가 navbar를 푸쉬했는데, 왜 작동이 안되는지 모르겠다고 한다.

해결을 위해서 먼저 해야 될 것은, 브랜치를 풀 다운 하는 것이다.

git fetch를 하여, 새로운 변경사항이 있는지 확인한다.

git fetch origin
navbar 브랜치가 생성된 것을 확인
git checkout origin/navbar (헤드가 분리되고, 체크가 가능하다. navbar 작동 안되는 것을 확인)
git switch - (다시 pricing-table브랜치로 돌아옴.)

navbar브랜치로 전환하고 싶으면, git switch navbar을 입력하면, 콜트의 컴퓨터에 navbar브랜치가 없어도 깃이 자동으로 navbar를 생성하고 원격 브랜치인 origin/navbar를 자동으로 연결해서 origin/navbar를 추적하도록 설정해 준다.

git switch navbar

위 문구를 입력하면, 위에서 설명한 대로
Brach 'navbar' set up to track remote branch 'navbar' from 'origin'
이 된다.

이제 스위치가 되었으니, 문제를 해결한다.
콜트 계정으로 수정사항을 변경하고 업로드 한다.

git add index.html
git commit -m "fix navbar bug"
git push origin navbar

이제 콜트는 자신의 작업으로 복귀를 한다.

git switch pricing-table

가격표 작업을 계속해서 작업을 한다.

한편, 스티비는 해결된 버그를 보기 위해, 최신 버전을 당겨 오거나 혹은 navbar 브랜치만 당겨갈 수 있다.

git pu;; origin navbar

협업을 하니 더 쉽게 작업이 가능하다.

Feature Branch 병합하기

위에서 협업워크플로우를 배웠지만, 콜트나 스티비 그 누구의 작업도 메인 브랜치나 마스터 브랜치에 반영되지 않았다.
피처 브랜치를 이용하는 것 만큼 머지도 중요하다.
방법은 두가지가 존재하는데,

누구든지 자기가 머지하고 싶은 모든 코드를 다 머지하는 것, 메인에 머지해 버리는 것이다

이럴 경우 당연히 문제가 발생한다. 특히 팀 규모가 크다거나 협업하는 사람이 많다거나 추가하는 기능이 많으면 더욱 그렇다.
머지하기 전에 테스트하는 과정이 없다거나, 확인이나 논의하는 과정이 없다면 제어하기 어려운 상황이 발생할 것이다.
엔드 유저에게 배포하는 실제 제품 개발을 이렇게 하면 안되고, 친구들과 하는 취미 프로젝트에서는 가능하다.

자신의 브랜치를 머지하되 반드시 논의를 거친 뒤에 확인한다.

팀과 상의를 하여 본인이 작성한 코드를 머지할 것인지 확인

세 번째 방법도 존재한다. 바로 Pull Request이다. (이 방법은 다음 시간에 다룬다)

우선 이 섹션에선 Merge하는 방법을 배운다.

위에서 한 작업에서, 프로젝트 오너가 pricing-table을 작업했다.
이제 메인 브랜치로 switch를 한 다음에, 깃허브에서 풀을 해서 놓친 변경사항이 없는지 확인한다.

git pull origin main

변경사항이 없음을 확인

git merge pricing-table

충돌도 없고, 잘 되는 것을 확인 할 수 있다.

방금 피처 브랜치를 머지했으니, 이제 메인 브랜치로 푸쉬할 수 있다.

git push origin main

깃 허브로 가면, 이제 메인 브랜치는 가격표 코드가 반영 되었다.

이제 스티비가 해야 할 일은 업데이트된 메인 브랜치를 당겨 가지고 오는 것이다.

변경사항을 반영해야 하면, 메인 브랜치로 전환해서 가져오면 된다.

git switch main
git pull origin main

이제 스티비의 메인 브랜치에는 모든 변경사항이 적용되었다.

스티비도 머지하기로 했다면, 같은 과정으로 진행하면 된다.

Pull Request 소개

줄여서 PR이라 한다.
이것이 필요한 이유와 활용하는 이유를 다룬다.
PR을 하면, 코드 검증을 거친다.

풀 리퀘스트는 깃의 기능이 아니다. 깃허브나 빗버킷 같은 플랫폼에서 활용하는 기능이다.

PR은 개발자가 새로운 작업을 브랜치에 올렸을 때 팀원이나 공동 작업자들에게 검토를 요청하고 머지를 승인 혹은 반려해달라고 요청하는 장치이다.

이제 논의가 진행되고 피드백이 되면, 검토 결과를 반영한다.

깃허브에서 Pull Request (PR)를 하는 이유는 주로 다음과 같습니다:

코드 협업: PR은 개발자들이 원격 저장소에 있는 코드를 수정하고, 다른 개발자들과의 협업을 용이하게 해줍니다. PR을 통해 다른 사람들이 변경 사항을 검토하고 토론할 수 있으며, 필요한 경우 추가 수정을 제안할 수 있습니다.
코드 검토: PR을 사용하면 다른 개발자들이 변경 사항을 확인하고 피드백을 제공할 수 있습니다. 이 과정에서 발견된 오류나 개선점을 수정하면서 코드의 품질을 향상시킬 수 있습니다.
버전 관리: PR은 깃(Git)의 브랜치 기능과 결합되어 사용됩니다. 브랜치를 통해 여러 버전의 코드를 동시에 관리할 수 있으며, PR을 통해 브랜치를 합치거나(main branch에 merge) 변경 사항을 반영할 수 있습니다.
추적 가능성: PR은 변경 사항에 대한 설명과 함께 제출되므로, 프로젝트의 변경 이력을 추적할 수 있습니다. 이를 통해 변경 사항의 이유와 주요 변경점을 나중에 참조할 수 있으며, 팀원 간의 투명성을 높입니다.
지속적 통합 및 배포: PR을 사용하면 지속적 통합(Continuous Integration, CI) 및 지속적 배포(Continuous Deployment, CD)와 같은 현대적인 개발 방법론을 적용할 수 있습니다. PR을 통해 코드가 테스트되고 검토되며, 이를 바탕으로 안정적인 코드만 main branch에 통합되어 배포됩니다.