메인 나뭇가지 이름: 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하기