GitHub 활용법

현재 Dreamfora는 GitHub을 기획, 디자인, 개발 팀 모두가 함께 사용하고 있습니다. 우리가 사용하고 있는 방법을 서술합니다.

1.7 버전 업데이트 작업을 진행하면서 겪었던 문제들을 해결하고자 도입하였습니다. 자세한 내용은 링크 타고 들어가시면 보실 수 있습니다. (https://dvlv.tistory.com/130 )

GitHub 기본적인 사용은 https://github.com/nathankim0/DreamforaV2/discussions/2 에서 확인하실 수 있습니다.

Repository

현재 2개의 Repo를 사용하고 있습니다.

• Dreamfora/DreamforaV2 (upsream)
• nathankim0/DreamforaV2 (origin)

Dreamfora/DreamforaV2 가 메인 Repo 입니다. upstream 입니다. 2주마다 6개의 개발 안건을 선택하여 여기서 Issue로 발행합니다. 이 6개의 Issue를, 개발팀 내부 회의를 통해 누가 어떤 Issue를 개발 할 지 결정하여 Assignee로 지정합니다. David이 추가 Issue 발행과 Issue 최종 결정권자입니다. 만약 2주가 지나지 않은 상태에서 지정한 6개 Issue 보다 더 개발이 필요하거나 시급한 상황, 할당된 Issue가 빨리 끝났을 경우엔 당시 판단에 따라 추가적으로 Issue를 발행할 수 있습니다. 본 Repo는 개발팀에서만 사용합니다.

nathankim0/DreamforaV2 는 Dreamfora/DreamforaV2를 Fork 한 Repo 입니다. origin 입니다. 모든 개발작업과 세부적인 Issue 발행, Discussion은 본 Repo에서 진행합니다.

Issue, Branch

모든 개발은 Issue 단위로 진행합니다.

upstream에 할당된 나의 메인 작업들은 origin에 작은 단위의 Issue로 쪼개서 작업합니다. 새로 Issue를 발행할 때엔 Category, 본인의 Project(칸반보드)와 Milestone을 반드시 지정합니다. 작업 진행도를 확인하기 위해서 입니다. 필요시에, 관련 작업 인원들을 Issue에 @로 태깅하거나 Assignees 로 지정합니다.

origin의 Issue가 잘 나누어져 있다면 개발을 시작합니다. Issue의 이름을 따서 dev에서 추출하여 branch를 생성합니다. Branch명은, "카테고리/#이슈번호/제목" 이런식으로 명명합니다. (예시: feat/#38/profile_page_ui)

Issue 단위로 개발하게 되면, 작업이 명확하게 구분되기 때문에 현재 작업에 온전히 집중할 수 있습니다. 또한, 다른 개발 사항과 혼용하여 작업하는 것을 미리 방지할 수 있습니다. 건별로 tracking이 가능하므로 Issue의 진행사항을 파악하기가 쉽고, 여러 의견과 기획의 변경 등이 백로그로 남기 때문에 언제든지 작업 Branch를 변경하며 헷갈리지 않고 작업할 수 있습니다.

백로그를 쌓기 위해, 기획팀의 의견 전달, 개발팀 내부 논의 등은 되도록 Issue에 reply 로 남기도록 합니다. 이렇게 해야 나중에 누가 어떤 말을 했고 어디까지 진행했으며 무엇이 잘못되었는지 확인이 빠르고, 중복된 회의를 방지할 수 있습니다.

Commit

Branch 내에서 작은 개발 단위로 Commit을 합니다. Commit 당시의 프로그램은 잘 돌아가는 것을 원칙으로 합니다. (빌드-실행) Commit 메세지는, "카테고리: 작업내용" 이렇게 작성합니다. 자세한 내용은 Dremafora Commit Convention에서 확인하실 수 있습니다.(https://github.com/ghojeong/dreamfora/wiki/Commit-Convention)

작업 진행

작업 공간은 크게 3가지입니다.

• local : 서버(origin, upstream)과 관련없는 컴퓨터 로컬 작업공간
• origin : local과 remote로 연결된 repository (Fork된 nathankim0/DreamforaV2)
• upstream : 메인 Repository. (Dreamfora/DreamforaV2)

local에 Commit을 한다고 GitHub Repository (origin, upstream) 에 바로 동기화 되는 것이 아닙니다. local에서 'git push' 혹은 'git push origin <branch명>' 이런식으로 push를 해야 반영됩니다.

origin의 본인의 개발 (branch) 이 끝나면, QC를 하고, origin/dev 에 pull request 합니다. 문제 없을 시 merge 합니다.

앱 업데이트를 하면 origin/dev - > upstream/master 로 pull request 합니다. dev에 문제가 없을 때 merge 했었기 때문에 master에 merge 할 때도 잘 되는 것이 보장되어야 합니다.

upstream/master 가 앱 최신 버전으로 merge 된 이후엔 release 에 패치노트를 적고 새 버전 태그로 release 합니다.

• master : 스토어에 올라와 있는 앱 최신 버전
• dev : 업데이트 전 개발 최신 버전

Fetch

local은 origin 과 upstream의 변경사항을 모릅니다. origin과 upstream의 내용을 땡겨올 때는 반드시 fetch를 해야합니다. 명령어는 'git fetch origin' 혹은 'git fetch upstream' 입니다.

Rebase

모든 작업이 끝나면 master 브랜치를 dev, master upstream/dev, 에 Rebase를 하고 dev (local) 는 origin/dev 에, master (local) 은 origin/master에 push 합니다. 이렇게 하면 모든 dev와 master 브랜치가 같은 위치에 있게 됩니다. rebase를 하기 전에는 현재 작업하고 있는 것들이 stash 나 commit 이 되어야합니다.

Rebase를 하는 방법은 2가지가 있습니다.

1. git checkout dev -> git rebase upstream/master
2. git rebase [basebranch] [topicbranch] (=>base에 topic을 rebase 한다)