✍️ 협업을 통해 알게 된 Git 그리고 Github

개요

오늘 제가 작성할 내용에는 제가 프로젝트를 하며 경험하고 배웠던 내용이 담겨있습니다. 저는 올해 iOS 개발을 시작한 후 지금까지 그간 4번의 팀 프로젝트를 경험했는데, 정말 협업에 대해 1도 몰랐던 사람에서 현재는 그래도 어찌됐든 1인분의 역할 정도는 하게 된 것 같다는.. 생각을 하고는 있습니다😂

과거에도 깃이 정말 중요하다는 말을 들었지만, 저는 실제 협업을 경험하기 전까지는 그걸 깨닫지 못했었습니다. 이제는 여러 번의 협업 흐름을 경험했고, 점점 몸에 익기 시작하는 지금 시점에 Git과 Github가 얼마나 중요하게 쓰이는 지 얼른 정리를 해 두어야겠다 싶어서 글을 작성하게 되었습니다.

 

 

(제가 경험한) 협업의 흐름

* 경우에 따라 다를 수 있습니다.

 

팀 안에 협업 경력자가 있다면, 보통은 개발 시작 전 아래의 과정들을 주도하시게 됩니다. 경력자가 없더라도 충분히 가능하지만요!

(깃 레포지터리 생성 및 세팅각종 컨벤션 및 규칙 정하기, 프로젝트 설정, 디렉터리 구조, … 기타 등등)

 

본격적으로 개발이 시작되면,

 

개발자들이 각자 맡은 태스크를 깃헙에 Issue 로 등록합니다.

 

그런 뒤 각자의 레포지터리에서 이슈에 맞는 branch 를 생성합니다.

 

저는 계속 Feature 단위로 작업을 했었기 때문에, 하나의 task — 즉 Feature 단위로 브랜치를 생성하였습니다.

 

danila/notesView, feature/#32_notesView 등등 방법은 다양합니다.

 

보통은 편의를 위해 이슈 번호를 브랜치에 넣습니다.

 

 

작업이 끝이 나면,

 

각자 자신의 브랜치에서 열심히 개발을 한 뒤 끝이 나면 코드를 Push합니다.

 

Push 후 Github에서 작업 내용이 상세히 담긴 Pull Request를 날립니다.

 

동료 개발자들 또는 디자이너/PM 들로 부터 코드 리뷰를 받습니다.

 

변경사항이나 실수가 있다면 즉각 수정하고 Push합니다.

 

일정 기준 이상의 Approve를 받으면 머지합니다.

 

이 때, 올리고자 하는 브랜치와 Conflict가 있으면 해결 뒤에 머지를 합니다.

 

여기까지가 제가 경험한 대략적인 개발 과정이었습니다.

 

하지만 매우 간략하게 정리한 만큼, 더 깊게 알아야 하는 내용들이 더 숨어있습니다.

 

 

브랜치 전략

보통의 경우엔 main → develop으로, 출시와 유지보수가 계획된 프로젝트라면 main → develop → release 세 단계가 존재했습니다.

 

main

• 출시된 버전만 존재하는 브랜치입니다.
• Hotfix (급하게 수정해야 하는 버그 등등이 적용됨) 용 브랜치로도 쓰입니다.

 

develop

• 지금까지 개발 내역이 담겨 있습니다.
• 버그를 수정하는 데 쓰이기도 합니다.
• 현재 진행중인 스프린트에 포함되지 않는 작업을 할 때, develop 브랜치로부터 새로운 브랜치를 따서 작업을 합니다.

 

release

• 스프린트 작업 (출시를 위한) 브랜치입니다.
• 현재 진행중인 스프린트에 포함되는 작업을 할 때, release 브랜치로부터 새로운 브랜치를 생성하여 작업합니다.

 

 

브랜치 원칙

제가 팀에서 사용했던 브랜치 운용 원칙입니다.

 

스프린트 시작 상태

• develop → release

release (스프린트 용) 브랜치를 하나 더 두는 이유는 release 브랜치엔 스프린트에 해당되는 작업들만 존재할 것이기에 버그나 오류를 파악하기가 쉽기 때문입니다.

 

 

스프린트가 진행되면

• release → releaseLocal (자유)
• releaseLocal → dani/feature1 , …

releaseLocal 브랜치는 굳이 딸 필요는 없지만, 저는 초기의 release 브랜치 상태를 간직하기 위해 사용했었습니다.

 

• develop → develop 으로는 버그 수정 외에는 웬만하면 머지하지 않습니다.

버전 관리를 위해서입니다. 오류의 시작점이 확실치 않으면 문제를 해결하기가 쉽지 않습니다.

 

• release (에서 딴 브랜치)→ release 로 머지합니다.

이미 초기 release 상태가 보장되어 있고, 뒤늦게 한꺼번에 merge를 하면 무수한 컨플릭이 날 수 있기 때문에 머지 준비가 되는 즉시 release로 머지를 합니다.

 

 

스프린트에 들어가지 않는 작업

• develop 에서 따서 계속 작업하다가 스프린트 머지될 때마다 코드를 최신 상태로 유지하고, 스프린트에 해당될 때 해당 release 로 PR을 날려야 합니다.

그런데 스프린트에 들어가지 않는 브랜치는 오래 놔두지 않는 게 좋습니다. 코드가 업데이트 될 때 마다 계속 pull을 해서 conflict를 해결하는 게 쉽지 않기 때문입니다. 이 문제를 해결하기 위해 스프린트에 들어갈 정도로 태스크를 쪼개는 것을 추천합니다.

 

 

Origin과 Upstream (fork)

저는 주로 팀원 모두가 원본 레포지터리를 Clone 해서 작업을 했었습니다. 그런데 팀원 수가 많았던 한 프로젝트에서는 원본 레포지터리를 모두가 Fork 해서 작업을 했었습니다.

 

이유는, Fork를 하면 우선 원본 브랜치에는 필요한 브랜치만 남길 수 있어서 깔끔합니다. 그리고 잘못 push를 하더라도 바로 머지되는 게 아니라 PR를 반드시 거쳐야 하기 때문에 원격 레포지터리의 코드가 보호받을 수 있습니다.

 

이 때 Origin은 Fork해서 새로 생긴 복사된 나의 레포지터리를 의미하고, Upstream은 원본 레포지터리를 의미합니다. 때에 따라 적절한 곳에서 pull을 받고 push를 하기 위해서는 Origin과 Upstream을 잘 알고 사용하는 것이 중요합니다.

 

 

세 가지 종류의 Merge

Merge에는 세 가지 종류가 있습니다.

 

Pull Request에서 머지를 할 때

1) Create a merge commit, 2) Squash and merge, 3) Rebase and merge

 

이 세 가지 옵션이 나옵니다. 간단하게는,

1. 커밋 기록이 남고 기존 브랜치가 트리에 그대로 남는 방식
2. 한 브랜치의 커밋 기록을 합쳐서 기존 브랜치에 병합하는 방식
3. 브랜치의 커밋 기록이 각각 기존 브랜치에 순서대로 모두 옮겨오는 방식

 

이렇게 요약할 수 있을 것 같습니다. 관련한 다양한 블로그 글들이 있으니 확인해 보시면 좋을 것 같습니다. 협업과 관련해서는, Squash 머지나 Rebase 머지가 Tree가 깔끔하게 남기 때문에 선호하는 편입니다.

 

 

Github의 다양한 기능

깃헙에는 코드를 올리고 받고 합치고 하는 것 말고도 다양한 기능이 있습니다. 팀끼리 합의하여 적극적으로 사용한다면 매우 유용하게 쓰일 수 있다고 생각합니다.

 

• wiki

이름에 걸맞게 여러 가지 정보들을 적어놓을 수 있는 공간입니다. 보통은 팀원들 모두가 참고할 수 있게 다양한 컨벤션을 적어놓습니다. 그리고 가끔은 데일리 스크럼이나 스프린트 진행상황을 Wiki에 기록해 놓는 경우도 있었습니다.

 

• projects

프로젝트 칸반을 관리할 수 있는 공간입니다. 원하는 대로 여러 자동화 설정을 할 수 있습니다. 보통은 이슈가 올라오면 자동으로 Todo, PR이 올라오면 In Progress, Approve 후 머지되면 Done으로 이동하게 됩니다.

 

• Actions

PR이 올라온 코드에 대해 빌드 테스트를 하도록 하는 기능입니다. 따로 확인하지 않아도 빌드 오류가 있는지 알 수 있어서 편리합니다.

 

• Discussion

여러 내용을 자유롭게 적고 이야기 나눌 수 있는 공간입니다. 토론을 하는데 활발히 사용되지는 않지만, 보통은 새롭게 알게된 정보나 공유하고 싶은 정보를 적기도 합니다. 개인적으로 좋아하는 공간입니다:)

 

 

마무리하며

오늘 단순히 깃을 정리한 게 아니라 협업을 위한 깃과 깃허브를 정리했다는게 저 개인적으로는 의미가 있는 것 같습니다. 계속해서 팀 프로젝트를 하며 정말 열심히 배우고 있긴 하지만, 아직도 주변 능력자 분들을 보면 UITest, RxSwift, .. 등등 제가 알지 못하는 툴에 대해 관심을 가지고 계십니다. 언제쯤 그들을 따라잡을 수 있을지.. 걱정도 많이 듭니다. 그런데 보다 보면 단계가 있는 것 같다는 생각이 들었습니다. 단계가 있다는 건 따라갈 길이 있다는 것이니 다행이라고 생각이 드네요! 이제 어떻게 빠르게 그 단계를 따라 갈 수 있을지 고민하고 노력해야겠습니다.

 

귀여운 옥토캣