Git 작업관리

프로젝트를 진행함에 따라 git을 더 잘 써야할 것 같다는 의무감과 동시에 욕심이 생기기 시작하였다.

main이 아닌 각자 branch에 push를 해달라고 요청을 하였지만, git이 아직 익숙하지 않아 그 마저도 어려워 하는 사람들이 있었기에 내가 욕심이 난다고 하여 무작정 추진할 수는 없는 노릇이었다.

 

이윽고 최종 프로젝트가 다가왔고, 이번에는 모두가 의욕적이었기에 많은 변화를 시도할 수 있었다.

Git을 좀 더 잘 쓰기 위해서 우리는 어떤 전략이 있는지 살펴보았으며,  git flow와 github flow 둘 중에 하나 고르면 되겠다는 생각을 하였다.

 

git flow와 github flow 두개의 선택지 중에서 git flow를 선택하게 되었는데, 선택의 근거는 아래와 같습니다.

 

1. main branch는 배포를 위한 것이기 때문에 최대한 merge를 최대한 지양한다.

2. 간단하다고 쓰기 보다는 좀 더 전략적이고 체계적이며, 실무에서도 많이 쓰일만한 전략을 익혀보려 한다.

3. 설계가 명확하여 개발자들의 혼란을 최대한 줄일 수 있는 방식을 원한다.

 

위와 같은 기준을 바탕으로 git flow 전략을 사용하게 되었다.

 

git 작업 관리

---

git-flow를 이해한 것을 바탕으로 우리의 git 작업 관리 전략을 아래와 같이 만들어 보았다.

 

1. upstream 레포지토리에 main 브랜치와 develop 브랜치를 생성한다. (최초 1번)    (github에서 main 브랜치와 develop 브랜치가 생성이 됩니다.)

2. git clone을 이용하여 github project를 local로 받아온다.

3. 기능 구현을 할 경우 develop브랜치에서 feature/post 같은 형식으로 로컬 브랜치를 생성한다.

4. 작업이 완료되면 origin 브랜치에 3번과 같은 이름의 브랜치로 push한다.

5. develop브랜치로 pull request를 요청한다.

    (병합은 main이 아닌 develop으로 진행을 해주세요!!)

6. 충돌이 있으면 팀원과 협의 후 충돌을 해결하고 pull request를 merge한다.

7. merge를 하였다면 자신의 기능이 잘 돌아가는지 테스트를 해야합니다.

8. 3번으로 돌아가서 같은 작업을 반복합니다.

9. develop 브랜치에서 main으로 merge를 할 때는 모두에게 알리고 같이 진행할 수 있도록 합니다.

Commit 메세지 작성에 대한 약속

---

이번에는 commit 메세지를 어떻게 작성할 것인가에 대해서 얘기를 나눠보았다.

commit은 어떠한 기능에 대한 commit인지 짧고 명확하게 나타내 줬으면 좋겠다는 생각을 하였다.

검색 끝에 많은 사람들이 사용을 하는 커밋 가이드를 찾을 수 있었습니다. Udacity Git Commit Message Style Guide 

 

커밋 메세지 작성 가이드

• feat : 새로운 기능을 추가하거나, 기존 기능을 요구사항 변경으로 인해 변경한 경우
• fix : 버그를 수정한 경우
• docs : 문서(주석) 추가/수정의 경우, 직접적인 코드의 변화 없이 문서만 추가 수정 했을 때
• style : UI를 추가/수정하거나, 스타일 관련 작업의 경우
• refactor : 기능의 변경 없이, 코드를 리팩토링 한 경우
• test : 테스트 코드를 추가/수정한 경우
• chore : 기능/테스트, 문서, 스타일, 리팩토링 외에 배포, 빌드와 같이 프로젝트의 기타 작업들에 대해 추가/수정한 경우

 

우리는 커밋메세지 작성 가이드에서 issue number를 추가하여 어떤 주제에 속하는 지를 조금 더 명확하게 나타낼 수 있도록 하였습니다.

[#issue number] feat: subject