프로젝트를 진행하면서 특정 기능 개발을 위한 브런치를 만들고 기능이 완성될 때까지 중간중간 커밋 기록이 남는다. 기능 추가, 버그 수정, 리펙토링 등등 수많은 커밋 내역을 거쳐 기능이 완성되면 Main 브런치에 푸시하게 된다. 이때 Main에 기능 개발까지 남겨둔 커밋 내역들이 모두 넘어가게 되면 히스토리가 지저분하게 느껴질 수 있다. rebase를 활용하면 특정 커밋 메시지를 수정하거나 개발과정에서의 여러 커밋 내역들을 깔끔하게 합쳐 히스토리를 간결하게 만들 수 있다.
commit log 확인하기
git log --oneline
log를 볼 때 --oneline 옵션을 추가하면 간단하게 커밋과 메세지만 확인할 수 있다. 예시를 위해 위 로그 중 06045a8 ~ 4601787 까지의 커밋을 합쳐보려 한다.
rebase 사용
git rebase -i HEAD~20
바꾸고자 하는 log가 있는 곳만큼 HEAD~ 뒤에 숫자를 넣어 편집할 수 있는 화면으로 넘어온다. 20을 입력했기 때문에 log 20개와 각종 커맨드들을 확인할 수 있다.
squash로 변경
# s, squash <commit> = use commit, but meld into previous commit
커밋 내역은 오래된 커밋부터 위에서 아래로 정렬되어 있고 편집모드에서 커밋 앞에 있는 커맨드를 수정할 수 있다. squash 커맨드의 설명은 커맨드를 사용한 커밋 이전의 커밋으로 합친다는 말 이므로 예전 커밋으로 이후 커밋들을 합치게 된다. 이후 편집 모드를 끝낸다.
스크린샷이 날아가버려서,, 위 커밋에 대한 사진은 없지만 아래 사진처럼 squash 하기로 한 커밋 메세지들을 편집할 수 있는 화면이 나온다. 없애고 싶은 내용은 앞에 해시태그를 붙이고 남기고 싶은 내용을 넣으면 된다. 마찬가지 편집 후 편집모드를 나오면 rebase가 이어서 진행된다.
rebase 진행
rebase를 진행하기 때문에 히스토리를 맞추기 위한 컨플릭트를 해결해주고
git push -f
원격저장소에 이미 저장된 커밋이라면 히스토리가 다르므로 강제로 밀어 넣어줘야 한다.
강제 푸시 참고 )
강제로 원격에 푸시할 때 에러가 난다면 깃허브 레포지토리 > 설정 > 브런치 > Branch protection rules 에 Main(or Master) 브런치가 등록되어 있진 않은가 확인해보자. 여기에 브런치가 포함되어 있다면 강제 푸시가 에러처리 되기 때문에 여기서 제외 시키고 필요에 따라 다시 추가해주면 된다.
경고❗️
예시를 들기 위해 원격저장소에 이미 올라가 있는 커밋을 수정했지만 깃 공식문서(Progit)에서는
이미 공개 저장소에 Push 한 커밋을 Rebase 하지 마라
는 말과 더불어 지키지 않을 경우 사람들에게 욕을 먹게 될 것이라 적혀있다.
혼자 쓰는 프로젝트라면 어느 정도 괜찮겠지만 협업의 경우 한 시점에 누군가 커밋을 푸시하고 다른 사람이 rebase를 진행한다면 히스토리가 심각하게 꼬일 위험이 있다. rebase를 다시 rebase 하는 방법 등등 많이 돌아가야 하기 때문에 꼭 유의하자.
원격에 밀어넣기 전에 컨벤션은 지켰는지 커밋 메세지는 적절하게 쓰였는지 꼭 확인하자,,
'Programing > Git' 카테고리의 다른 글
[Git] alias를 이용해 깃 명령어를 단축어로 사용 (0) | 2022.12.18 |
---|---|
[Git] github repository 연결하기 (0) | 2022.08.27 |
[Git] 깃 시작하기 (0) | 2022.08.03 |