형상관리, 버전관리시스템에 대해 알아보고 대표적인 Gitflow와 Github flow 의 장단점에 대해 설명합니다 여기서 나온 장단점을 토대로 팀 운영환경에 적합한 Git workflow 에 대해서 고민해봅니다

1. Git workflow

2. 시작하기 전에..
형상관리란?
[software configuration management]
task of tracking and controlling changes in the software
소프트웨어 변화를 기록해두고 추적할수 있는것.
문제가 생겼을때 어떤게 바뀌었는지, 누가 바꿨는지 알 수 있다
원초적인 형상관리..

3. 시작하기 전에..
버전관리시스템이란?
이전버전으로 특정 파일이나 전체 프로젝트를 revert,
버전별 변화과정을 compare, 누가 파일을 변경했는지 등..
뭔가 잘못되어도 쉽게 복구가능!
작업물의 변경버전을 관리해주는 시스템

4. 시작하기 전에..
SVN vs Git
Apache Subversion = SVN
중앙집중형 버전관리 시스템 (CVCS)
중앙서버가 각 파일의 변경내역을 관리
SVN
Git
분산 버전관리 시스템 (DVCS)
로컬서버마다 clone repo를 가지고 있다
파일의 변경이력이 아닌 스냅샷을 저장

5. 자.. 이제 Workflow를 다뤄봅시다

6. SVN 썼을때는 말이지..
Release Branch와 trunk 두개로 다 했음(가끔 dev 따고)
매주 R.B 따서 그주 배포나갈건 거기에 commit 하고
끝나면 다음주 R.B 따서 다음주것 commit 하고..
왜그랬을까?
중앙에서 브랜치 생성과 관리를 다 맡아서 하기때문에
브랜치를 이것저것 생성해서 관리하기에는 비용이 큼
(물론 장기간의 작업을 할때는 Dev 브랜치를 생성함)

7. Git workflow
Git은 local clone repository에서 대부분의 작업을 처리해 branch 생성과 작업이 수월함.
+ Open Source 에서 활발히 사용한만큼 Contributor 간의 협업방법을 고민하지 않았나..
= Gitflow, Github flow, Gitlab flow 등 다양한 git workflow가 등장

8. 아니 뭘 복잡하게.. Git도 Svn 쓰던대로 쓰면 되는것 아니오?
네 뭐.. 가능은 한데..
이번주 배포 말고 다음주 배포에 포함시킬 건들은 어떻게 하죠?
SVN처럼 하면 배포할때마다 R.B 따야하는데..
그러면 그동안의 작업은 어디다 commit 하죠?
hotfix건들이 있으면 어쩌죠?
master에 바로 commit? commit한 다음에는?
협업하다보면 여러가지 경우의 수가 생기는데.. 가이드가 필요하지 않을까요?!

9. Gitflow

10. Gitflow
Master
ready on production.
언제든 배포할수 있는 브랜치
Develop이 배포준비가 되면 master merge
Develop
Integration branch
다음 배포에 나갈 변경사항들이 merge된 브랜치
Merge feature들간의 통합테스트를 할 수 있음

11. Gitflow
Release Branch
Develop 브랜치에서 배포준비가 되면 생성되는 브랜치
Source Freezing 상태여야 함. 단 Bugfix등은 허용
Develop에서 생성되어 Develop, Master로 Merge 됨
Feature Branch
말그대로 신규 Feature를 개발하는 Branch
Develop에서 생성되어 Develop으로 merge됨
Next Branch로 사용되기도 한다

12. Gitflow
Hotfix Branch
장애 또는 크리티컬 버그 발생시
Master에서 생성해 작업후
Develop과 Master에 Merge

13. Gitflow 총평
장점
- 발생할 수 있는 경우의 수를 거의 다 포함하고 있음
즉, 발생할수 있는 웬만한 상황에 대한 설명서
작업이 서로 꼬이게 될 일은 잘 없음
- 나름 표준 git workflow라 개발자간 통용이 잘 됨
단점
- 배포주기가 짧으면 RB 따는게 별로 효용이 없음
(예를들면 매주 혹은 매일배포)
- 초반에는 사람들이 복잡하다고 생각해서 좀 어려워함

14. Github Flow
더 심플한 방법은 없나?
1. master에서 feature branch 생성
2. Feature branch에 commit
3. Pull Request
4. Master 배포
매우 간단함
* 최근버전 *
Feature 선배포후 이상없으면 Master Merge
Feature 배포후 이슈발생하면 Merge 안된 Master로 롤백

15. 꽤 신선한 컬쳐쇼크
Github Flow CI/CD 환경이 구축되어있어야 한다는 전제가 있어야함
여러개 feature가 같은날 배포해야하는 경우가 생기면?
Pull Request를 범용적으로 사용
완성된 기능만 merge전에 PR로 리뷰하는게 아니라
그냥 궁금한거 있으면 중간에 PR 날려서 Discussion
Master로 꼭 배포 안해도 되네?
Feature 먼저 배포후 이상없으면 Master로 merge
좋아요 좋은데..

16. 가이드가 탄탄한 Gitflow 의 골격을 따르면서
- 단, release branch는 생성하지 않음
Github flow 장점을 더한다
- develop 선배포후 테스트 완료되면 master merge
- PR을 빈번하게 잘 사용하자
Gitflow + Github flow