git flow 란

• git flow 는 git branch 관리 전략입니다. 쉽게 말해 깃을 활용하여 프로젝트를 진행할 때 각자 기능 별로 브랜치를 파서 개발을 진행하고, 이를 다른 브랜치와 합치면서 프로젝트를 관리하는 방식입니다. git flow 의 사용하는 이유는 다음과 같습니다.

  1. 독립적인 개발 환경

  • 각자 기능 단위로 브랜치를 파서 개발을 진행하기 때문에 다른 사람의 개발 결과에 영향을 받지 않고 개발을 진행할 수 있습니다.

  2. 쉬운 코드 추적

  • 깃에 저장된 히스토리를 통해 어떤 기능이 어디에 통합되었는지를 확인할 수 있으므로, 오류 발생 시 코드 추적이 쉬워집니다.

  3. ci/cd 사용이 쉬워짐

  • 브랜치 별로 역할이 분리되어있기 때문에 각 브랜치의 업데이트에 맞춰 배포 & 테스트를 하기에 용이합니다. 저도 이 부분은 진행해 본 적이 없어서 이번 프로젝트에서 테스트 해 볼 예정입니다.

사전 준비

• git bash 설치
• 깃 플로우는 깃 명령어에 대한 약간의 사전 지식이 필요합니다.
  • status
  • add
  • commit
  • push
  • pull
  • branch 에 대한 간단한 이해(생성, 삭제, 브랜치 간의 이동)
  • 로컬 브랜치 vs 리모트 브랜치
• 그리고 구글에 git flow 를 검색해서 master, develop, feature 브랜치는 무엇이고 어떤 용도로 사용되는지 정도만 빠르게 이해하고 이 후 직접 테스트해가며 익혀 보는 것을 추천합니다.

- master : 메인 브랜치 -> deploy용 -> 실제 프로젝트 배포 시 사용

- develop : 실제 base branch. 새로운 기능 구현을 할 경우 해당 브랜치에서 feature 브랜치를 파생할 것

- feature/[구현할 기능] : 기능을 개발할 branch. 기능 구현 후 바로 develop에 머지하지 않고, pull request 를 develop으로 날려줄 것

실행 예시

<aside> 💡 예제를 실행하면서 가장 헷갈릴 것으로 예상되는 개념은 로컬 브랜치와 리모트 브랜치의 구별입니다(로컬에도 develop 브랜치가 있고 깃허브에도 develop 브랜치가 있고 이게 똑같은 건지 다른건지…). 로컬 브랜치는 내 컴퓨터에 있는 브랜치이고, 리모트 브랜치는 깃허브 상에 존재하는 브랜치입니다. 둘은 엄연히 다르지만 사실 깃 플로우를 진행함에 있어서 일단은 크게 신경쓰지 않아도 됩니다. 우선은 그냥 위에 언급한 두 develop 은 같은 브랜치다.. 라고 가볍게 이해하고 넘어가도 무방합니다.

</aside>

<aside> 💡 해당 진행 과정에서는 병합 충돌(merge conflict)이 나는 경우는 다루지 않았습니다.

</aside>

1. 맨 처음 깃허브에서 레포지토리를 생성하면 master 브랜치에 프로젝트가 세팅됩니다.

   

   

2. 최초에 팀원 중 누군가가 master 브랜치에서 뻗어나온 develop 브랜치를 생성해놓을 겁니다. 브랜치는 항상 어떤 브랜치에서 다른 브랜치가 파생되어 생성된다는 개념이며 마치 나무의 줄기에서 여러 가지들이 뻗어나가는 것과 같은 느낌입니다. 여기서는 직접 깃허브에서 develop 브랜치를 생성해주세요. 그리고 클론 받아 작업을 진행하면 됩니다.

   

   

3. 저에게 readme 파일을 수정하라는 작업이 주어졌습니다. 이제 로컬에서 해당 기능에 대한 브랜치를 파서 readme 파일을 수정하고 이를 develop 브랜치에 합치는 과정을 진행할 겁니다.

4. 먼저 develop 브랜치에서 새로 작업할 브랜치를 팝니다. 이름은 보통 feature/진행할기능이름 으로 짓습니다. 아래 명령어를 실행하면 develop 브랜치에서 feature/update-readme 브랜치가 파생되어 생성되고 이 브랜치로 이동까지 마치게 됩니다.

   

   // 현재 브랜치에서 새로 브랜치를 생성하고 새로운 브랜치로 이동하는 명령어 
   git checkout -b '브랜치명'
   

   

5. 이제 작업을 진행하면 됩니다. readme 파일을 직접 수정한 뒤 변화를 확인해보겠습니다. status 명령어를 통해 파일의 변화를 확인할 수 있습니다.

   

6. 작업이 끝나면 커밋 후 깃허브에 해당 브랜치를 올려봅니다.

   

   git add .
   git commit -m "commit messages"
   git push origin 'new_branch'
   

7. 정상적으로 푸쉬가 됐다면 레포지토리의 Pull requests 탭의 화면 상에 다음과 같은 화면이 뜰겁니다. 그러면 Compare & pull request 버튼을 눌러봅니다.