목록rebase (2)
코딩마을방범대

예전에 커밋했던 소스를 수정해야할 일이 생겼다. 하지만 그 커밋 이후 여러 커밋을 했던 상태여서 푸쉬 기록을 날리기엔 어려운 상황이였다. 아래 방법이 정답은 아니겠지만 문제 없이 내가 원하는대로 수정을 완료했으니 참고만! 이전 커밋 수정하기 1. git 로그 확인 후 커밋 ID 복사 git log intellij 를 사용 중이라면, 굳이 터미널에 명령어를 입력하지 않고 git 탭에서 수정하려는 커밋보다 전 버전의 커밋에서 오른쪽 마우스 클릭 후 'Copy Revision Number' 을 클릭해주면 커밋 ID가 자동으로 복사된다. 2. rebase를 통해 작업 환경 세팅 git rebase -i [커밋ID] 위에서 복사했던 커밋ID를 이용해 위 명령어 입력 시 아래와 같이 커밋 목록이 주루룩 나온다. 수..

Git에서 브랜치를 연동할 때 rebase, 브랜치를 합칠 때 merge를 많이 사용한다. rebase 공통 base를 가진 브랜치에서, 한 브랜치의 base를 다른 브랜치의 최신 커밋으로 base를 옮기는 작업 merge git 브랜치를 다른 브랜치로 합치는 과정 merge를 사용해 브랜치를 연동 시킬 경우의 문제점은? A라는 브랜치에서 main으로 작업 중, A 브랜치를 base로 B라는 브랜치를 새로 만들 경우 log를 볼 때 아래처럼 연결된 선 하나가 새로 생긴다. 이후 B 브랜치에 작업하다가 A에 merge할 경우 아래처럼 연결된 선이 기존 A 브랜치에 합쳐진다. 위 작업으로 인해 여러 브랜치가 겹치게될 경우 아래처럼 복잡한 히스토리가 생길 수 있다! 위처럼 지저분한 히스토리를 만들지 않기 위해..