깃 허브 플로우(Github Flow) 이해 하기

6 min readJul 15, 2021

https://guides.github.com/introduction/flow/ 를 나를 위해 번역한 글

깃허브 플로우는 팀 간 프로젝트의 수정이 자유롭게 이뤄지도록 돕는다. 이 글은 어떻게 깃허브 플로우가 진행되는지 설명한다.

1. 브랜치를 만든다. (Crate a Branch)

브랜치란 메인의 복사본이라고 생각하면 쉽다.

프로젝트를 진행할 때 여러 새로운 특징들 그리고 아이디어 — 그 중 몇몇은 코드를 작성할 수 있는 것들이고 몇몇은 아이디어만 있는 것 — 들이 생긴다. 브랜치는 이 WorkFlow를 관리할 수 있게 해주는 핵심 키워드다.

브랜치 (브런치아님) 를 만든다는 것은 새롭게 시도하고 싶은 아이디어를 실행해 볼 환경을 만드는 것 이다. 브랜치는 main 브랜치에 영향을 주지 않는다. 따라서 마음대로 시도하고 commit (쉽게 말해 코드 수정 및 추가) 해도 된다. 같이 일 하는 사람들의 리뷰가 진행되기 전에는 main에 합쳐지지 않으므로 자유롭게 실험하면 된다.

2. 코드를 바꾼다. (Add Commits)

브랜치가 만들어지면 이제 코드를 바꿀 차례다. 파일을 추가, 수정, 삭제하는 것은 Commit 을 해서 브랜치에 추가하는 것이라고 보면 된다. Commit을 추가하는 과정은 Feature 브랜치(main이 아니라 너가 새롭게 만든 브랜치) 에서 작업을 하면서 너의 진행상황을 체크할 수 있게 해준다.

Commit들은 또한 다른 사람들이 너가 무엇을 그리고 왜 코드를 수정 했는지 이해 할 수 있도록 너의 작업의 기록들을 투명하게 보여 준다. 각각의 commit 들에는 관련된 commit Message를 쓸 수 있는데, 이 메시지는 왜 그렇게 파일을 작성했는지 설명 한다. 게다가 각각의 commit은 한 단위별로 처리되어서 만약 버그가 발견되거나 중간에 다른 방향으로 코드를 바꾸고 싶으면 언제든지 roll back 할 수 있게 해준다.

커밋을 서버에 올리면 Git이 너의 작업을 저장하고 보여주기 때문에 커밋 메시지는 매우 중요하다. 커밋 메시지를 정확하고 간결하게 써야 다른 사람들이 피드백주고 따라오기 더욱 편하기 때문이다.

3. 합치기 요청하기 (Open Pull Request)

Pull Request (합치기요청)은 너의 커밋에 대한 의견을 공유할 수 있게 한다. 너의 커밋들은 기본적으로 깃 레퍼짓토리에 (전체 저장소) 합쳐져 있기 때문에 그 들이 너의 커밋을 승낙하고 너의 커밋들이 합쳐진다면 무엇이 바뀔지 누구나 알 수 있게 되어있다.

너가 코드를 반드시 작성하지 않더라도 그냥 아이디어 혹은 스크린샷을 공유 하고 싶을 때, 아무때나 Pull Request를 할 수 있다. 너가 도움이나 조언이 필요할 때, 혹은 다른 사람이 너의 작업물을 리뷰할 준비가 되었을 때 너는 pull request를 할 수 있다. Pull Request안에 있는 깃허브의 mention 시스템을 통해서 (@mention), 특정 사람 혹은 팀들에게 피드백 요청을 할 수 있다.

Pull Request는 오픈소스나 공유된 레퍼짓토리를 관리하는데 있어서 유용하다. Fork & Pull 모델을 이용해서Maintainer (레퍼짓토리를 담당하는 사람) 에게 너가 그들이 바꾸길 고려했으면 하는 것들을 알릴 수 있다. Shared 레퍼짓토리 모델을 사용하면 Pull Request를 통해서 커밋들이 메인 브랜치에 합쳐지기 전에 제안된 변화에 대한 리뷰, 대화를 시작할 수 있다.

4. 코드 리뷰 상의하기 (Discuss and review your code)

Pull Request가 한번 실행되면 팀원들은 너의 커밋에 대한 궁금증이나 의견이 있을 수 있다. 코딩스타일이 프로젝트 가이드라인에 맞지 않는다던가 테스트가 더 필요하다던가 칭찬을 한다던가 여러 의견이 있을 수 있다. Pull Request는 이러한 타입의 대화를 쉽게 해준다.

또한, 너의 의견 이나 피드백을 받고 브런치를 계속해서 수정할 수 있다. 버그가 있다던가 해야할 일이 빠졌다던가 너는 그런 피드백을 받고 수정을 할 수 있다. Github은 너에게 어떤 커밋이나 추가적으로 오는 피드백들을 Pull Request View를 통해서 보여준다.

(Pull Request는 Mark Down으로 쓰여있다. 그래서 이미지나, 이모지, 다른 설정된 포맷을 가져와서 사용 할 수 있다. )

5. 공개 하기 (Deploy)

Gibhub에서는 메인에 합치기 전에 브랜치에서 코드를 공개 및 테스트 할 수 있다.

Pull Request가 상의가 다 되고 너의 브랜치가 테스트를 통과하면 너의 변화된 것을 상품으로써 확실시 하기 위해 (테스트버전으로) 공개할 수 있다. 만약 브랜치에 문제가 있으면 원래 기존의 main 브랜치를 deploy 해서 너가 공개한 브랜치를 roll back 할 수 있다.

이 공개에는 여러 팀에 따라 다양한 전략이 존재할 수 있다. 예를 들어서, 제약된 테스트 환경속에서 공개하는게 최선일 수도 있고 혹은 상품 자체에 직접 공개하는 것이 최선의 전략일 수도 있다.