[Github 사용법 A to Z] 3_GIT으로 협업하기 (실무에서 쓰는 협업규칙)

저희 팀은 GIT으로 협업할 때 아래와 같이 진행합니다.

 

1. 새로운 브랜치 생성 (개인 브랜치로 한명만 작업이 가능한 브랜치입니다.)

ex) 모달 버그 수정일 경우: fix/modal 브랜치 생성하여 해당 브랜치에서 작업

브랜치 이름 규칙 [feature/기능이름] - feature 자리에 들어갈 수 있는 단어들 feature: 새로운 기능 개발 fix: 버그수정 hotfix: 실서비스 긴급 수정 사항 documentation: 문서 작성 및 업데이트

 

여기서 잠깐 ,,

main: 프로덕션에 배포되는 안정적인 버전을 관리하는 브랜치 (상용 사이트)
development: 개발 중인 소스를 관리하고 팀원 간 협업을 진행하는 브랜치 (개발 사이트)

 

2. 기능 개발이 끝나면 development 브랜치에 merge request (MR) 을 올린다.

 

👩🏻‍🏫 merge request (MR) : 

바로 development에 push 하지 않고

'나 이런 코드를 올렸는데 development 브랜치에 머지 해도될까요?' 하고 팀원들에게 요청을 올리는 것.

팀원이 수락하면 머지합니다. 

 

3. 팀원이 MR을 승인해주면 개인브랜치 => development 브랜치로 머지한다.

저희팀은 보통 사수에게 mr 요청을 올립니다.

 

4. development 머지가 완료되면 개발사이트에서 올려진 코드가 문제 없이 잘 동작되는지 확인한다.

저희팀은 CI/CD 프로세스를 구축해두었기때문에 development 브랜치에 머지를 완료하면 개발 사이트에 바로 반영됩니다.

개발사이트에서 기능이 정상적으로 작동되는지 확인 후 이상이 없으면 다음 단계로 진행.

버그가 발견된다면 다시 1번으로 진행 (새로운 브랜치 생성 후 다시 development로 mr)

 

5. development => main 브랜치로 MR

development 개발브랜치에서 main 상용브랜치로 머지리퀘스트를 올립니다.

(= 나 개발사이트 문제 없는 거 확인했는데 상용브랜치로 머지해도되죠?)

저희팀은 CI/CD 프로세스를 구축해두었기때문에 main 브랜치에 머지를 완료하면 상용 사이트에 바로 반영됩니다.

 

6. 상용사이트 확인

상용사이트에서 문제 없이 동작하는지 확인하고 이슈가 생겼다면 다시 1번단계부터 진행

새로운 기능을 추가할 때도 1번단계부터 진행

 

---

📌 요약

 

머지 순서를 정리하면 아래와 같습니다.

개인브랜치 (ex: feature/blog) => development 브랜치 => main 브랜치

 

개인브랜치와 다르게 development, main 브랜치는 팀원들이 공동으로 코드를 올리는 공간이기 때문에

머지 할 때마다 merge request로 머지해도 되는지 허락을 받고 수락되면 머지를 진행합니다.