Git Flow

git flow 는 git의 어떠한 기능이 아니라 조직적으로 개발함에 있어 하나의 방법론 정도로 이해하면 될 것 같다. 기본적인 틀이 정해져 있지만 각 회사나 조직에 따라 그 방법을 변형하여 유연하게 사용하면 될 것이다.

Git Flow Branch

git flow 는 총 5개의 브랜치를 사용한다. 항상 유지되는 (master/main, develop)브랜치, 일정기간 유지되는 (feature, release, hotfix)

• master / main : 제품을 출시할 수 있는 브랜치
• develop : 다음 출시 버전을 개발하는 브랜치
• feature : 각 기능별 작업을 하는 브랜치
• release : 이번 출시 버전을 준비하는 브랜치
• hotfix : 출시 버전에서 발생한 버그를 수정하는 브랜치

vincent driessen 블로그 참조

git flow를 가장 잘 나타내는 사진이다.

1. master/main 브랜치에서 프로젝트를 시작
2. 동일한 내용으로 develop 브랜치를 생성, 개발자는 develop브랜치에서 개발 진행
3. 공동 개발을 진행하다. 기능 구현이 필요하면 기능을 맡은 개발자 별로 feature브랜치를 생성하여 개발 진행
4. 기능 구현이 완료된 feature 브랜치는 검토를 거쳐 develop브랜치로 merge
5. 모든 기능이 완료되면 develop 브랜치를 release 브랜치로 변경 이후 품질검사와 보완 디버그를 수행
6. 모든 것이 완료되면 release브랜치를 master와 develop브랜치로 이동시킴
7. master 브랜치에서 버전추가를 위해 태그를 생성하고 배포
8. 배포 후 발견하지 못한 버그는 hotfix브랜치에서 긴급 수정 후 태그를 생성하여 바로 수정 배포

fork / pull request

위 사진 속 단계를 순서대로 나열해보았다. 이것은 절대적으로 지켜하는 룰이 아니라 일반적인 개발 flow를 나타내는 것이고 각 조직에 맞게 변경 보완하여 git flow를 진행하면 될 것이다.

대규모 개발을 할 경우 Git Flow 방식 보다는 fork 와 pull request 방식으로 개발을 진행하는 경우도 많습니다.

fork 란 프로젝트를 진행 중인 git repository를 그대로 복제하는 개념입니다. 그대로 복제하여 자신의 repository로 가져와 맡은 기능들을 개발하고 중앙으로 pull request 날려 프로젝트 관리자의 검토 후 merge하는 형식으로 개발할 수도 있습니다.

---

Git rebase

기존에 알던 git init, add ., commit, push 등등 만 알아도 개발하는데 지장이 없어서 끝난 줄 알았다.. 하지만 git은 더욱 편리하고 많은 기능을 제공한다.. 그 중 rebase의 개념을 알아보자. 우리는 프로젝트를 시작하고 각각 맡은 기능을 feature 브랜치에서 작업하고 저장하고 싶은 지점에서 현재 상황에 대해 요약하는 commit을 날린다.
그렇게 되면 조금만 개발 규모가 커져도 엄청난 수의 commit내용이 정신없이 쌓이게 된다.

그렇기 때문에 commit내용을 정리할 필요가 있다.

실습을 한번 해보자. remote된 repository에 연습용 commit을 여러개 날려보자..

해오던 대로 git add. -> git commit -> git push 의 과정을 거쳐 github에 올려보자.

위 사진과 같이 기능 구현 중 올린 커밋 내용이 쭉 나타난다.

이후 rebase를 사용해보자.

git rebase -i main feature/movie
git rebase 메인브랜치 + 합치고 싶은 브랜치
# main 브랜치에서 rebase하는 경우
git rebase -i main

그러면 다음과 같은 화면이 나온다.

첫번째 pick을 제외하고 나머지는 전부 s로 바꿔준다. s는 squash한다는 것이다. 여러개의 커밋로그를 하나로 묶는다는 의미이다.

vi에디터에서는 i(insert)를 누르면 편집이 가능하다.

이렇게 바꿔준 후 esc를 눌러 편집모드를 빠져나온 뒤 : 콜론을 하고 wq 저장 종료를 하고 빠져나온다.

빠져나오면 다음 화면이 나오는데 # 주석처리 된 부분은 다 지워도 된다. (선택사항) :)

정리하고 싶은 커밋내역대로 작성해주면 된다.

나는 이렇게 정리했다. 한개에 기능단위 브랜치에서 여러개의 커밋 대신 큰 주제 밑에 여러개의 커밋내용을 깔끔하게 정리하면 되겠다.

git push origin feature/movie

push 해주면 된다. 하지만 이미 PR 내역이 있다면 다음과 같은 에러가 뜰 것이다.

그렇다면 강제로 푸쉬하는 명령어를 사용해보자.

git push origin feature/movie -f

그럼 다음 사진과 같이 커밋내역이 깔금하게 관리된 모습을 볼 수 있다.

만약 이 과정에서 conflict가 발생한다면 수정 후

git add .
git rebase --continue

의 과정을 진행하며 터미널에 나와있는대로 하나씩 수정하면 되겠다.