[1] git checkout -b dev origin/dev
dev라는 브랜치 생성 시 origin에 있는 dev 브랜치의 내용을 dev에 다 가져와준다.
즉, 브랜치를 생성하고 머지를 해준다.git checkout -b 브랜치명 git pull origin 브랜치명
- 위의 명령어와 동일한 기능을 수행한다.
[2] 새 브랜치 생성 시 주의할 점
💡 branch를 새로 만들 때는 기준이 되는 브랜치(ex. main, dev)에서 만들어주자.
git checkout -b 브랜치명
[ 이유 ] 다른 브랜치에 있던 내용이 새 브랜치에 반영이 되므로
⇒ 분기가 기준이 되는 브랜치에서 되도록 하자.
[3] git push --all origin 브랜치명
모든 브랜치와 함께 push를 할 수 있다.
- 처음에 push할 때만 사용하고 더 이상 사용하지 않는 것이 좋다.
[4] git push --delete origin 브랜치명
원격 저장소에서 특정 브랜치를 삭제할 수 있다.
[5] tag 사용법과 사용 이유
git tag v1.0.0
태그를 위와 같이 생성할 수 있는데 주로, 배포한 버전에 태그를 붙인다.
만약, 배포 후 치명적인 버그가 생기더라도 빠르게 복구할 수 있기 때문이다.
git push --tags origin 브랜치명
태그들은 자동으로 원격 저장소에 올라가지 않으므로 별도로 push를 해줘야 한다.
[6] release 브랜치 이름의 규칙
주의) release 브랜치는 dev(개발 브랜치)에서 분기가 된다.
[7] 배포 버전 이후의 코드에 대한 pr 처리 방법
만약 1.0 개발 중일 때 받은 2.0에 대한 코드의 pr요청을 받게 되면 이 pr 이후 1.0에 들어온 커밋 메시지와 꼬이게 된다. rebase로 다시 커밋 로그를 수정 후 다시 pr를 날려야 한다.
이를 해결하기 위해서는 다음과 같은 명령어를 수행해야 한다.
git checkout dev
git pull origin dev
git checkout 2.0에 대해 작업하던 브랜치명
git rebase dev
git push -f origin 2.0에 대해 작업하던 브랜치명
[8] 배포 후 git에서 할 일
배포 버전과 관련된 코드만 가져오기 위해 release 브랜치와 머지 진행
git checkout main git merge --no-ff main git tag 배포버전 git push --tags origin main
release 브랜치에서 버그를 수정했을 수도 있기 때문이다.
git checkout dev git merge --no-ff dev git push origin dev
[9] git log --oneline --all --graph
모든 브랜치의 로그를 한 줄 그래프 형식으로 보여준다.
[10] git stash
변경사항을 임시로 저장할 수 있도록 도와주는 기능으로 커밋되지 않은 변경사항을 스택에 쌓아둔다.
내가 어떤 기능을 열심히 개발 중인데 hofix 요청이 들어오면 개발하던 코드들에 대해
1. 커밋을 날린다.
2. hofix를 위해 새 clone을 받아온다.
3. 변경사항을 전체 hard 리셋시킨다.
=> 이런 방법을 사용하면 git rebase를 이용해 커밋 로그를 다시 이쁘게 만들어야 하는 등의 추가작업이 발생한다. 이때, git stash를 통해 임시로 저장해두면 이런 번거로운 작업을 하지 않아도 된다.
git stash
git stash pop
작업하던 브랜치가 아닌 다른 브랜치에서도 꺼내올 수 있고 다른 커밋이 추가되어도 꺼내올 수 있다.
다만, 충돌이 발생하면 직접 코드를 수정해 충돌을 제거해줘야 한다.
< 추가 기능 >
git stash -m "원하는 메시지"
git stash list
git stash drop
git stash pop --index
git stash branch 브랜치명
git stash clear
git stash -u
[11] 기본 편집기 설정
""안에 원하는 편집기 이름을 넣어주면 된다.
git config --global core.editor "vim"