git flow란

1. git에서 사용되는 branch를 효율적으로 활용한 사례
2. git에서 사용되는 branch를 효율적으로 사용하게 해주는 program

위 2개를 git flow라고 지칭할 수 있습니다. 저 같은 경우 1번의 경우로 실습을 진행하려하며 그 이유는 program의 경우 1번의 flow를 간단한 명령어로 간단하게 사용할 수 있게 해주는 것이므로 전체적인 흐름을 알기 위해 1번의 경우로 직접 git의 명령어를 활용하여 branch를 만들고 merge하고 삭제할 예정입니다. 또한 기본적인 git의 흐름을 알고 계신다는 가정하에 진행하겠습니다.

git flow 실습

1. git hub repository 생성

   

   git hub에서 자신의 repository를 생성하겠습니다.

2. git hub에 연결될 local 폴더 생성

   

   저는 위 위치에 폴더를 만들어 git init을 한뒤 repository에 remote/push를 해주겠습니다.

   

   저는 기본적인 README.md 파일과 각 커밋의 내용을 확인할 수 있도록 work.txt 파일을 만들어 해당 파일내에서 git의 흐름에 따라 정상적으로 작동하는지 확인해보겠습니다.

3. git flow의 main branch 생성 (master, develop)

   git hub의 커맨드를 그대로 사용하셨던 분들은 master 대신 main이 생성되어 있을텐데요 main을 master 대신 사용하셔도 되고 다시 master로 변경하셔도 됩니다. 우리는 develop branch를 생성해야하며 이또한 develop naming 대신 development , dev 등 사용하싶은 naming으로 하시면 됩니다. 저는 기본 naming을 따라 가겠습니다.

   

   git checkout -b develop

   -b : checkout시 branch를 생성한 뒤 해당 branch로 바로 switch 한다.
   명령어를 통해 develop을 생성해주시고

   

   git push --set-upstream origin develop

   명령어를 통해 저장소에도 develop branch를 추가해줍니다.

   

   develop branch를 확인이 된다면 우린 main branch를 모두 생성했습니다!

   그리고 develop branch에서 실제로 개발을 하지 않겠지만 commit을 남겨놓기 위해 저는 파일의 내용을 변경하여 commit하였습니다.

4. version 관리를 위한 tag

   version의 관리를 위한 tag를 만들어주고 tag를 통해 version을 백업해둘 수 있습니다.

   

   아무 branch에서 tag를 생성해도 상관은 없지만 해당 branch의 내용이 그대로 tag로 관리되기 때문에 최대한 master에서 tag를 관리해주는게 좋겠죠? master가 항상 서비스되고 있는 branch니까요!

   git tag <태그명>
   으로 tag를 생성하고

   git push origin <태그명>
   으로 tag를 repository에 적용할 수 있습니다.

   git tag -d <태그명>
   으로 tag를 삭제하고

   git push origin :<태그명>
   으로 repository의 tag를 삭제할 수 있습니다.

   

   다음과 같이 tag가 생성된걸 확인할 수 있고 태그 네임을 누르시면 branch 이동처럼 해당 코드를 확인할 수도 있습니다!

5. 보조 branch 활용 (feature, release, hotfixes)

   이제 개발을 위한 준비가 모두 끝났습니다. 이제 우리는 git flow에 branch 활용 방법에 따라서 개발을 진행하면 됩니다!

6. feature

   feature는 기능 개발을 위한 보조 branch입니다. 기능 개발이란 개념이 사람마다 작업의 단위가 될수도 있고 하나의 기능이 될수도 있으니 편하신대로 이해하시면 될거 같습니다. 저는 feature/short branch와 feature/long branch를 생성했는데. short는 단기간에 종료될 작업을 의미하고 long은 오래걸릴 작업을 의미합니다.

   

   git checkout -b 명령어를 통해 두개의 branch를 develop에서 따옵니다. 그 후 short branch에 feature-short.txt 파일을 만들고 commit하겠습니다. 그리고 long branch에서도 feature-long.txt 파일을 만들어 commit하고요!

   

   파일들을 생성한 뒤 다시 develop으로 checkout 합니다.

   지금의 작업을 업무로 이해하자면 회의/상사의 명령?을 통해 자신의 업무가 배정되었고 해당 기능을 개발하기 위한 작업을 시작하기 위해 feature/<작업 name> (작업 name의 경우 회사에서 정해진 naming 규칙이나 자신만의 naming 규칙에 따라 작성하시면 됩니다.) branch를 생성했고 branch 내에서 작업을 끝낸 뒤 commit하여 서버로 push 한 상황입니다.

   혼자 작업하는 프로젝트라면 여기서 바로 merge를 해도 되겠지만 저는 개인 작업이 아닌 여러 인원과 프로젝트를 진행한다는 가정하에 pull requests를 생성해보겠습니다. (git hub일 경우)

   

   이렇게 short branch를 push 해주시고

   

   git에 들어가면 친절하게 compare후 pull request를 생성하라고 합니다.

   그럼 저 버튼을 눌러 우리는 맛깔나는 commit을 또 적어줘야겠죠 하지만 지금은 아무런 기능이 없으므로 스킵

   단 주의하실 점은 master <- feature/short 으로 pull request하시면 안돼고! develop으로 pr 하셔야합니다! 꼭 주의해주세요.

   

   pull request를 완료하면 저렇게 코드에 대한 리뷰도 받고 리뷰를 참고하여 수정할 부분이 있다면 수정한 뒤에 최종적으로 develop으로 merge가되겠죠.

   

   최종 merge가 된후 git에서는 자동으로 branch를 삭제시키겠냐고 물어봅니다. 여기서 바로 삭제시켜줍니다.

   

   그럼 이제 우리는 정상적으로 merge된 코드와 feature/short branch가 삭제되어진걸 확인할 수 있습니다. 결론적으로 develop에 우리가 하나의 기능을 추가하게 된거죠!

   이제 우린 github에 정상적으로 반영이 되었으니 local도 동일하게 작업해줘야겠죠

   

   git pull origin develop을 통해 develop branch 수정된 내용을 pull 하고 정상적으로 merge된건지 commit을 조회해보겠습니다.

   

   git log 명령어를 통해 commit을 확인할 수 있는데 commit에 보시면 feature/short branch의 pull request를 merge했다는 commit이 보이시죠? git hub가 이렇게 똑똑하게 어떤 branch가 merge되었는지까지 commit으로 남겨줍니다. 이 또한 git flow의 방침이기도 한데요. 그래서 만약 git command로 merge를 한다면 꼭 옵션으로 --no--ff를 입력해주셔야합니다. 여기서 --no--ff란 merge의 기본 방침은 ff > fast forward로 저렇게 merge가 된다면 merge commit이 남지 않고 commit들만 합쳐서 마치 develop에서 작업한것처럼 commit이 남습니다. 하지만 --no-ff는 fast forward를 하지 않겠다는 옵션이고 fast-forward가 아니므로 merge commit이 남게되어 다른 branch에서 작업한 것임을 알수 있습니다.

   

   그리고 마지막으로 git의 branch를 삭제했으니 local branch도 같이 삭제해줍니다.

7. release

   release는 개발된 기능을 develop에 merge한 뒤 기능들을 모두 모아 master = service에 적용하기 전 테스트 단계를 진행하기 위한 branch 입니다. 여기서는 test가 진행되며 test에서 발견되는 bug들을 fix하는 과정의 commit들이 만들어지게 됩니다. 우리는 회사에서 실제 서비스를 시작하기 위한 기능들을 모두 개발했다 생각하고 release 1.0 버전으로 branch를 만들어보겠습니다.

   

   이제 release branch에서 test가 진행되며 test에서 feature-short.txt 파일에서 bug를 발견했습니다. 그리고 우리는 그 bug를 수정했고요.

   

   내용은 신경쓰지 마세요! 제가 테스트해보느라 ㅎㅎ... 마지막줄의 -bug fix가 우리가 버그를 수정했다는 코드입니다. 우리는 이 release branch에서 계속해서 test를 진행하고 위와같이 계속해서 bug를 수정해갑니다. 그리고 이제 실제 service에 코드를 반영할 수 있게 될정도로 test도 많이 진행했고 code를 반영해야할 때가 왔습니다.

   그러므로 우리는 develop으로 branch를 checkout을 한뒤 release를 merge해주고 master에서도 merge를 해줍니다. 여기서 merge를 하시는건 위의 방법대로 github를 통해 진행하셔도 되고 git command로만 진행하셔도 됩니다! 둘다 이해하신 분들은요!

   그리고 우리는 master에 반영하게되었으므로 버전 1.0을 출시하게되었습니다! 축하드려요!!! 버전이 올라갔으니 tag도 달아줘야겠네요. 그리고 마지막으로 release branch를 삭제해주시고요!

8. hotfixes

   실제로 우리가 반영한 service가 실행되어지다가 test때 발견하지 못한 bug가 발생했습니다. 이럴땐 hotfixes branch를 사용하여 수정을 해줘야하는데요. hotfix branch는 develop에서 따오는 branch가 아닌 master에서 따오게됩니다.

   

   이제 전체적인 흐름을 이해하실거라 생각하기에 명령어만 적어봤습니다. 이렇게 hotfix를 맞친 뒤 master에 바로 적용하여 bug를 fix하고 가장 중요한점은 master에 반영하는것과 develop branch에도 반영하는 것이 가장 중요합니다! 그리고 또한 소스가 변경되어 버전이 달라졌으므로 1.1버전으로 변경해주셔야겠죠? tag도 달아야겠네요...ㅎ

   

   이렇게 master에 hotfix를 모두 적용하고 develop에도 똑같이 적용시켜주면 됩니다. 근데 저는 실수로 branch를 삭제해버렸어요... 저처럼 이런 분들 제발 없으시길 바랄게요...

   꼭 master와 develop 모두 적용후에 release branch를 삭제해주시야 합니다ㅜㅜ

   그리고 현재 아직 작업중인 feature/long은 작업을 완료한 뒤에 적용시켜주시면 되는 branch구요!

지금까지 git flow에 대해 알아봤는데요! git flow를 최초로 제안한

Vincent Driessen의 git flow 관련 문서

위 글을 읽어보시면 git flow 자체가 2010년에 최초로 구상한 flow이며 10년 전 모델이기때문에 지금의 프로젝트와 맞지 않을 수도 있다. 무조건 적으로 flow를 따를 필요는 없다. 라고 말하고 있어요. 그렇기 때문에 굳이 flow를 무조건적으로 따르지 않더라도 자신이나 팀에서 더 효율적인 flow가 있다면 git flow를 참고하여 수정된 flow를 따라 프로젝트를 관리하는 것도 좋을것 같습니다! 그 예로 git flow말고도 gitlab flow, github flow 등 더 간단한 flow들도 공부해보시는 것도 좋구요! 읽어주셔서 감사합니다!