현업에서의 형상관리

원래라면 git add . -> git commit -m "" -> git push origin main 시퀀스로만 했으면 끝났을 터였다

많은 인원들과 작업하는 현업에서는 개인 프로젝트 & 소규모 프로젝트에서와의 형상관리와는 꽤 다른점이 많았다

1. dev & prod branch

이 부분은 익히 들었긴 했었다, dev브랜치에서 먼저 병합하고 테스트 한 다음에 prod브랜치에 올려 배포한다

 

2. rebase

출저 : https://seosh817.tistory.com/240

로컬에서 작업 중에 변경사항이 생겼다면 현재 진행상황에 대한 커밋을 남기고 pull을 받아 merge후 push를 했었다

물론 소규모 프로젝트에서는 상관이 없겠지만 인원이 많아지면 커밋 그래프(기록)이 지저분해지는 문제가 생긴다

 

하지만 rebase를 하게 되면 위처럼 꼬인 커멋 기록들이 선형적으로 깔끔해진다

rebase는 말 그대로 base를 옮긴다는 뜻인데, 여기서 base는 분기를 만든 후의 첫 커밋을 뜻한다

이에 대한 자세한 설명은 아래 링크 참조, 이해하기 쉽게 잘 설명해주심

https://firework-ham.tistory.com/12

 

간략하게 터미널 시퀀스를 설명하자면 아래와 같다

1. git stash (현재 진행중인 변경사항 메모리에 임시 저장) 또는 진행상황 커밋

2. git pull origin dev —rebase (리베이스 하면서 pull)

3. git push origin my_branch

이렇게 하면 원격저장소에서 rebase 끝

1번에서 stash를 했다면, git stash pop (임시 저장했던 변경사항을 지우면서 가져옴, 안 지우고 가져오기만 하려면 pop->apply)

3. pull request

공동으로 작업하는 브랜치(dev)에 병합해도 되는지 관리자의 승인을 받는 과정이다

별도로 자신의 브랜치에서 작업 후, rebase, push를 한 다음 자신의 브랜치와 공동 브랜치의 merge를 요청하는 pull request를 날린다

이 과정은 보통 원격저장소의 GUI에서 이루어지는 것 같다

---

git add . 으로 무지성 스테이징 역시 안된다, git graph로 모니터링 해가면서 커밋하니까 편한 듯

원격 저장소도 깃허브가 아닌 엔터프라이즈용을 쓰는 것 같다