Git 특강
별도의 브랜치?
복사본, 수정용으로 이용 가능
-
git branch [브랜치 이름]
브랜치 생성 -
git branch
모든 브랜치 확인(내 브랜치 생성 확인 가능) -
Q를 누르면 무한슬립..을 빠져나올 수 있음
-
git switch [브랜치 이름] / git checkout [브랜치 이름]
해당 브랜치로 이동.
원래는 checkout만 있었으나 의미상 행동과 잘 맞지 않아 switch 추가.
기능은 똑같음. -
git switch -c [브랜치 이름] / git checkout -b [브랜치 이름]
브랜치를 만들고 동시에 해당 브랜치로 이동
c : create
b : branch
브랜치 merge
1) git switch main 또는 git checkout main
-> 2) git merge [브랜치 이름]
풀 리퀘스트
사실 git merge는 잘 쓰지 않는다.
직접 github에서...
풀 리퀘스트를 쓰는 이유는 코드 리뷰를 위함
Pull : 당겨서 합치다 (merge)
Request : 요청하다
풀 리퀘스트 순서
git add .
git commit -m"어쩌구저쩌구"
git push [브랜치 이름](메인 말고, 내가 작업하던 그 브랜치에)
github에 올라가 풀리퀘스트 요청, merge
로컬 브랜치 main도 바꾸어야 함!
메인 브랜치로 checkout 해서 git pull origin main으로 당겨오기.
메인 브랜치가 배포용이기 때문에, 어느 정도 기능 개발이 완료되어야만 풀 리퀘스트를 보내고 merge할 수 있는 단점이 있다.
따라서 develop 브랜치를 따로 만들어 배포 전 테스트 용으로 사용하는 것이 좋다.
변수명이 겹치는 등의 예상 밖의 충돌도 있을 수 있다.
로컬에서 데브를 내 브랜치로 끌고 와, 내 코드와 충돌이 없는지 확인하고 기능 브랜치에 push하면 어느 정도 방지할 수 있다.
conflict?
방지를 하기 위해 git pull origin develop을... 내 브랜치에서 합니다.
오류가 난 부분을 지우고 고쳐 다시 내 브랜치에 push합니다.
(develop 로컬 브랜치에도 다시 pull로 당겨오는 것 잊지 말기)
충돌이 해결되어 자연스럽게 merge가 가능합니다.
다시 정리
git clone
git branch [브랜치 이름]
git add .
git commit -m "메시지"
git push origin [브랜치 이름]
git pull origin dev
(내 브랜치에... 가지고 와서 테스트. merge 해결)
git push origin [브랜치 이름]
풀 리퀘스트 요청
리퀘스트 완료 후 git pull origin dev(로컬에도 최종 사항 반영)
git ignore?
git으로 관리하고 싶지 않은 파일용
