브랜치 이름 규칙과 테스트
메인 브랜치 v1.2.0일 경우
- 기능 개발 : feature/login, feature/select-product [조직의 규칙을 따라야 한다]. develop 브랜치 하위 브랜치 생성해서 작업하는 경우도 많다
- 출시 준비 : release-1.3, release-1.4
- 긴급 수정 : hotfix-1.2.1
세가지 경우에 브랜치를 생성해서 작업한다.
`git branch -d`브랜치명 : 브랜치 삭제
❓브랜치가 변경될때 수정한 기록이 같이 변경되는지??
예를들어, A 브랜치에 있는 상태에서 파일을 수정하고, B 브랜치로 checkout 할 경우 수정사항은 그대로 옮겨진다.
A 브랜치에 있는 상태에서 파일을 수정하고, add하고, commit을 하면, B 브랜치로 checkout 할 경우 수정 이전 상태로 파일이 바뀐다.
즉, 커밋을 해야지 현재 브랜치에 변경사항 포인터가 찍힌다 라고 이해해도 될 것 같다.
그러니 커밋 하기 전에 자신의 브랜치 상태를 철저히 확인해야한다
브랜치 push 업로드 하기
`git branch -r` : 깃허브 레파지토리 브랜치 정보 알려줌
여기서! Login Branch Commit 커밋은 feature/login 브랜치에 들어가있다.
깃허브에 적용하려면? origin/main 에도 올라갈 수 있도록 해야한다.
`git push 깃허브저장소별칭 깃브랜치명` : 깃허브에 브랜치 생성하고, 깃 브랜치 복제하기
로컬의 깃을 원격 깃허브에 올리겠다는 의미
깃 브랜치 전략
전략을 알아야~ 브랜치 병합을 할 수 있다.
==깃 플로우 라고도 한다.
대표적으로 두가지 전략이 있고, 그 이외에도 수많은 전략이 있다.
- fast forward
- 3-way
fast-forward 전략
main에서 branch를 생성한 뒤, main에는 아무런 추가 구현 하지않고, 생성된 branch에서만 추가 구현 한다.
합칠때, 생성된 branch를 main에 붙이기만 하면 끝나는 과정.
너무 간단하기에 많이 쓰이지 않는 전략
3-way 전략
main에서 branch를 생성한 뒤, main에서도 추가구현, 생성된 branch에서도 추가구현한다.
합칠때, 두 브랜치가 서로 비교하여 바뀐 것을 정리하여 합치는 전략
정답은 없다! fast-forward + 3-way 전략 합쳐서 진행하는 경우
main을 건들지 말자.. 기능단위 브랜치, 순서대로 merge 하자는.. 일반적인 전략!
Merge, pull request 병합
깃허브에서 충돌여부, merge 가능여부를 파악해준다
이전에, main 브랜치 protect 설정을 해주면 좋다.
pull request : PR : 브랜치 병합 요청
pr 버튼이 사라졌을 경우 contribute를 누르면 뜬다.
브랜치에 충돌이 없으니, 깃이 자동으로 merge 병합할 수 있다는 내용!
pr description에 메모 꼭 작성해야한다.
ex. Markdown 형식
### 주요 구현 내용
- 로그인
- 계정정보 : 아이디(이메일, 비밀번호)
- 비밀번호 알고리즘 :
### 이슈
-알고리즘 구현 시, ___ 에러가 있어서 ___ 알고리즘으로 대체
병합 후 브랜치는 지우는게 좋다. 복구도 가능하다.
깃허브 히스토리 : 시계모양~
병합이란?
브랜치를 생성한다는건, 협업을 위한것. base가지를 가지고, 추가 가지 브랜치를 병합한다.
깃허브에서 main 브랜치를 protect 보호 처리
추가 생성된 브랜치를 main 브랜치에 병합시키는 것 `pull request` 충돌 일어나나 자동으로 확인해준다.
pr 메시지
merge commit
최종으로 브랜치를 삭제해서 가지를 정리한다.
깃에 동기화
`git fetch -p` : 깃 동기화 - 브랜치 동기화 등
`git checkout main` → `git pull origin main`
pull 하기 전에 현재 브랜치 위치를 파악해야한다.
merge가 포함되어있는 모습을 볼 수 있다.
로컬 저장소에서도 원격에서 삭제한 브랜치를 삭제해야한다. ` git branch -D feature/login`
⭐ 순서
- git fetch -p : 깃허브 브랜치 목록 동기화
- 깃 브랜치 삭제 : git checkout main → fit pull origin main → git branch -D feature/login
충돌
깃허브에서 브랜치 생성할 수도 있다.
`git checkout -t origin/feature/1` : 깃허브에서 생성한 브랜치 (git branch -r) git branch에 받아오는 방법
각각의 브랜치를 수정해서 pr 날리면 두개가 동시에 뜬다!
같은 부분 수정
pr 날릴때 자동으로 merge 될 수없다고 깃허브가 파악해준다.
충돌 발생! 반드시 수정해주어야 한다.
어디가 충돌이 발생했는지 코드를 보여준다.
원하는 코드 남기고 다 지우고 → Mark as resolve 클릭 → commit merge
pr 남길 수 있게 된다.
이후 각 폴더마다, 다시 branch pull 과정 (동기화, 브랜치 삭제) 해야한다.
📝 최종 커밋 히스토리
☑️ 배운 점
main 브랜치 protected 설정해주는 것
main 브랜치를 기본 브랜치로 설정하고, 수정되지 않도록 처리해준다. 좋은 기능!
pr description 메모 작성법과 취업 꿀팁! 최대한 구체적으로 작성하는 버릇을 들이자
병합 후 브랜치는 지워주는게 좋다. 이전에는 브랜치 지우면, 커밋 기록이 다 날라가서 만일 문제가 생길시 복구를 못하는 줄 알고 있었는데, 깃허브에서 삭제하면 Restore branch가 가능하다!
git fetch -p 개념! 정확히 이해하지 못하고, pull 이전에 해주면 좋은것이라고 알고 있었다. 브랜치 생성이 워낙 복잡하기 때문에, 깃허브 원격에 브랜치 규칙을 정리하고, 로컬에 깃 브랜치 동기화 하는 과정이 필요한 것 같다.
브랜치 관리 순서 중요하다. 특히 현재 브랜치 상태를 확인하고 순서를 실행해야 하는 것을 잊지 말자!