애증의 깃허브,,, 실수하면 너무나도 화나지만 또 익숙해지면 무엇보다 편한 것,,^^ 다시는 까먹지 않기 위해 열정적으로 정리해보았다.
< 내 작업물을 올릴 때 >
👩🏻🍳 우리가 큰 뷔페 레스토랑의 주방장이라고 해보자.
`main` : 메인 뷔페
`dev` : 주방
`feature` : 요리 재료
⇒ `feature` 는 요리에 필요한 재료들이다.
⇒ `dev` (주방)에서 그 재료들을 모아서 요리를 한다. (즉, feature 브랜치에서의 작업을 dev에 병합)
⇒ 완성된 요리들을 `main` (뷔페 장소)에 진열한다.
이때 실패한 노맛도리 음식들이 main에 진열되면 안됨! 따라서 main에 올라가는 코드들은 dev에서 충분히 테스트가 완료된 음식들이어야 한다.
[ 실제 브랜치 적용 예시 ]
1. 새로운 작업을 하기 전에 먼저 브랜치를 생성한다.
- 새로운 컴포넌트를 만들기 전에 가장 먼저 branch를 생성하자.
- 이때 branch 이름은 보통 feature/컴포넌트명 으로 작성한다.
git checkout -b feature/signup # -b: 브랜치 생성과 동시에 전환
2. 작업을 완료한 후, commit & push를 통해 원격 저장소에 반영한다.
- 로컬 저장소: 내 컴퓨터, 원격 저장소: 깃허브
- signup 컴포넌트 작업이 다 완료되면, commit과 push를 통해 원격 저장소에 있는 내 signup 브랜치에 작업이 완료된 최신 코드를 반영해준다.
- 만약 로컬에서 브랜치를 처음 생성했다면, 원격 저장소에는 해당 브랜치가 아직 없음. ⇒ 첫 push를 해주고 나면, 그때 원격 저장소에 내 브랜치가 생성된다.
git add .
git commit -m "✨feat 회원가입 컴포넌트 작업 완료"
git push origin feature/signup
3. Pull Request(PR)를 생성한다.
- PR: 원래 코드를 수정하거나 그 코드에 새로운 기능을 추가할 때, “내 수정 내용을 프로젝트에 반영해주세오”라고 요청하는 것.
- 원격 signup 브랜치에 push를 하면, 깃허브에서 Pull Request(PR)를 생성할 수 있다. 이때 PR의 대상 브랜치를 dev로 설정하고, 요청을 보낸다. (내가 제일 실수 많이 하는 부분,,8ㅅ8)
❓ 그냥 dev로 바로 push하면 되는 거 아님? 굳이 내 원격 브랜치로 push하고, PR 과정을 거쳐서 dev로 병합해야 할까?
👀 만약에 내가 작성한 코드에 문제가 있는데 바로 dev로 push 해버린다? 그러면 돌이킬 수 X.
그래서 중간에 안전 장치 느낌으로 PR 과정에서 문제가 있는지 검토하는 것.
4. PR을 날리면 다른 팀원들이 내 코드들을 검토한다.
- 코드에 문제 없을 때: 팀원들이 PR을 승인해주고, 내 코드가 dev 브랜치에 병합된다.
- 코드에 문제가 있을 때: 코드를 수정한 후 다시 PR을 업데이트 해야 함. (만약에 코드리뷰에서 문제가 발견되면 코드 합칠 수 X)
5. merge 후에 feature/signup 브랜치를 삭제해주자.
- PR이 승인돼서 merge 되면, 로컬과 원격에서 feature/signup 브랜치를 삭제해주자.
git branch -d feature/signup # 로컬 브랜치 삭제
git push origin --delete feature/signup # 원격 브랜치 삭제
< 작업 도중에 원격 dev가 변경됐을 때 >
🚨 이런 상황에서 내가 PR을 날려버리면? (아찔)
- 깃에서는 일단 로컬 dev, 원격 dev를 비교한다.
⇒ 내가 수정한 App.js랑 원격 dev의 App.js를 비교할텐데, App.js의 같은 3번째 라인인데도 내용이 서로 다름.
⇒ 깃은 둘 중에 뭐를 선택해야 하는지 모르기 때문에 충돌이 발생함.
⇒ 원래 같았으면 깃이 자동으로 합쳐줬을 일을, 어디서 충돌났는지 내가 수동으로 확인해가면서 해결해야 댐;
🛠️ 그러니까 원격 dev가 변경되면 다음과 같은 처리를 해주자.
- 원격 저장소의 dev가 변경됐다? 그럼 로컬 dev도 못참지 ㅋ 바로 최신 버전으로 반영해주자. (동기화 너낌)
- 근데 그건 그거고, 일단 나는 현재 작업 중이기 때문에 지금까지의 변경 사항을 add, commit을 통해 저장해놔야 한다. (만약, 이 작업을 안할 거면 git stash 로 임시저장 할 수 있긴 함.)
- 먼저, 현재 내 브랜치에서 dev 브랜치로 이동하자. (signup ⇒ dev)
git checkout dev
4. 원격 dev의 최신 변경 사항을 내 로컬 dev로 가져온다.
git pull origin dev
5. 이제 다시 작업하던 signup 브랜치로 돌아가자.
git checkout feature/signup
6. 이제 내가 작업하던 signup 코드와 최신의 dev 코드(로컬에서의 dev)를 통합해주자. 이때 2번 단계에서 미리 commit을 해뒀기 때문에 그 시점에서의 코드가 보존되고 있는 상태이다.
git merge dev
⇒ 만약 merge 과정에서 충돌이 일어났다?
⇒ 그럼 충돌 난 파일을 수정해주면 된다. 그리고 나서 다시 add, commit을 해주자. 그럼 병합 완.
🤦🏻♀️결론
모두를 위해서 수시로 commit, pull하자^^!