개발을 처음 접했을 때 개인적으로 꽤 생소했던 개념이 바로 깃(Git) 혹은 깃허브(GitHub)였다.
여러 개발자들이 꼭 알아야 하는 중요한 개념이라고 강조를 하곤 했는데, 이제는 꽤 익숙해졌다고도 생각하는 시점에서 정리를 해보려 한다.
더 자세한 이론적인부분은 이곳에 잘 정리되어있습니다.
https://git-scm.com/book/ko/v2
Git
깃(Git)은 리눅스의 창시자인 리누스 토르발스(Linus Torvalds)가 개발한 소스 코드 관리 시스템이다.
깃은 다음과 같은 대표적인 기능을 가지고 있다.
버전 관리
이력서나 과제등을 작업하다보면, 최종이라고 저장한것이 이후엔 진짜최종이되고, 최최최종이되고..와 같은 상황은 다들 겪어보셨을것이라 생각된다.
깃을 이용하면 문서를 수정할 때마다 시기와 변경된 내용을 기록할 수 있고, 원하는 이전의 수정시점으로 돌아갈 수 있다.
백업 (BackUp)
일반적으로 컴퓨터에 존재하는 자료를 따로 보관 하기 위해선 USB나 외장하드, 혹은 클라우드 시스템을 이용 할 수 있다.
이처럼 깃을 위한 여러 온라인 저장소(클라우드)가 존재한다.
대표적으로 사용하는 서비스들은 GitHub, GitLab, Bitbucket이 있다.
협업
사실상 개발자가 깃을 배우는 가장 큰 이유이다. 깃을 이용하면 편리하게 여러 사람들과 업무를 같이 할 수 있다.
공동의 저장소에 작업물을 동료가 내려받아 이어서 작업 할 수 있으며, 언제 어떤 수정을했는지 모든 기록이 남기때문에 효율적인 협업이 가능하다.
Branch(브랜치)?
문득 예전에 영어공부를 할 때, Branch == 나뭇가지로 외우고있었는데, 왜 분점의 의미가 있는지 고민했던 기억이 났다. 나뭇가지처럼 한 갈래(원격 저장소)에서 이어진 것(브랜치)이라고 이해하니 편했다.
깃을 이용한 워크플로우
깃을 이용한 협업방법 중 널리 사용되는 2가지에 대해 알아보자.
Git-flow
Git-flow의 브랜치
- master : 배포서버에 제품으로 출시되는 브랜치.
- hotfix : master 브랜치에서 발생한 버그를 수정하는 브랜치.
- release : 다음 버전 출시를 준비하는 브랜치. develop 브랜치를 release 브랜치로 옮긴 후 QA, 테스트를 진행하고 master 브랜치로 합친다.
- develop : 다음 출시 버전을 대비하여 개발하는 브랜치.
- feature : 기능 개발 브랜치. develop 브랜치에 들어간다.
Git Flow의 구조 및 흐름
- 기본 구조 5개 중 가장 많이 사용되는 브랜치는 master와 develop이 되며 정상적인 프로젝트를 진행하기 위해서는 둘 모두를 운용해야 한다.
- 나머지 feature, release, hotfix branch는 사용하지 않는다면 지우더라도 오류가 발생하지 않기 때문에 깔끔한 프로젝트 진행을 원한다면 지워뒀다가 필요시 생성해도 문제가 없다.
- 대부분의 작업은 develop에서 취합한다 생각하면 되며 테스트를 통해 정말 확실하게 더 이상 변동사항이 없다 싶을 때 master로의 병합을 진행하게 된다.
- master가 아닌 브랜치들은 master의 변동사항을 꾸준히 주시해야 한다.
Github-flow
Git flow가 좋은 방식이지만 GitHub에 적용하기에는 복잡하다는 Scott Chacon의 판단에 따라 만들어진 새로운 깃 관리 방식이다.
자동화 개념이 들어가 있다라는 큰 특징이 존재하며 만일 자동화가 적용되어 있지 않은 곳에서만 수동으로 진행하면 된다.
Github-flow
- 기능 개발, 버그 픽스 등 어떤 이유로든 새로운 브랜치를 생성하는 것으로 Github-flow는 시작된다.
- 새로운 브랜치는 항상 master 브랜치에서 만든다
- 체계적인 분류 없이 브랜치 하나에 의존하게 되기 때문에 브랜치 이름을 통해 의도를 명확하게 드러내는 것이 매우 중요하다.
- master 브랜치는 항상 최신 상태며, stable 상태로 product에 배포되는 브랜치.
- 이 브랜치에 대해서는 엄격한 role과 함께 사용한다
Commit과 push
- 커밋메세지에 진행단계 파악을 의존하기 떄문에, 최대한 상세하게 적어줘야한다.
- 로컬 저장소에서 원격 저장소로 수시로 push 한다 (Git-flow와 상반되는 방식)
- 항상 원격지에 자신이 하고 있는 작업물을 올려 다른 사람들도 확인할 수 있도록 한다.
- 이는 하드웨어에 문제가 발생해 작업하던 부분이 없어지더라도, 원격지에 있는 소스를 받아서 작업할 수 있도록 해준다
PR (Pull Request)
- 피드백이나 도움이 필요할때 혹은 merge 준비가 되었을때는 pull request를 생성한다.
- 내 작업물을 동료와 공유하고 리뷰를 받으며 수정사항이 있다면 수정한다.
- Pull request가 끝난 후 merge가 된다면, 바로 배포 서버에 합쳐지는것이므로 상세한 토의와 검토가 필요하다.
테스트
- 리뷰가 끝났다면, 해당 작업물을 테스트 환경에 배포 해본다.
- 테스트에서 문제가 생긴다면 배포서버에 병합 되지 않도록 주의가 필요하다.
Merge
- 테스트환경에 문제가 없다면, 그대로 master 브랜치에 병합해 즉시 배포되도록 한다.
- 대부분의 Github-flow에선 master 브랜치에 배포 자동화도구를 이용해 merge 즉시 배포를 시킨다.
정리
추가로 Gitlab-flow 등 워크플로우는 다양하지만 말 그대로 work-flow, 즉 방법론이기 때문에 어느것이 좋고 나쁜것은 없다고 생각한다.
각자 팀의 상황에 맞게 적절한 워크플로우를 선택하여 생산성을 높이는 것이 중요할 것이다.
마지막으로 Github-flow에서 Git-flow로 변경한 우아한형제들의 블로그를 남깁니다.
https://techblog.woowahan.com/2553/