일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- SQL
- HTTP 완벽 가이드
- Gunicorn
- Query
- stack&que
- ORM
- Stack
- greedy
- Q objects
- stateful
- postreSQL
- Programmers
- AWS
- permutations
- was
- stateless
- dictionary
- codecov
- ws
- Python
- Git
- pytest
- utils
- Bruteforce
- Unit Testing
- Django
- algorithm
- combinations
- TDD
- 백준
- Today
- Total
해피 코딩!
Git 활용 - pull fetch merge rebase 본문
해당 내용은
Rebase
가 주를 이룹니다.
Fetch
local git
에게 원본에서 최신 메타 데이터러 정보를 검색하도록 지시
git diff head origin/main
을 통해 확인 가능
Pull
git pull
원격 저장소에서 변경 사항을 가져오고 복사
pull
과 fetch
의 차이는 가져온 파일에 대한 merge
수행 여부입니다.
Merge
- 머지는 추가적인 커밋을 생성시킨다.
Rebase
Rebase
는 커밋 히스토리가 보다 깔끔하다.main
을 보면 커밋의 ID는 그대로 인데,develop
의 커밋 ID들이 변경이 되었다.head -> develop
에서git rebase master
하면 된다.
Rebase
한 브랜치의 log
를 살펴보면 히스토리가 선형이다. 일을 병렬로 동시에 진행해도 Rebase
하고 나면 모든 작업이 차례대로 수행된 것 처럼 보인다.
Rebase
는 보통 리모트 브랜치에 커밋을 깔끔하게 적용하고 싶을 때 사용한다.
Rebase
를 하든지, Merge
를 하든지 최종 결과물은 같고, 커밋 히스토리만 다르다는 것이 중요하다. Rebase
의 경우는 브랜치의 변경 사항을 순서대로 다른 브랜치에 적용하면서 합치고, Merge
같은 경우는 두 브랜치의 최종 결과만을 가지고 합친다
Rebase의 위험성
이미 공개 저장소에 push 한 커밋을 rebase
하지 마라
Rebase
는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만든다.
다음의 예제는 깃 공식문서에 있는 Rebase
의 위험성을 보여주는 예시이다.
중앙 저장소에서 clone하고 일부 수정을 하면 커밋 히스토리는 아래와 같다.
팀원 중 누군가가 커밋, 머지를 한 후 서버에 push를 한다. 해당 이 리모트 브랜치를 로컬에 fetch, merge하면 히스토리는 아래와 같다.
그런데 push한 팀원은 merge한 일을 되돌리고 다시 rebase한다. 이후 저장소에서 fetch하고 나면 히스토리는 이렇게 된다.
대참사 발생 C4
가 중복되기 시작한다.
- 다른 팀원이
c4
에 의존하던 커밋c4, c6
을 삭제하고 rebase한 커밋을 다시 push한다.
지속적인 대 참사가 발생한다
로컬에서는 c4'
와 c4
, c6
, c8
등 여러 문제를 가진 커밋들이 생겨난다.
- git log 로 히스토리를 확인해보면 저자, 커밋 날짜, 메시지가 같은 커밋이 두 개 있다(C4, C4'). 이렇게 되면 혼란스럽다. 게다가 이 히스토리를 서버에 Push 하면 같은 커밋이 두 개 있기 때문에 다른 사람들도 혼란스러워한다.
C4
와C6
는 포함되지 말았어야 할 커밋이다. 애초에 서버로 데이터를 보내기 전에Rebase
로 커밋을 정리했어야 했다.
git pull 명령을 실행할 때 옵션을 붙여서 git pull --rebase
로 Rebase
할 수도 있다.
추가해야 할 내용
- 해결의 과정을 알지 못합니다.
git pull --rebase
의 정확한 의미를 아직 파악하지 못했습니다.git rebase --onto
찾아보기
요약
- git에서 한 브랜치에서 다른 브랜치로 합치는 방법으론 두 가지가 있다.
Merge
와Rebase
Merge
는 새로운 커밋을 만들어낸다Rebase
는 변경된 사항을 Patch로 만들고, 이를 head로 가리키고 있는 브랜치에 적용하는 방법.git pull
=git fetch
+git merge
git pull --rebase
=git fetch
+git rebase
참고링크
후기
- 협업을 할 때
rebase
를 사용하지 않고merge
만 사용하였던 것이 커밋의 로그를 지저분하게 만들고 있었다는 것을 깨닫고 반성하게 되었으며 upstream remote
에서 항상fetch
를 확인하지 않고pull
로 파일 및 데이터의 컨플릭트를 해결하였던 부분이 무지에서 비롯된 버릇이었다는 것을 깨닫게 되었다.- 항상 올바른 피드백을 주시는 지인에게 무한한 감사를