실무에서 사용했던 git 모음집

#1 브랜치A에 지난 브랜치B의 코드를 반영하게 하고 싶을 때

[가정]

브랜치A : feature/190701_git_test 

브랜치B : develop

상황 : 브랜치B에서 만든 브랜치A에서 작업 후 origin에 반영한 상태이다. 그리고 브랜치B에서 급히 수정을 해서 origin에 반영을 하였는데 브랜치A에도 이 수정 내역이 반영되었으면 한다. 

초기 상황

브랜치B에서 급히 수정을 한 후

[해결과정]

 

1. git rebase 브랜치B

브랜치A에서 rebase 실행  

 

충돌난 파일 src/test1.html을 상황에 맞게 수정해준다.

<<<<<<< HEAD
<div>update4444444</div>
=======
<div>update4</div>
<div>update5</div>
>>>>>>> feature/190701_git_test commit

 

2. git add src/test1.html, git rebase --continue

rebase는 merge와 다르게 충돌 부분을 수정한 후에는 commit이 아니라 rebase명령에 --continue 옵션을 지정해서 실행해야 한다. 

※ rebase를 취소하려면 --abort 옵션 지정

충돌 해결 후

 

3. git push origin 브랜치A -f

rebase만 실행한 경우, 위의 로그 사진처럼 아직 브랜치A가 브랜치B 앞으로만 옮겨졌을 뿐, origin에는 반영이 되지 않았다. 

※ 만약 브랜치A가 push되지 않은 상태였다면, force push가 필요없다.

push -f로 origin에 반영한 후

 

[결론]

 

히스토리 이력을 하나의 줄기로 만들어 깔끔하게 정리할 수 있다. 

하지만 rebase 대상 브랜치(여기서는 브랜치A)가 이미 origin에 반영되어 있고, 그 뒤에 변경한 commit들이 있다면 rebase를 하지 않는 것이 좋다.

 

[가정]

브랜치A : feature/190701_git_test2

브랜치B : develop

이미 origin에 반영된 브랜치A

그 뒤로 수정된 commit들이 있는 브랜치A

rebase된 후

이미 origin에 반영된 상태의 브랜치A에서 수정된 commit들이 있고 rebase를 하면, origin에 이미 반영된 지난 commit과 같은 중복된 commit이 만들어진다. rebase는 단순한 이동이 아니라 노드 변경점의 역추적을 통한 복제이다. 복제된 commit은 내용은 같지만 새로운 노드여서 기존 노드와 해쉬값이 다르다. 그 결과 똑같은 commit 노드들이 공존하게 되는 의도치 않은 상황이 만들어진다. 이처럼 origin에 내보낸 사이에 해당 브랜치에 변경된 사항들이 있다면 rebase하지 않는 것이 좋다. (참고 : https://djkeh.github.io/articles/Do-not-rebase-commits-that-you-have-pushed-to-a-public-repository-kor/) 

 

push -f한 후

물론 rebase한 상태에서 force push를 한다면, 중복된 commit은 사라지지만 원래의 commit 순서는 사라지고 지난 commit들이 모두 끌어올라와진다. 조심할 것~