웹 풀사이클 데브코스 TIL 5일차

깃 브랜치 이름 규칙

• 원래는 master라는 이름을 썼었음 하지만 이름이 main으로 바뀌었음
• 언제 복사를 하나?
  • 기능 개발: feature/login, feature/select-product
  • 출시 준비: release-1.3, release-1.4
  • 긴급 수정: hotfix-1.2.1

브랜치 삭제

git branch -d {브랜치 이름}

브랜치는 커밋해야 그때부터 브랜치

브랜치를 커밋해야 그때부터 적용된다. 하나의 개발툴안에서 브랜치 왔다갔다 하다 커밋할 때 어느 브랜치에 있는지 꼭 확인해야함

git branch -r

remote에 있는 브랜치가 뭐가 있나 알려주는 명령어

git branch 이해

위 사진을 예시로 설명해보자면 origin 깃허브 레포지토리의 main, 로컬 main, 로컬 feature/select-product 브랜치는 두번째 커밋까지 된 상태고
로컬의 feature/login은 첫번재 커밋까지 된 상태이다.

깃허브 저장소에 branch 올리기

git push {레포지토리 별칭} {깃브랜치명}

브랜치 전략

깃 플로우라고도 함

fast-forward

A 브랜치 에서 B 브랜치를 생성한 시점부터
A 브랜치에는 아무런 추가 구현을 하지 않고
B 브랜치에만 추가 구현을 한뒤
다시 A 브랜치에 B 브랜치를 붙이면 끝남
협업에서 잘 쓰이지는 않는 방식임

3-way

A 브랜치에서 B 브랜치를 생성한 시점부터
A 브랜치에도 추가 구현을 하고
B 브랜치에도 추가 구현을 하고
B 브랜치와 A 브랜치를 합친다.(각 브랜치를 서로 비교하여 바뀐 것을 정리하여 합치는 전략)
일반적으로 많이 사용하는 전략

하지만 main 브랜치는 건드리지 않는게 국룰 따라서 main 브랜치를 비워두기 때문에 처음 병합은 fast-forward 방식이고 그 뒤에 병합은 3-way 방식으로 이루어짐

병합

• 브랜치를 생성한다는 것은 협업을 위한 것
• 병합을 깃허브에서 주로 함
• main 브랜치 보호 설정
• pull request(PR): 병합을 해주는 브랜치에게 당겨줄 것을 요청한다.
  브랜치는 병합 후에 삭제하는게 일반적.
• pull request 메시지는 무슨 구현을 했는지, 무슨 이슈가 있었는지 등등 자세하게 써야한다.
• 병합할때도 commit이 하나 찍힘. 이것을 merge commit 이라고 부름.

병합된 깃허브를 깃에 동기화하기

• git fetch -p 깃허브 브랜치 목록을 동기화 명령어
• 다른 브랜치로 빠져나간 후
• git pull {레포지토리 별칭} {브랜치 이름}
• git branch -d {브랜치 이름}

충돌

• git checkout -t {레포지토리별칭/브랜치이름} : 깃허브에서 브랜치를 가져오는 명령어
• 깃 브랜치를 병합할 때 충돌이 발생할 수 있음. 이럴 경우에는 깃허브에서 충돌되는 부분을 하나만 선택하라고 알려줌

후기

이번수업으로 깃허브 사용법에 대한 과정이 모두 끝이났다. 깃허브의 작동이 어떻게 일어나는지 CLI를 통해서 제대로 알아보았고 또 병합과 충돌수정도 깃허브에서 진행해본 것은 처음이었던 것 같다. 이제 깃허브를 사용할 때 문제가 발생하면 해결책을 찾는것도 더 쉬워질 것 같다.

 

 

키워드: 프로그래머스 데브코스, 국비지원교육, 코딩부트캠프