[Tars] 회고록 6일차 - git rebase

오늘은 내 파트는 많이 못 했지만 팀원들과 회의를 하면서 git에 대해서 상의를 하는 시간을 갖었다.

PR을 merge를 할 때 반드시 rebase를 하라고 해서 하는 방법과 이유에 대해서 간략하게 정리를 해보았다.

git rebase 해야하는 이유

우선 PR을 올릴 때 rebase를 안하면 pull받아온 파일의 커밋 기록이 남았다.

커밋 기록이 남으면 pull받아온 부분도 files changed에 남기 때문에 코드리뷰를 하기가 어려워지고 PR도 지저분해진다.

그래서 rebase를 하면 그 브랜치에서 작업한 부분만 files changed에 남아서 코드리뷰를 하기가 편하고 깔끔해진다.

 

Files changed가 뭔데

 

git pull rebase를 하는 방법

자신 브랜치에 있는 작업물을 가져오고 싶으면 

1. git pull —rebase origin {가져오고 싶은 브랜치명}
2. 충돌 해결
3. git rebase —continue
4. 충돌 해결과 git rebase --continue 반복
5. 다 되면 push

 

충돌 해결을 하다가 꼬이게 된다면

나는 원래 프로젝트 자체를 지웠다가 다시 깔고 진행을 하였는데 다른 방법이 있었다.

꼬인 브랜치를 지웠다가 fetch로 다시 연결해서 다시 가져오면 됐다.

1. git checkout {아무 다른 브랜치}
2. git branch -D {브랜치명}
3. git fetch origin
4. git checkout {브랜치명}

 

git pull rebase해야만 PR이 가능하도록 설정하는 법

 

Settings에 들어가서 조금 내리다보면 Pull Requests에 대한 설정이 가능하다.

 

여기서 Allow rebase merging만 체크하면 rebase했을때만 PR이 가능하도록 설정이 가능하다.

 

git pull과 git pull --rebase 차이점

2024.02.23 - [개발/github] - git pull와 git pull --rebase의 차이점