위코드에서 공부하며 정리한 내용입니다.(사진 출처, 위코드)

Git flow

실제 서비스를 운영한다면, 서로 작업한 코드를 병합하는 과정에서 발생하는 콘플릭트를 사전에 해결해야 합니다. 그러기 위해 중간 단계의 브랜치를 만들어 활용합니다.

Main - 실제 배포해서 운영하고 있는 코드가 담긴 브랜치
Develope - Main 에 병합하기 전 각각의 기능들을 취합하는 브랜치
Feature/F1 - 각 기능별로 만들어서 작업하는 브랜치
Release - QA, 버그 테스트등을 위해 파는 브랜치
Hotfix - 운영중인 서비스에 장애가 생겨서 급하게 고쳐야 할 때 main 에서 바로 생성하는 브랜치

실제 개발을 진행하면 Main 에서 Develope 브랜치를 파고 거기서 feature 브랜치를 생성합니다. feature 브랜치의 작업은 develope 에 병합되고 다른 feature 들은 이 develope의 내용을 병합해서 최신화를 유지합니다. QA 나 버그 해결을 위해서는 Release 브랜치를 파서 바로 main 에 적용하기도 하고 운영중인 서비스에서 급박한 장애가 발생하면 Main에서 바로 hotfix 브랜치를 파서 작업합니다. 이런 플로우는 회사마다 다를 수 있습니다.

Git rebase

리베이스는 깃 머지와 같은 병합 방식으로 병합된 브랜치들의 커밋을 조금 더 보기 쉽게 정리할 수 있는 방법입니다. 머지를 사용하면 각 브랜치의 커밋들이 시간순서대로 섞여서 들어오고(history가 복잡해지고), 머지를 했다는 불필요한 커밋이 남습니다. 브랜치 이동간 남긴 불필요한 커밋도 포함됩니다. 깃 리베이스를 사용하면 머지 커밋이 남지 않고 각 브랜치별로 커밋이 모이고, 하나의 맥락으로 묶을 수 있는 커밋이라면 정리해서 하나로 합칠 수 있습니다. (깃 PR 상에 커밋이 하나만 남는)

깃 허브상에서도 옵션을 세팅하면 리베이스 머지가 가능합니다.

깃 리베이스 도중에 커밋 메시지만 정리하기 위해 Squash 를 사용합니다. 새로운 작업을 마치고 push 하기 전에 main branch 로 이동해 remote main을 pull 하고 내가 push 할 브랜치로 이동해 git rebase -i main 을 진행합니다. 그리고 나오는 창에서 가장 오래된 commit 을 pick 으로 남기노 나머지는 s 로 바꾸어 squash 합니다.

그리고 추가로 수정용 에디터 창이 또 나오면 최종 리베이스에 적을 커밋만 남기고 나머지 것들은 지워준 후 나와서 푸쉬합니다. 이렇게 되면 git 상의 history 와 로컬의 history 가 달라져 push가 되지 않으므로 -f 옵션을 사용해 강제로 푸쉬를 해야 합니다.
git push origin feature/login -f

rebase 컨플릭트 해결

리베이스 중 컨플릭트가 나면 리베이스를 멈추는데 이때는 머지와 비슷하게 해결합니다. 충돌이 나면 해당 코드 수정 후 git add . 을 하고 (수정 사항이 없으니 커밋하지 않고) git rebase --continue 를 진행합니다. 그렇게 충돌이 날 때마다 수정하고 git add . git rebase --continue 를 반복합니다. 이 과정에서 코드를 합치던 도중 중단된 것이므로 기존 코드가 안 보일 수 있지만 날아간 것은 아닙니다. 계속 컨플릭트를 해결하다 보면 모든 코드가 보이게 됩니다.

계속 해결이 안된다면, git rebase --abort 를 사용해 rebase 진행 전 상황으로 돌아갈 수 있습니다.
git reflog 로 돌아갈 지점을 찾고 git reset --hard [커밋기록] 으로 해당 시점으로 이동도 가능합니다.

참고 명령어)
git reset soft vs hard
git log
git reflog
giit checkout
git stash & git stash apply & git stash clear