rebase

[- Disclaimer -] 아래 내용은 정보보안 공부 목적으로 작성된 것이나, 이를 토대로 허가되지 않은 대상에 실습을 진행할 경우 해킹 시도로 간주하여 법적 처벌을 받을 수 있음을 알려 드립니다.

충돌 상황

✦ 1) fork한 Repositry에서 기능 추가 후 Remote Repositry에 Push

✦ 2) Local Repositry에 Remote Repositry의 최신 Commit 2개이 반영되지 않은 모습

✦ 3) Remote Repositry에서 pull 받기

✦ 4) Local Repositry도 Remote Repositiry에 맞게 Commit 업데이트

✦ 5) Local Repositiry에 기능 추가 후 Remote Repository에 Push

✦ 6) Commit 하나 더 만들어 Push

✦ 7) 방금의 원본 저장소의 새 업데이트 정보가 없는 채로 새 작업이 수행되어 수정된 fork Repositry에서 원본 저장소로 pull request 생성 시 충돌 병합 발생

✧ Can`t automatically merge

Sourcetree에서 하나의 Local Repository가 하나의 Remote Repository가 아닌 둘 이상의 Repository를 바라보게 하여 fork된 Repositry에서도 원본 저장소 추적

✦ 실습을 위한 계정 변경

✦ 1) 원본 저장소 추가

✧ git remote add origin [Remote Repository]와 동일

✦ 2) upstream

✧ 원본 저장소를 뜻하는 관용적 이름

✦ 3) 원격 항목에 origin과 하위 폴더들 말고도 upstream이 추가됨을 확인

✦ 4) 패치

✧ upstream에서 Commit History 가져오기

→ 이력 새로 고침 기능이며, 원본 저장소의 master 브랜치에 5개의 Commit이 올라갔는데 나의 소스 트리에 해당 이력이 없으면 패치해여 받을 수 있음

✧ 최신 코드를 반영하는 pull과 다르게 내 코드엔 영향 없음

→ Default로 10분 마다 자동 패치하는 옵션이 있어 패치 없이 새 이력이 보였던 것 // 도구 옵션 원격 업데이트가 있는지 확인함(시간 설정 가능) Check/Uncheck

Rebase

✦ fork한 Repository에서 병합 Commit을 만들어 호환시키는 방식은 충돌 병합을 위해 불필요한 Commit 이력을 남겨 자신의 변경점이 계속 쌓이면서 지저분해 지므로 base를 이동시키는 방식으로 하는 충돌을 병합하는 방법

✦ 1) Graph로 "찜하기 기능 추가"의 base Commit은 "좋아요 기능 추가"인 것을 확인

✦ 2) 재배치

✦ 3) 다른 사람이 History를 보고 있다면 꼬일 수 있기 때문에 따라서 브랜치 하나 당 한 사용자가 쓰는 이유

✦ 4) 충돌 병합 작업

✦ 5) rebase 계속 진행

✦ 6) fork한 Repository의 특정 브랜치의 base Commit이 upstream/master의 특정 브랜치로 변경된 것 확인

✦ 7) rebase한 Commit은 이력을 조작하는 행위라 위험성 있어 Remote Rository에 일반 push로 저장할 순 없어 강제 push 진행

✦ 8) 강제 푸시 Check

원본 저장소 소유자에게 pull request 생성 후 원본 저장소 소유자의 승인/병합

✦ 아까의 경고가 발생하지 않음