[Git] github 브랜치 네이밍 및 PR 올리는법

Github

브랜치

• master(main): 오류 없는, 항상 배포할 수 있는 안정화 버전 유지.
• develop: 기능 개발이 완료된 브랜치들을 병합하기 위한 브랜치 (모든 기능이 추가되고 버그가 수정되어 배포버전이 완성되면 master 브랜치에 merger(합병) 하면 됩니다.)
• feature: 기능 개발을 위한 브랜치 (기능이 완성되면 코드 리뷰 진행 후 develop 으로 push-merger 를 진행하면 됩니다.)

브랜치 네이밍 (참고)

• feature: 새로운 기능 개발 ( 예시: (개발 타입)/(개발하는 도메인)/(일감번호) // feature/user/1 )
• fix: 버그 수정
• docs: 문서 수정
• refactor: 코드 리팩토링

프로젝트 진행 시 브랜치 생성 및 병합까지의 순서

1. master branch 생성 후 master branch 에서 develop 브랜치 생성. (조장)
2. develop 브랜치 생성 후 기능 생성, 버그 수정, 등 역할에 맞게끔 feature, fix 등 브랜치 생성 (조장 및 팀원)
3. feature, fix 브랜치에서 작업이 끝나는 경우 develop 브랜치에 push. (조장 및 팀원)
4. develop 브랜치에 push 된 경우 조장은 merge 작업을 진행합니다. 1.팀원이나 조장이 PR 을 올렸을 경우 코드에 문제가 없다면 이 페이지에서 merge 를 진행하면 코드가 합병됩니다 (자신이 PR 올린 브랜치에).
5. 합병이 성공적으로 진행이되었다면 develop 브랜치에서 다시 브랜치를 만들어 작업을 진행하시면 됩니다.

주의할점.

• 예를들어 위와같이 병합이 완료되었을 때 이전에 작업하시던분들은 develop bracnh 를 pull 받아 최신버전을 유지해주어야합니다. (merge 시 충돌 방지)

• 1번이 merger 완료 후 develop 브랜치는 user1 의 코드를 병합하여 가지고 있습니다.
• 여기서 user2 브랜치가 병합을 시도하려할 때 develop 은 user1 브랜치의 코드를 가지고 있으나 user2 브랜치는 develop 최신 버전을 유지 하지 않았을 때 user1 의 브랜치 코드에 대한 정보가 없어 develop 에서 충돌이 나게 됩니다.
• 여기서 충돌을 물론 해결할 수 는 있지만 당사자들이 없을 때 어느 코드가 맞는지 분석하는데 시간이 걸리며 최신버전을 유지할경우 시간 절약이 되어 develop 최신버전을 유지해주는것이 효율적입니다.

미흡한 부분이 많습니다! 가감하여 봐주시고 읽어주셔서 감사합니다.