[Git] 팀프로젝트시 Git Branch 전략, 컨벤션, 히스토리 관리 rebase 방법

Git Branch 전략과 컨벤션을 정하고 팀 프로젝트를 진행했다.

 

[Git Branch 전략]

• 기능 개발을 진행할 때 develop 브랜치를 기준으로 feature 브랜치를 만들어서 기능개발을 완료 
• 기능 개발한 feature를 develop 브랜치에 Pull Request를 하고 코드리뷰를 진행한 후 develop 브랜치에 merge
• merge를 한사람씩 하여 업데이트된 develop 브랜치를 각각의 feature 브랜치에서 develop브랜치를 rebase하고, develop에 merge하여 깃 히스토리를 관리

 

[Git 컨벤션]

• 커밋 타입은 [태그: 제목] 형식
• 태그는 영어로 쓰되 첫 문자는 소문자
• 태그로는 feat, fix, docs, style, refactor, test, chore 를 사용

 

Git 히스토리 복잡한 문제

Git Branch 전략을 사용하여 develop 기준으로 feature 브랜치를 따서 각자 개발하는 방식은 좋았으나 한사람이 먼저 develop 브랜치에 merge하면 다른사람이 push 하기전에 develop 브랜치의 소스를 자신의 feature 브랜치에 merge를 한후 develop 브랜치에 merge를 하니 깃 히스토리가 너무 어지러웠다. 그래서 어느 시점에 어느 기능까지 완료가 되어있는지 파악하기가 어려웠다.

 

Git을 공부하고 merge가 아니라 rebase를 해야 겠다는 판단을 했고 develop 브랜치에서 자신의 feature 브랜치를 합칠때 rebase를 사용하도록 하였다. rebase를 사용하는 이유는 develop에서 feature 브랜치를 만들었을때의 시점을 update된 develop 브랜치기준으로 브랜치를 만들었다는 것으로 시점을 옮겨야 history가 구름모양으로 아름답게 나온다.

 

Git 히스토리 관리를 위한 rebase 방법

rebase 방법은 develop 브랜치로 이동해서 pull을 받아 업데이트 한 후 자신의 브랜치에서 rebase를 하고 push force를 하면된다.

 

[단계]

1. git checkout develop : merge 하여 업데이트된 develop 브랜치로 이동

2. git pull :  develop 브랜치에서 pull

3. git checkout feature/xxx : 자신의 feature 브랜치로 이동

4. git rebase develop : 자신의 branch로 와서 develop 브랜치를 rebase 한다.

5. git push --force : 자신의 소스 기준으로 원격 저장소에 저장한다.

 

참고 : git push --force 를 하는 이유는 만약 자신의 브랜치에서 push를 한적없다면 git push만 해도 된다. 하지만 push를 한게 있다면 rebase를 한 후 자신의 로컬 브랜치 소스의 헤드와 원격 저장소의 헤드 정보가 맞지 않기 때문에 push가 되지 않는다 그래서 강제로 로컬 소스 기준으로 원격 저장소로 밀어 넣기 위해 push --force를 한다.

 

 

rebase 하여 깃 히스토리가 구름 모양으로 이쁘게 나온것을 볼 수 있다. 이처럼 히스토리를 관리하여 어느 시점에 어떤 개발이 완료 되었는지 알수 있어 rollback 할 때 기준점을 찬거나 어느 버전으로 master에 merge할건지 찾기 쉬웠다.

 

 

참고 

- https://github.com/wecode-bootcamp-korea/14-2nd-2.9cm-backend

- https://kghworks.tistory.com/133