우리는 개발을 진행하면서 우리가 구현한 소스코드를 git이라는 버전관리 시스템을 통해 관리한다.
git을 사용하지않았더라면 협업을 진행하며 메일이나 USB로 소스코드를 주고 받았을 것이다. git을 사용함으로써 우리는 시시각각 코드를 전송할 수 있다. 또한 일일히 병합하는 과정을 생략하고도 손쉽게 소스코드를 관리할 수 있다. 뿐만 아니라 꼼꼼한 commit 로그 과정을 통해 과거의 소스코드와도 한눈에 비교가 가능하다.
협업을 할 때에도 이 git을 사용해 분산 버전 관리를 할 수 있어 브랜치에 따라 독자적인 개발을 하고 메인 저장소에 merge하는 방식으로 체계적으로 개발을 진행할 수 있다.
이를 위해서는 대표적으로 사용하는 브랜치 전략인 Git flow, Github flow, Gitlab flow에 대해서 소개한다.
5가지 성격의 브랜치를 가지고 있다.
- feature
- develop
- release
- hotfix
- master
아래 그림은 이 git flow의 브랜치 전략을 드러내는 유명한 그림이다.
각각의 브랜치에 대해 간단히 살펴보면
feature 브랜치는 기능의 구현을 담당한다.
브랜치명은 팀마다 컨벤션을 가지고 지을 수 있지만 feature/{구현기능명}
과 같은 명칭을 준수하는 것이 일반적이다.
예를 들어, feature/login 은 login 기능을 구현하는 브랜치임을 알 수 있다.
feature 브랜치는 develop 브랜치에서 생성되며, develop 브랜치로 머지된다.
머지된 후에는 해당 브랜치가 삭제된다.
develop 브랜치는 말 그대로 개발을 진행하는 브랜치로 중심적인 브랜치이다.
하나의 feature 브랜치가 머지될 때마다 develop 브랜치에 해당 기능이 더해지며 살을 붙여간다.
develop 브랜치는 배포할 수준의 기능을 갖추면 release 브랜치로 머지된다.
release 브랜치는 개발된 내용을 배포하기 위해 준비하는 브랜치이다.
브랜치명은 release-1과 같은 방식으로 첫번째 릴리즈, 두번째 릴리즈 등을 지정하는 것이 보편적이다.
release 브랜치에서 충분한 테스트를 통해 버그를 검사하고 수정해 배포할 준비가 완전히 되었다고 판단되면
master로 머지해 배포한다.
release 브랜치는 develop 브랜치에서 생성되며 버그 수정 내용을 develop 브랜치에도 반영하고, 최종적으로
master 브랜치에 머지한다.
hotfix 브랜치는 배포된 소스에서 버그가 발생하면 생성되는 브랜치이다.
브랜치명은 hotfix-1로 지정된다. release 브랜치를 거쳐 한차례 버그 검사를 했지만 예상치 못하게 배포 후에 발견된 버그들에 대해서 수정한다.
hotfix 브랜치는 master 브랜치에서 생성되며, 수정이 완료되면 develop 브랜치, release 브랜치와 master 브랜치에 수정 사항을 반영한다.
master 브랜치는 최종적으로 배포되는 가장 중심의 브랜치이다.
develop 브랜치에서는 개발이 진행되는 와중에도 이전 release 브랜치 내용이 master에 있어 배포되어 있다.
github flow는 git flow의 브랜치 전략이 너무 복잡하고 적용하기 어렵다고 해서 생겨난 브랜치 전략이다.
github flow는 master 브랜치 하나만을 가지고 진행하는 방식이다.
master 브랜치는 어떤 기능이 구현되든, 오류가 수정되든 모두 master에 머지되어 항상 update된 상태를 유지한다.
아래 흐름은 github flow의 흐름을 보여주는 그림이다.
- mater브랜치에서 개발시작
- 기능구현이나 버그가 발생하면 issue 작성
- 팀원들이 issue해결을 위해 master브랜치에서 생성한
**feature/{구현기능}**브랜치에서 개발을 하고 commit log을 작성 - 누군가 push를 하면 서로 pull / request를 사용할 수 있게됨
- 이를 통해 팀원들간의 피드백, 버그 찾는 과정이 진행된다. release 브랜치가 없으므로 이 과정이 탄탄하게 진행되어야 한다.
- 모든 리뷰가 이루어지면, merge하기 전에 배포를 통해 최종 테스트를 진행한다.
- 테스트를 완료하면 master 브랜치에 merge.
github flow는 시시각각 master에 머지될 때마다 배포가 이루어지는 것이 좋다.
- CI/CD를 통한 배포 자동화를 적용하는 것이 좋다. 브랜치 전략이 단순해 master 브랜치에서 pull 하고, 기능 구현하고, 머지하는 일의 반복이다.
- 주의해야할 점 pull request에서 팀원간의 충분한 리뷰와 피드백이 진행되지 않으면 배포된 결과 자체에서 버그가 발생할 수 있다.
gitlab flow는 복잡하지 않고 효율을 높이고자 생겨난 브랜치 전략으로 master, feature, production 브랜치가
존재한다.
gitlab flow는 이슈트래킹을 연동해 프로세스를 단순화하고자 한다. merge request를 통해 승인이 되는 이슈만 머지하도록 하는 것이 핵심이다.
모든 기능 구현은 feature 브랜치에서 진행된다.
이 feature 브랜치는 master 브랜치에서 나와 master 브랜치로 머지된다.
기능 구현이 완료되면 merge request를 보낸다.
merge request에서 팀원 간의 협의가 완료되면 master 브랜치로 머지한다.
gitlab flow의 master 브랜치는 git flow의 develop 브랜치와 같다.
master 브랜치는 feature 브랜치에서 병합된 기능에 대해 test 한다.
전체적인 테스트가 진행되어 기능에 대한 보장이 되었다면 production 브랜치로 머지한다.
production 브랜치는 한 마디로 배포 브랜치이다. git flow의 master 브랜치와 같다.
안정된 소스코드가 되었을 때 production 브랜치에 병합해 배포하도록 한다.
하지만 여기서 견고한 test를 거치고 싶은 경우 pre-production 브랜치를 생성해 production에 병합하기 전에 test server에 배포해 확인할 수도 있다.
gitlab flow는 git flow처럼 복잡하지 않으면서, github flow처럼 너무 단순하지 않아 비교적 적용이 쉬우면서도 원활한 운영이 가능하다.
gitlab의 CEO가 서술한 최대한의 효울을 위해 지켜야 할 11가지 규칙
1. 메인 브랜치에서 직접 커밋하기 보다는 기능 브랜치를 사용하세요.
기능 분기를 사용하는 것은 소스 코드를 깔끔하게 개발하고 유지하는 간단한 방법 입니다.
예를 들어 팀이 최근 SVN에서 Git으로 전환한 경우 트렁크 기반 워크플로에 사용됩니다. 개발자는 병합하기 전에 코드 검토 프로세스를 쉽게 시작할 수 있도록 작업 중인 모든 항목에 대한 분기를 만들어야 합니다 .
2. 메인 브랜치의 커밋뿐만 아니라 모든 커밋을 테스트합니다.
분기에 병합된 항목만 테스트하도록 하는 것이 아니라 사용할 수 있는 커밋은 모두 테스트가 되어있어 신뢰성이 있어야합니다. 개발자가 새로운 기능 개발을 시작하기 전에 각 커밋을 테스트해야 하는 것은 비효율적이기 때문에 항상 테스트를 해둬야합니다.
3. 모든 커밋에 대해 모든 테스트를 실행합니다. (테스트가 5분 이상 실행되는 경우 병렬로 실행할 수 있습니다.)
브랜치 에서 작업하고 feature 새 커밋을 추가할 때 즉시 테스트를 실행하세요. 테스트에 시간이 오래 걸리면 병렬로 실행해 보십시오. 전체 테스트 모음을 실행하여 병합 요청에서 이 서버 측을 수행합니다. 개발용 테스트 제품군과 새 버전 전용 테스트 제품군이 있는 경우 [병렬] 테스트를 설정하고 모두 실행하는 것이 좋습니다.
4. 메인 브랜치에 병합하기 전에 코드 검토를 수행합니다.
일주일이나 프로젝트가 끝날 때 모든 것을 테스트하지 마십시오. 개발 후반에 문제를 일으킬 수 있는 문제를 식별할 가능성이 더 높기 때문에 코드 검토는 가능한 한 빨리 이루어져야 합니다. 문제를 더 일찍 발견할 수 있다면 더 쉽게 솔루션을 만들 수 있습니다.
5. 배포는 분기 또는 태그를 기반으로 자동으로 이루어집니다.
담당 개발자가 매번 배포하고 싶지 않다면 production 분기를 만들 수 있습니다. 스크립트를 사용하거나 수동으로 수행하는 대신 팀은 자동화를 사용하거나 프로덕션 배포 를 트리거하는 특정 분기를 가질 수 있습니다 .
6. 태그는 CI가 아닌 사용자가 설정합니다.
개발자는 tags CI가 레포지토리를 변경하도록 하는 대신 CI는 작업만 수행하도록 사용해야 합니다. 팀에 자세한 메트릭이 필요한 경우 새 버전에 대해 자세히 설명하는 서버 보고서가 있어야 합니다.
7. 릴리스는 태그를 기반으로 합니다.
각 태그는 새 릴리스를 생성해야 합니다. 이 방법은 깔끔하고 효율적인 개발 환경을 보장합니다.
8. 푸시된 커밋은 리베이스되지 않습니다.
공개 브랜치로 push할 때 개발자는 rebase하지 않아야 합니다. 그 이유는 체리 피킹(cherry picking) 중에 개선 및 테스트 결과를 식별하기 어렵기 때문입니다 . 때때로 이 팁은 코드 검토 프로세스가 끝날 때 누군가에게 더 쉽게 되돌릴 수 있도록 스쿼시 및 리베이스하도록 요청할 때 무시될 수 있습니다. 그러나 일반적으로 지침은 다음과 같습니다. 코드는 깨끗해야 하고 기록은 현실적이어야 합니다.
9. 모든 사람은 메인에서 시작하여 메인을 목표로 합니다.
이 팁은 긴 가지를 방지합니다. 개발자는 main에서 체크아웃하고, 기능을 구축하고, 병합 요청을 생성하고, main 으로 다시 대상을 지정합니다. 중간 단계를 병합하고 제거 하기 전에 완전한 검토를 수행해야 합니다 .
10. 먼저 메인의 버그를 수정하고 두 번째로 릴리스 분기를 수정합니다.
버그를 식별한 후 자주 문제가 발생되는 조치는 main에서 수정하지 않고 방금 릴리스된 버전에서 수정하는 것입니다 . 이를 피하려면 개발자는 항상 main 변경사항을 처리한다음, 다른 패치 릴리스 분기로 옮겨서 골라내야합니다.
11. 커밋 메시지는 의도를 반영합니다.
개발자는 자신이 무엇을 했는지 뿐만 아니라 왜 했는지도 말해야 합니다. 이 방법은 향후 후임자가 개발 프로세스를 이해하는 데 도움이 되도록 합니다. 다른 솔루션과 비교해 이 솔루션을 선택된 이유를 설명하는 것입니다. 설명 커밋 메시지를 작성하는 것은 코드 검토 및 향후 개발에 유용합니다.