GitHub Flow란?

소개

이 기사는 Git의 취급에 익숙하지 않은 분을 향한 기사입니다.
그리고 나의 비망록으로도 되어 있으므로 아무쪼록 따뜻한 눈으로. . .

이 기사를 쓰는 경위

최근에는 github에 관한 기사를 많이 쓰고 있습니다 신졸 엔지니어입니다.
지난번 'git fetch'를 몰랐음을 말씀드렸습니다만 역시 아직 공부 부족이었던 것은 점점 발견됩니다.
요 전날, 제가 어사인 된 안건으로 「GitHub Flow나 GitLab Flow 알겠지요?」라고 PM분으로부터 질문되었습니다.

나 "미안해, 모르겠어..."

쓴웃음의 PM쪽. 학생 시절, 그리고 신졸의 연수로 무엇을 해 왔다고 생각되어도 어쩔 수 없습니다.
거기서 부끄러워하면서 이번 git 학습의 시간을 받고, 동시에 Git 운용의 워크플로우도 학습해 이해해 왔으므로 이번은 Github Flow의 설명과 고찰을 말해 가려고 생각합니다!

GitHub Flow란?

한마디로 표현한다면 "마스터에서 브런치를 자르고 각각 개발하여 마스터에 병합한다!"

네, 이것만. . .

이제 더 이상 말할 일이 없을 정도로 간단한 일이었지요. . . 웃음
그렇게 모른다고 하면 깜짝 놀리는 것도 무리는 없다. . .

보다 구체적으로 설명하겠습니다.



간단히 그림을 보았습니다. 마스터 브랜치에서 feature 브랜치가 2개 있는 경우의 워크플로우군요.

첫째, GitHub Flow의 경우 마스터 브랜치는 언제든지 최신으로 배포할 수 있어야 합니다. 이를 위해서는 마스터 브랜치에서 각각 개발 브랜치를 작성하고 구현을 마친 후에 master에 병합한다. 이 절차라면 master는 항상 배포 가능한 상태가 되네요!

고찰

언제나 하는 일이 GitHub Flow라고 말하는 것을 깨달았을 때는 조금 한심한 기분이 되었습니다. . . 웃음
그러나 몇번 봐도 이 브랜치라는 기능은 잘 생각된 것이라고 실감하게 됩니다.
저도 학생 시절로 돌아갈 수 있다면 코딩도 있지만 Git이거나 CircleCI 등 코딩 이외의 것을 학습하는 시간을 걸어두면 좋았다고 생각합니다.

아직도 신인인 것으로 이 기사에도 잘못이 있을지도 모릅니다만 거기는 용서 받을 수 있으면 다행입니다.
끝까지 읽어 주셔서 감사합니다! !