이번시간에는 git flow 를 실습해보겠습니다.
먼저 github 에서 gitflow 라는 새로운 repository 를 만들어줍니다. 그리고 https 주소를 복사해줍니다.
이후 git 에서도 gitflow 라는 디렉토리를 만들고 저장소로 만들어 줍시다. 그리고 git remote add origin https주소 를 통해서 로컬 저장소와 원격 저장소를 연결해줍니다.
이후 f1.txt 파일을 만들고 add 와 commit 를 해줍니다.
이전에 설명했던 것처럼 master 는 사용자에게 배포하는 버전들만 존재하고 실제 개발이나 구현은 develop 라는 branch 에서 주로 이루어집니다.
그리고 develop 라는 새로운 branch 를 만들어 줍니다.
git log --decorate --graph --all --oneline 을 통해 현재 상태를 확인 할 수 있습니다.
다시한번 f1.txt 를 수정해서 commit 을 해주었습니다.
여기까지 작업하다가 만약에 어떤 기능을 추가하는 새로운 업무가 생겼다고 하면 develop 에서 다른 branch 로 따로 수정을 하는것과 같습니다.
하나만 새로운 기능을 추가하는 과정을 알아보겠습니다.
feature-some 이라는 새로운 branch 를 만들어 주었습니다. 위 그림처럼 develop 에서 개발을 하다가 새로운 기능을 추가하기 위하여 다른 분기점이 생긴것이죠.
feature-some 에서 f1.txt 를 수정하고 commit 을 했습니다.
즉 현재 빨간원으로 표시한것과같은 상황이죠.
그 상태로 쭉 개발을 하다가 어느정도 마무리 되면 develop 에 병합을 합니다.
이를 위해서 develop 로 이동한 후애 git merge featuer-some 을 합시다.
이제 featuer-some 과 develop 가 같은 상태이기 때문에 더이상 쓸 일이없다면
git branch -d feature-some 을 통해서 feature-some 을 삭제하셔도 됩니다.
현재 여기까지 온 상태입니다.
만약 이제 개발한 내용을 사용자에게 배포해야할 때라면 release 라는 branch 를 사용할 때입니다.
release-1.0 을 만들어 주고 f1.txt 를 수정해서 파일의 코드를 바꿨다고 가정하고 commit 을 해주었습니다.
현재 여기까지 왔습니다.
그렇게 해서 release 를 위한 준비가 모두 끝나면 이제 release 의 현재 버전을 master 와 develop 에 모두 merge 를 해줍니다.
master 로 checkout 해주고 release-1.0 을 병합해줍니다.
이후 git tag -a 1.0 -m "first release" master 를 통해 새로운 tag 를 만들어 줍니다.
git log --decorate --graph --all --onelie 을 통해서 현재 상태를 확인 할 수 있습니다.
그리고 develop 로 이동해주고 git merge release-1.0 을 해줍시다.
따라서 현재 상태는 빨간색 동그라미와 같으며 tag 를 만들었으므로 다른사람에게 자신이 만든 버전을 공유할 수 있는 상태에 도달했습니다.
이때 만약에 긴급하게 수정해야하는 경우가 생길 수 있습니다. 이를 위해 hotfix 라는 branch 를 만들어 봅시다.
hotfix-some 이라는 branch 를 만들어 주었습니다 - 뒤에는 어떤것에 대한 수정인지 넣어주면 좋습니다. 이후 f1.txt 를 수정하고 commit 을 했습니다.
그리고 수정했으므로 master 로 이동하고 병합을 해줍니다.
master 에서는 배포를 하는 branch 이기 때문에 수정해서 병합한 내용을 git tag -a 1.1 -m "hotfix som" master 를 통해서 새로운 태그를 만들어 줍니다.
그리고 당연히 hotfix 에서 수정한 내용은 develop 에서도 추가가 되어야합니다.
한번 해봅시다.
따라서 develop 로 이동하고 merge 를 하였습니다.
즉 현재 상태는 위 그림에서 빨간동그라미와 같습니다.
이제부터 github 에서 언제 pull 과 push 를 할지 알아봅시다.
먼저 새로운 branch 를 만들기 직전에 pull 을 해서 다른사람이 develop 에서 변경한 것이 없는지 직전에 확인해줍니다.
그리고 feature 에서 작업을 하고 develop 로 merge 를 해버리면 나중에 feature 의 내용이 필요없을때 develop 에서 제거하는것이 복잡하기 때문에 feature 는 독립적으로 히스토리를 만드는것이 좋습니다.
이 과정에서 feature 에 있는 내용과 develop 에 있는 내용이 같은 곳이 수정되고 있었다면 나중에 병합했을때 심각한 문제가 생길 수 있습니다.
그렇게 때문에 그러한 확률을 낮추기 위해 develop 에서 변경된 사항을 계속해서 feature 로 가져와서 feature 은 develop 의 내용을 가지고 있고 develop 는 feature 의 내용을 가지고 있지 않다가 feature 의 수정이 끝나면 그때 develop 로 이동해 feature 를 병합을 하면 됩니다.
또한 release 에서 수정한 내용도 develop 에서도 바로바로 병합을 해서 다른 개발자들이 나중에 충돌이 크게 발생하는 확률을 낮추는게 좋습니다.
hotfix 도 마찬가지로 수정한 후에 바로 develop 와 master 로 병합을 한 후에 push 해서 다른사람이 동기화 할 수 있도록 해줍니다.
master 는 최종적으로 사용자에게 배포하기 위한 저장소 이기 때문에 권한을 가지고 있는 사람만이 엄격하게 통제하는 것이 협업 맥락에서 사고를 줄일 수 있는 방법중 하나입니다.
지금까지 git flow 에 대해 알아보고 실습을 통해 그 과정을 확인해보았습니다.
여기까지 하도록 하겠습니다.
