개요
팀 프로젝트에서 git 어드민 역할을 맡게되어 git 협업에 대한 이해가 필요했습니다.
팀원 모두가 개인 git repository 에만 push 경험만이 있었고
git 협업에 대한 경험이 전혀 없었습니다.
그래서 나만 이해해야 할게 아니라 팀원 모두에게 git 협업에 대한 설명을 자세히 해드려야해서 정리하게 되었습니다.
또한 팀프로젝트 중 git 충돌로 인해 시간이 많이 허비되고 팀 내부에서 갈등도 생길 수 있다는 말을 많이 들어서 확실하게 정리하고 싶었습니다.
Git-flow
git 협업에서 우선 가장 중요한 것은 git-flow 입니다.
위 사진이 가장 중요합니다. 저도 처음에는 무슨 구슬아이스크림인가 했는데
이해한 뒤 가장 합리적이고 리스크를 줄일 수 있는 방법이구나 납득했습니다.
브랜치를 여러개 만드는 방식인데 master, hotfix, release, develop, feature 의 브랜치를 만들어줍니다. 각각 브랜치 설명을 하자면 아래와 같습니다.
- master : 배포브랜치, 배포할 수 있는 상태인 브랜치. 그만큼 완벽하고 정리된 상태여야 한다.
- hotfix : 배포 중 간단한 수정을 위해 존재하는 브랜치
- release : 팀 내부에서 테스트 하기 위한 브랜치
- develop : 개발브랜치, 주로 여기에서 팀원들의 커밋이 merge된다.
- feature : 팀원 개인/ 기능별의 브랜치
과정을 간단히 정리하자면
- 여러개의 feature 브랜치에서 팀원 개인의 커밋을 작성한뒤 feature 👉 develop 로 merge한다.
- develop에 모으다가 어느정도 테스트단계에 오면 develop 👉 release로 merge한다.
- 테스트 단계 통과 후 실제 배포를 위해 release 👉 master로 merge한다.
- 배포 중 간단한 오류나 기능 수정은
hotfix 브랜치를 통해 수정후 다시 hotfix 👉master로 merge한다.
Pull request
merge를 하는 방법은 수정한 사람이 pull request를 보내서 어드민이 merge를 수락하면 merge가 됩니다.
pull request 를 할때 꼭 브랜치를 확인해 줘야한다.
Able to merge 가 떴다면 일단 merge가 가능하다는 뜻이다.
어드민은 다시 한번 pr의 브랜치를 검사해준다
아래의 commits 를 통해 수정된 코드들을 확인할 수 있다.
merge 버튼이 활성화 되어있다면 merge가 가능하다는 이야기!
만약 브랜치가 다르거나 수정하지 말아야 할 것을 커밋했다면 아래의 close pull request 버튼을 눌러서 merge 를 취소해준다.
