자료 출처
https://puleugo.tistory.com/107
https://www.youtube.com/watch?v=-27WScuoKQs

brach를 분류하는 이유

협업 중 수정된 코드의 충돌을 방지하기 위해!

이전 내용과 이어진다. 다시 메인페이지로 가보자
여기 branch에 main이라고 적힌걸 볼 수 있다.

코드버전을 파일 각각의 commit으로 관리할 수도 있지만 프로젝트 전체 repository(ex 모델, 웹 등)의 버전을 관리할 수 있다.

실제 어플리케이션을 개발할 때 버전 1.0으로 출시한다고 하면 버전을 1.1, 1.2 등등으로 업데이트를 한다. 이때 관리하는 repository가 하나인 상태에서 누군가는 개발해서 추가하는데 서비스는 운영된다고 가정을 해보자. 그럼 코드가 계속 수정되는 와중에 이용자가 있으므로 필연적으로 오류가 발생할 수 밖에 없다.
그래서 운영하는 서비스와 개발중인 서비스를 분리할 필요가 있다.

이를 위해 brach관리 전략으로 GitFlow가 있다.

gitflow는 git에서 제공하는 브랜치를 활용한 변경 이력 관리 전략이다.

내용은 다음과 같다

main(master): 서비스을 직접 배포하는 역할을 하는 브랜치
feature(기능): 각 기능 별 개발 브랜치
develop(개발): feature에서 개발된 내용이 저장되는 브랜치
release(배포): 배포를 하기 전 내용을 QA(품질 검사)하기 위한 브랜치
hotfix(빨리 고치기): main 브랜치로 배포를 하고 나서 버그가 생겼을 때 빨리 고치기 위한 브랜치

이를 위한 설명이다.

다시 돌아와 branch를 추가하는 방법이다

기존에 만들어진 main을 클릭하고 저 칸에다 입력을 해주면된다.

저기에 create branch develop from main을 클릭하면 develop branch가 만들어진다.

다시 위의 사진으로 돌아가보겠다.

핑크색 노드를 주목해보자!
만약 우리가 공동프로젝트를 진행할 때 특정 기능을 추가하는 상황이라고 가정해보자. 각자 작성하는 코드가 다르므로 한 파일에서 진행을 하면 실행 시 에러가 날 것이다. 그렇기 때문에 추가적인 branch를 만들 필요가 있다.

따라서 이처럼 새로운 branch를 만들어 줘야한다.

github에서 코드를 직접 수정할 수도 있다.
연필 모양을 클릭하면 아래와 같은 창이 뜬다

작성이 끝나면 commit change를 클릭하여 commit을 작성하고 brach경로를 설정하면된다. 이 경우에는 앞에서 만든 사본_edit으로 설정해 주었다.

그 이후 pull requests에 들어간 후 Compare & pull request에 들어가보자

그럼 이 화면으로 넘어간다. 이 화면 위의 노란색으로 체크한 것은 사본_edit에서 수정된 사항을 main으로 보낸다는 것이다. 또 업무 보고 시 추가적인 텍스트와 요청사항을 입력한 후 아래 create pull request를 통해 팀리더에게 공유할 수 있다.

다음화면에서 merge pull request를 클릭하고 confirm merge 버튼을 클릭하면 사본_edit에서 작업한 작업이 적용된다.

그이후 특정 branch의 용도가 사라지면 그 branch는 지우면된다.

이때 main이 default로 되어있는데 main은 최종본이기 때문에 계속 수정하는게 좋지 않다. 따라서 develop을 default로 바꿔주는게 좋다.

github는 이외에도 회의기록용으로도 사용할 수 있다. 이는 다음 글에서 다루겠다.