2차 프로젝트에 들어가면서 git rebase라는 새로운 flow를 익히게 되었다.
기존에 적용하였던 git flow는 각자 작업하던 branch에서 새로운 업데이트 사항이 생기면
git addgit commitgit push origin master- conflict 발생!
git checkout mastergit pull origin mastergit checkout feature/my branchgit merge master
의 과정을 통하여 작업을 하였으나, 위와 같은 flow의 단점은 여러 사람들이 협업 시에 지저분한 커밋 히스토리가 생긴다는 것이다.
위 사진에서 볼 수 있듯이...중간중간 Merge 메세지가 있어서 무슨 의도로 작업을 한건지 파악하기가 힘들다.
git rebase는 이를 보완해줄 수 있는 명령어이다. 불필요한 commit메세지를 줄이고 각 branch에서 실행시킨 주요한 commit 메세지만 남겨둘 수 있기 때문에 협업 시에 보다 명확하게 기능 파악이 가능하다는 장점이 있다.
git rebase를 하는 순서를 살펴보면
현재 branch에서 작업을 하다가 master에 변경사항이 생겼을 경우
git addgit commit -m "commit message"git checkout mastergit pull origin mastergit checkout feature/my branchgit rebase -i mastergit squash- commit message 정리
- conflict 발생!
- conflict 해결 후
git add . git rebase --continue-> rebase과정에서 conflict가 발생할 경우에는 커밋 개수만큼 conflict가 발생하므로Successfully rebased를 보기 전까지 계속git rebase --continue를 해줘야한다.
! 만약 rebase를 전부 취소하고싶다면 git rebase --abort명령어로 취소할 수 있다.
- conflict 해결 및
Successfully rebased가 되었다면 branch를 push해야하는데, 이 때 이전 push기록이 있다면 git에서 push를 막으므로,
git push origin feature/my branch --force명령어를 통하여 push할 수 있다.
git rebase사용이 처음에는 익숙치 않았지만 사용하다 보니 commit message를 간결하게 작성하는 것이 협업할 때에 어떻게 작용하는지를 경험하게 되었고 꽤나 큰 장점을 지녔다는 것을 알게되었다. 또한 기존에 적용시켰던 git flow에서는 다른 사람의 branch가 merge될 경우 내 branch를 최신화 하는 과정에서 불필요한 commit message를 남긴 경우가 발생했다면, rebase를 하는 과정에서는 이 과정을 줄일 수 있었다.
다만 git merge를 활용할 경우에는 직관적으로 흐름을 파악할 수 있다는 장점이 있음을 고려해볼 필요도 있는 것 같다.
마지막으로 세션 때 보았던 git flow에 관한 영상을 남기고 글을 마무리 해야겠다..😇
