깃 리베이스에 대해 잘 이해하고 있는 분 있나요?

[도와줘용(1.237)]

오픈소스들 보면 커밋 내역이 다 하나의 줄기로 관리되고 있는데 이게 리베이스를 활용하기 때문으로 알고 있습니다.

구글링하면 나오는 내용이긴 한데 조금 헷갈리는게 있어서 질문드립니다!

Q. `dev`에서 작업 브랜치(ex. feat/1)을 따고 커밋을 예를 들어 3개를 찍습니다. 이때 dev에 리베이스? 하라는 말이 3개의 커밋을 하나로 만들고 dev의 최신 커밋으로

밀어넣어라? 라고 이해하면 되는건가요?

[아마존바나나(9p33ljpywryb)]

ㅇㅇ 맞음. git rebase -i 쓰면 쉽게 가능. 커밋 세개 중 두개 squash하면 됨.

[도와줘용(1.237)]

답변 감사드려요. 아래 단계처럼 차례대로 하면 되는건가요?1. 오픈소스를 포크합니다.2. 포크한 프로젝트를 클론 받습니다.3. 클론 받은 프로젝트에서 브랜치(feat/#1)을 땁니다.4. 커밋을 열심히 합니다.5. 리모트?에 PR을 날립니다.6. 코드 리뷰를 받습니다. 리뷰를 반영하며 커밋이 더 생겨납니다.7. 메인테이너가 dev에 리베이스를 하기를 원합니다?8. 현재 브랜치(feat/#1)에서 git rebase -i HEAD^3 명령어를 입력하고 하나의 커밋만 pick하고 나머지는 squash합니다.9. 하나의 커밋이 되었습니다. 이것을 feat#1에 강제로 밀어넣는다?

[도와줘용(1.237)]

위의 순서가 맞을까요? 근데 제가 이해가 안가는게 dev에는 어차피 제가 밀어넣을수 없는데 dev에 리베이스하라는 말이 무슨 말인지 잘 모르겠습니다.

[아마존바나나(9p33ljpywryb)]

dev에 리베이스하라는 소리는 dev에서 branch out 되는 부분을 가장 최근 HEAD로 branch out되게 rebase하라는 소리임. 커밋 여러개를 하나로 squash하는 과정은 해도 되고 안해도 됨. 근데 보통 레포는 협업하는 공간이라 보는 사람 햇갈리지 않게 불필요한 커밋을 squash함으로써 가능한 한 적게 줄이는게 예의임.

[아마존바나나(9p33ljpywryb)]

git rebase -i HEAD^3 하지말고 git rebase -i dev하면 됨. 그리고 거기서 뜨는 커밋들 하나만 pick으로 놔두고 나머지는 squash로 바꾸고. 리베이스하면서 생기는 conflict는 리베이스 하면서 고쳐주면 됨. 고칠떄마자 git add하고 git rebase --continue하면 됨.

[도와줘용(1.237)]

흑흑.. 제가 완전 초보자라 말씀하신게 이해가 안되는데용.. "dev에 리베이스하라는 소리는 dev에서 branch out 되는 부분을 가장 최근 HEAD로 branch out되게 rebase하라는 소리임" 이 말씀이 dev에서 새로운 브랜치따고 작업하다보면 원본 dev에서도 계속 커밋이 일어나니까 새로 딴 브랜치를 dev에 리베이스해서 최신 이력을 반영하고 그 뒤에 제 커밋을 이어붙여라? 라고 이해를 하면 될까요?

[아마존바나나(9p33ljpywryb)]

유의할점은 포크한 님의 dev는 오픈 소스 레포의 dev와 같은 위치에 있지 않을 수도 있으니 (님이 코딩하면서 딴 사람들이 더 커밋 추가했을테니) 그건 맞춰두셈. 보통 깃허브에서 그런 경우일 경우, 알려주고 어떻게 하라는지도 알려줌.

[도와줘용(1.237)]

감사합니다!

[아마존바나나(9p33ljpywryb)]

이미지 수정 다시 올림:
https://imgur.com/a/vneGkoh

[도와줘용(1.237)]

많은 도움이 되었습니다~!