git workflow
git workflow란 git을 이용하여 버전관리를 하는 다양한 흐름의 방법을 말합니다. workflow에는 다양한 방법이 존재하지만, 현재까지 두가지 방법을 사용한 경험이 있습니다. git flow와 github flow 입니다.
github flow
첫 번째 사용한 flow는 gitgub flow입니다. gitgub flow는 git flow에 비해 단순한 flow로 진행되며, develop과 feature 브랜치가 서로 나누어지지 않고 각 기능이 하나의 브랜치로 작성되므로 main에 즉시 배포 되는 방식입니다. 이러한 방식으로 인해 main이 항상 최신화되어 있고 상시 배포되기 때문에 Pull Request을 통한 정확한 merge와 자세한 log 작성을 필요로 합니다.
git flow
아래의 그림은 git flow를 한 번이라도 검색했다면 볼 수 있는 그림입니다. 그만큼 git flow에 대해 정확한 설명을 하고 있다는 반증인 것 같습니다.
아직 많은 flow를 경험하지 못했지만, git-flow가 많은 기업에서 사용되고 있으면서 배포와 개발을 함께 적용할 수 있는 합리적인 방법인 것 같습니다. git flow에는 5가지 상태가 있습니다.
- master - 현재 배포중인 상품을 나타내는 브랜치. github flow의 main과 같다.
- hotfix - 현재 배포중인 상품의 버그를 개선하고 바로 적용시키는 브랜치
- develop - 배포중인 상품의 다음 기능을 구현하는 브랜치
- feature - develop 브랜치에 포함되는 기능을 만드는 브랜치
- release - develop을 완성 후 오류를 찾아 검증하는 브랜치(QA)
위와 같은 5개의 상태로 구성되어 있고, hotfix와 feature 브랜치는 작업이 끝나고 merge되면 삭제합니다.
master 브랜치에서 우리가 실제로 사용하는 상품을 배포하는 브랜치이고, 다음 버전을 준비하기 위해 develop 브랜치에서 작업을 합니다. develop의 각 기능은 feature 브랜치에서 작업하며 완성할 때마다 merge합니다. 최종 develop 브랜치가 완성되면 master 브랜치에 merge한 후, release 브랜치에서 develop 브랜치의 오류를 지속적인 QA과정을 통해 개선하고 다시 merge 합니다. 만약 배포중인 상품에서 작은 오류가 발생한다면 hotfix 브랜치에서 빠르게 수정 후 바로 master 브랜치로 적용합니다.
위와 같은 과정을 통해 배포, 개발, QA를 모두 동시에 작업하며 공간을 적절히 분리하는 git flow 방식이 가장 합리적인 방식이라고 생각합니다. 근 10년 동안 많은 사람들이 git flow 방식을 사용하면서 효율적인 방법이라고 생각하고 사용하고 있습니다. 그럼에도, 앞으로 기술이 발전하며 또 다른 방식이 생겨날 것이기 때문에 저 또한 개선할 점을 생각하고 준비해야 할 것입니다.
