git을 이용한 4명의 프로젝트 이야기

구성 인원

팀장 1명

팀원 3명

주제 : 피보나치 함수와 하노이 함수 구현

역할 : 피보나치 구현(recursion), 일반식 피보나치 구현, 하노이 함수 구현

여러사람과 프로젝트를 하기 위해서 거쳐야 하는 과정에 대해 모두 서술하려고 한다.

그 예시로 1명의 팀장과 3명의 팀원이 한 팀을 꾸려 프로젝트를 하는 이야기를 모두 적어보려 한다.

시작

4명은 모여서 피보나치 함수와 하노이 함수를 구현해야 하는 상황에 놓였다. 한명이 모두 구현할 수 있는 시간이 안 된다. 4명은 일을 분배해서 일을 시작하려 한다.

팀원 1이 구현해야 하는 일은 피보나치 함수를 재귀식으로 구현하는 것이다.

팀원 2는 비넷 일반식을 이용한 피보나치의 일반식을 통해 피보나치 함수를 구현하는 역할을 맡았다.

팀원 3은 하노이 함수를 구현하는 역할을 맡았다.

repository 생성

팀장은 fibo and hanoi 라는 repository를 생성했다. 그리고 이 repository의 링크를 모두에게 뿌려주었다.

issue 등록 및 develop 브랜치 생성

팀장은 repository를 생성 한 후, develop 브랜치를 생성했다. 이 develop 브랜치에서 모든 작업이 이루어질 것이다.

팀원들은 본인들의 해야할 일들을 로직 바이 로직 to do list로 만들어 이슈로 등록했다. 예시로 팀원 3의 issue는 아래와 같다.

fork

develop 브랜치가 완성되었으니 팀원들이 fork를 해서 본인들의 repository로 가져올 차례다. 팀장의 repository에서 오른쪽 위를 보면 fork 버튼이 있다. 내가 작업을 수행할 계정이나 organization으로 fork 해왔다. 그리고 로컬에서 작업하기 위해 팀원들은 이 repository를 개인 로컬 작업 공간으로 clone 했다.

upstream으로 팀장의 remote 저장소 연결

clone한 로컬 저장소에 팀원들의 코드가 모일 remote 저장소를 upstream으로 연결해주어야 한다.

git remote add upstream "저장소 주소" 

로 연결해주자.

작업 브랜치 생성

팀원들은 git flow를 이용해서 효율적인 작업을 하기로 했다. develop 브랜치를 기반으로 작업하고 있으니, 새로운 기능을 추가하기 위해 새로운 feature 브랜치를 따서 작업한다. 팀원 2는 피보나치 일반식을 구현하기 위해 feature/feature-binet 이라는 브랜치를 새로 생성했다.

git flow feature start feature-binet 

해당 명령어를 통해 feature 작업을 위한 flow를 열었다.
마찬가지로 다른 팀원들도 각자의 작업을 위해 flow를 열었다.

작업

팀원 2 는 작업을 완료했다. 생각보다 간단한 구현이었다. 좋은 커밋 메시지로 커밋을 완료하고 잠깐의 뿌듯함을 느낀 뒤 git flow를 마무리하려 한다.

git flow feature finish feature-binet 

명령어를 통해 feature-binet 브랜치를 마무리 하고 다시 develop 브랜치로 병합해 주었다. 그리고 바로 자신의 리모트 develop 브랜치로 푸쉬 한 뒤 팀장에게 pull request를 보냈다.

작업2

팀원 1은 팀원2가 작업을 끝내는 것을 보고 자극을 받아 즉시 피보나치 함수를 구현해냈다. 마찬가지로 좋은 커밋 메시지로 커밋을 완료하고 git flow를 마무리했다.
옆을 슥 보니 팀장이 pull request 요청을 확인하고 해당 커밋들을 모두 승인했다. 팀원1는 바로 push를 하고 싶지만 지금 푸쉬를 하면 conflict가 발생할 것이다. 왜냐하면 이미 팀원2이 올린 커밋이 upstream 저장소에 반영되었기 때문이다.

팀원1의 로컬 저장소는 아직 이 upstream 저장소의 내용이 없기 때문에, 팀원1의 로컬 저장소를 push 하고 pull request를 넣어버리면 conflict가 발생한다. 때문에 팀원1은 먼저 upstream 저장소를 pull 해준 후 conflict를 해결 한 뒤 push를 실행해야 한다. 지금 같은 경우 다른 파일에서 작업이 일어나기 때문에 pull 할 시 conflict는 발생하지 않겠지만, 만약 같은 파일에 다른 작업을 했다면 pull 시에도 conflict가 발생한다. 이를 잘 처리해주어야 한다.

pull을 완료하고 팀원1은 마찬가지로 fork 한 리모트 저장소에 작업내용을 push 했다. 그 후 pull request를 팀장에게 보냈다.

issue close

팀원2는 pull request가 완료된 것을 확인하고, 이슈의 체크리스트를 모두 체크했다. 그리고 팀장에게 해당 issue를 닫아줄 것을 요청했다.

야근

팀원3은 하노이 함수를 구현하지 못해 야근을 한다. 팀원2는 본인이 작성한 테스트 코드에 문제가 있던 것을 팀장이 발견했다. 오늘 밤까지 다 고쳐놓으라는 불호령을 받은 팀원2는 야근을 시작한다. 팀원2는 다시 issue를 등록하고 git flow를 열어 feature 수정을 시작했다.
팀장은 한심한 눈으로 둘을 쳐다보며 다 끝내고 pull request 해놓으면 내일 와서 확인하겠다며 퇴근을 했다.

release

팀장은 다음 날 와 완벽하게 처리가 완료된 pull request를 확인했다. 팀장은 모든 pull request를 승인한 뒤, 간단한 코드 리뷰를 남겼다. 팀장은 기특해 하며 release를 준비한다. test를 다시 돌려본 뒤 문제가 없는 것을 확인하고,

git flow release start v1.0 

을 작성해 실행시켰다.

release는 최대한 빠르게 종료하는 것이 좋기에,

git flow release finish v1.0
으로 바로 브랜치를 닫아주었다. main 브랜치에 모든 것이 merge 되었고, 기존에 연결해두었던 자동화된 배포 서비스를 통해 배포까지 완료되었다.

이제 사람들은 피보나치 함수의 실행 결과를 명령어를 통해 찾아볼 수 있을 것이다.

ver1.1

팀장은 욕심이 생겼다. 조금 더 빠르고 메모리를 효율적으로 사용하는 피보나치 함수를 구현하고 싶어졌다. memoization을 이용해 더 빠른 피보나치 함수를 구현할 수 있다고 생각해 낸 팀장은 recursion으로 피보나치를 구현해 낸 팀원1을 불러 호통을 쳤다.
대충 끝내고 퇴근하려고 하니, 이런 효율 떨어지는 코드를 짠다며 잔뜩 혼이 난 팀원 1은 메모이제이션을 이용해 구현을 시작하려고 했다.

issue 등록 및 feature branch 따기

팀원1은 작업을 위해 다시 issue에 해당 내용을 등록하고 feature 브랜치를 땄다. 그리고 끙끙거리며 memoization을 이용한 피보나치 함수를 구현했다. 다른 팀원들이 어제 새벽까지 고생하며 짠 코드를 아직 pull 하지 못했으므로, 먼저 pull을 실행 했다. 하지만 어제 binet 피보나치를 구현한 팀원2가 팀원1과 같은 파일명을 사용해 conflict가 났다. 이걸 잘 못 처리하면 팀원의 코드가 모두 날아가 버릴 것이다. 팀원1은 침착하게 pull 을 취소하고 파일명을 바꾼 뒤 다시 pull을 했다. 이번에는 conflict없이 잘 동작했다.

마무리

push 를 마무리한 팀원1은 pull request를 넣어두고 팀장에게 리뷰를 부탁했다. 팀장은 바쁘다며, 나중에 하겠다고 했다. 팀원1은 본인의 코드가 테스트는 모두 통과했지만, 코드 퀄리티에 크게 자신이 없었기 때문에, 이대로 퇴근하면 내일 크게 혼이날 거 같아, 일단 기다렸다. 그렇게 개발자의 밤은 깊어갔다.

이 내용을 무한반복하는게 개발자의 git으로 하는 프로젝트다.