GitHub Workflow
workflow
일련의 작업 단계를 자동화하기 위한 프로세스로 소프트웨어 개발 및 배포에 필요한 모든 작업을 수행
업무 흐름을 더울 효율적으로 만들어주는 도구
특정 이벤트(ex. pull request 또는 push)가 발생할 때 실행되며, 이러한 이벤트는 GitHub repositiry에서 발생할 수 있음
ex. workflow는 소스 코드, 단위 테스트, 빌드, 배포 및 알림과 같은 작업을 자동화할 수 있음
장점 : 작업의 일관적인 수행, 반복적인 업무 수행 자동화로 시간과 비용 절감, 업무 처리 과정에서 발생할 수 있는 문제 사전 예방, 문제 발생 시 즉각적인 조치를 취할 수 있는 방법 제공
브랜치(branch)
버전 관리 시스템에서 코드를 분리하는 방법 중 하나
브랜치를 사용하면 다른 작업자들과 공유하고 있는 코드 베이스에서 독립적으로 작업을 수행할 수 있음. 이렇게 분리된 작업은 나중에 다시 원래 코드 베이스와 병합(merge)하여 하나의 완성된 코드로 만들 수 있음
git에서 브랜치 사용
git branch : 새로운 브랜치 생성
git checkout : 브랜치 간 전환
브랜치 전략(branching strategy)
여러 개발자들이 협업하여 소프트웨어를 개발할 때, 버전 관리 시스템에서 브랜치를 어떻게 사용할지에 대한 일련의 규칙과 가이드라인
브랜치 전략을 잘 정의하고 유지하면, 다수의 개발자들이 효율적이고 일관성 있는 방식으로 코드를 관리하고 출동을 최소화할 수 있음
브랜치 전략의 종류
● Mainline(Trunk) Development Strategy
- 모든 개발자들이 하나의 메인 브랜치에서 작업하는 전략
- 모든 변경 사항은 메인 브랜치에서 처리되며, 모든 개발자들은 메인 브랜치를 최신 상태로 유지하도록 노력함
● Feature Branch Strategy
- 새로운 기능을 개발할 때마다 새로운 브랜치를 생성하여 개발하는 전략
- 각각의 기능 브랜치에서 작업을 수행한 후, 완료되면 메인 브랜치에서 다시 병합
● Gitflow Strategy
- Mainline(Trunk) Development Strategy와 Feature Branch Strategy의 조합
- 메인 브랜비를 기반으로 'develop'브랜치를 생성하고, 모든 기능 개발은 'feature'브랜치에서 수행
- 완료된 기능은 'develop'에 병합되며, 메인 브랜치에는 안정 버전만 릴리스됨
Gitflow
Git을 이용한 효율적인 소프트웨어 개발에 대한 일종의 전략(strategy)
여러 개발자들이 소프트웨어를 개발할 때, 작업의 효율성을 높이고 충돌을 최소화할 수 있음.
팀 내에서 통일된 브랜치 관리 방식을 적용함으로써, 프로젝트의 관리 및 유지 보수 용이
크게 두 개의 메인 브랜치
● master : 제품으로 출시될 수 있는 브랜치로,언제든지 배포 가능한 상태만을 관리
● develop : 다음 출시 버전을 개발하는 브랜치로, master 브랜치로부터 시작되며, 기능 개발이 완료되면 master 브랜치에 병합
각각의 기능 개발 수행 feature
feature : 새로운 기능 개발을 위한 브랜치로, develop 브랜치로부터 시작되며, 기능 개발이 완료되면 develop 브랜치로 병합
배포를 위한 버그 수정 release
● release : 다음 출시 버전을 준비하는 브랜치로, develop 브랜치를 기반으로 하며, QA 및 버그 수정 등의 작업 수행. 이후에는 master 브랜치와 develop 브랜체에 병합
배포 이후 문제 발생하거나 버그 수정 hotfix
● hotfix : 긴급하게 수정이 필요한 경우, master 브랜치에서 분기하여 수정 작업을 수행하고, master 브랜치와 develop 브랜치에 병합
GitHub Workflow
소프트웨어 개발 및 배포를 자동화하는 데 사용되는 GitHub Actions의 일부 작업 그룹
YAML 파일로 정의되며, 이 파일에는 workflow가 실행될 이벤트 및 수행할 작업과 단계가 포함
workflow는 GitHub Actions에서 실행되므로, 사용자는 GitHub Marketplace에서 작업을 검색하고 자신의 workflow에서 사용 가능
GitHub에서 권장하는 간단한 협업 워크플로우로 지속적인 배포, 테스트 및 코드 리뷰에 중점.
작은 규모의 프로젝트나 지속적인 배포를 필요로 하는 프로젝트에 적합.
팀의 개발자들이 지속적인 통합과 배포를 수행할 수 있도록 지원하며, Pull Request를 통해 토드 변경 사항에 대한 코드 리뷰 및 승인 과정을 간편하게 수행 가능.
GitHub WorkFlow 주요 단계
1. 브랜치 생성 : 개발자는 작업을 위해 새로운 브랜치를 메인 브랜치(ex. master, main, develop)에서 생성
2. 코드 변경 : 개발자는 새로운 브랜치에서 코드를 변경하고, 커밋(commit)하여 변경 사항을 저장
3. Pull Request (PR) : 개발자는 변경 사항을 브랜치(ex. master)로 병합하고 싶다는 의사를 나타내는 Pull Request를 생성
4. 코드 리뷰 : 코드 리뷰어(일반적으로 다른 다른 개발자나 팀 리더 등)은 Pull Request에서 변경 사항을 검토하고, 수정이 필요한 경우 댓글(Comment)를 남기거나 코드에 직접 변경을 가할 수 있음
5. 병합 : Pull Request가 승인되면, 변경 사항이 원본 브랜치에 병합(Merge)
6. 배포 : 병합된 코드는 CI/CD 파이프라인을 통해 자동으로 테스트 및 배포