메인 나뭇가지 이름: main(기존명은 master)
develop 브랜치를 따고 밑에 feature로 depth를 더 줘서, feature/login, feature/select-product, feature
release-1.3, release-1.4
hotfix-1.2.1
git checkout -
git branch -d 브랜치명

*참고로, 내가 현재 머무는 브랜치에서는 해당 브랜치 삭제 불가→ git checkout 명령어로 이동 후 삭제
git branch 브랜치명
git branch
git checkout 브랜치명
바로, commit
브랜치 복사한다고 바로 병렬처리 되는 게 아님
브랜치를 브랜치답게 사용하는 것은 커밋부터
원격 브랜치 확인
git branch -r

깃에서 가지는 브랜치는 3개, 원격 깃허브에서 가지는 브랜치는 origin으로 한 개
깃에 만들어둔 브랜치를 원격 브랜치로 복제
git push 깃허브저장소별칭 깃브랜치명
반대로, 깃허브에서 브랜치 먼저 생성 → 깃으로 받아오기
git push 깃브랜치명 깃허브저장소별칭

팀플 시, 브랜치 생성하고, 어떤 단위로 브랜치 만들건지 등
어떻게 워크 플로우 짜는가
다양한 전략 가능
크게 2가지로 분류 (fast-foward, 3ways)
메인 브랜치는 배포할 브랜치라서 안 건드리는 게 국룰
A 브랜치에서 B브랜치 생성
A 브랜치에서는 추가 구현 없고, B 브랜치에서 추가 구현
이후, B브랜치를 A브랜치에 붙이는 방식

보통 잘 쓰진 않음
폴더 하나 가지고 개발하는 게 아니기에, 하나의 브랜치가 가만히 있는 경우 희박
A 브랜치에서 B브랜치 생성
A 브랜치, B 브랜치 둘 다 추가 구현 후, 서로 비교 후 바뀐 거 정리해서 합치는 전략

대부분, 3ways를 진행할 때는 fast-forward도 진행
PR(pull request) 전 권고 사항
setting → branches → branch protection rule
*근데, private repo에는 필요없는 듯? 확인 필요

pull request 버튼 누르고
마크다운 형식으로 description 작성
주요 구현 내용, 이슈 등에 대해서 작성(구현내용, 이슈는 필수로 작성하기)
pr에 대한 내용, 신경써서 작성하기, 협업 시에 소통하기 좋은 사람이라는 것



delete 진행
보통 브랜치는 사용이 다 끝나면 머지를 시킴
머지 다 시키면, 브랜치 없애주는 게 좋음

*머지 푸는 거, 브랜치 삭제한 거 복구하는 거 모두 가능
이후, 브랜치 목록 확인하면 브랜치는 메인뿐

브랜치를 생성한다는 건, 협업을 위한 것
그래서 우리는 주로 브랜치 병합(추가 가지 → base 가지로 합침)을 깃허브에서 진행
1. 메인 branch 보호
2. 추가 브랜치 main 브랜치 방향으로 병합 진행(pull request; pr)
3. 충돌 일어나는지 깃허브가 확인(자동으로)
*PR 메시지 신경써주기(주요 핵심 기능, 이슈)
4. merge 진행(”merge commit”) 병합 시에도 커밋이 발생
5. branch 삭제

git fetch -p
git branch 브랜치명
git pull origin main
merge 깃허브에서만 진행한 것
따라서, 로컬에서 동기화 진행해줘야 함
git branch -d 브랜치명
깃허브로 브랜치 생성하기


깃허브 내의 브랜치 로컬로 받아오기
git branch -t "브랜치명"
A폴더와 B폴더에서 똑같은 폴더를 깃허브에서 받아오고 폴더 내의 test1.txt 파일을 수정했다고 가정
A폴더가 수정본 업로드
이후, B폴더의 수정본도 업로드하면, 충돌 발생


이렇게 같은 부분에 대해서 수정한 것을 확인할 수 있음

이 경우, 확인 후 원하는 코드 남기고 나머지 없애주기
그 다음 상단의 mark as resolved 클릭 후 commit merge하기

