프로젝트를 진행하다 보면 코딩보다도 github 사용법 때문에 시간을 허비하는 경우가 상당히 많다. 말 나온 김에 오늘 발생했던 github 관련 이슈들을 정리하고 가련다.
files changed
hstack 브랜치 풀리퀘스트(#3) => hstack 브랜치 수정 => 커밋 & 푸시 => center 브랜치 생성 => center 수정 내용 커밋 & 푸시 => center 브랜치 풀리퀘스트(#4)
hstack 브랜치를 풀리퀘스트(#3)올렸다. 근데 잘못해서 Center컴포넌트 수정내용까지 같이 올라갔다. 원래는 Hstack.test.tsx 파일에 추가한 내용만 올렸어야 했는데 잘못한 것이다. 이 때부터 github 커밋내용이 지저분해지기 시작했다.
#4에 커밋&푸시 할 당시에는 #3과 비교했을 때 수정된 파일이 2개밖에 없었지만 아래 빨간색 네모박스를 보게되면 Files changed가 7로 표시되어있는 걸 볼 수 있다.
여기에 표시되는 숫자는 main과 비교했을 때 업데이트 된 파일의 숫자를 말한다.
물론 여전히 Center 컴포넌트에 해당되는 파일들이 #3과 #4에 중복되어 반영되어있다. 이 내용은 내일 멘토세션 이후에 더 자세히 기록해놓을 예정이다.
git reset & git revert & cherry-pick
#3(hstack 브랜치)에 해당되는 내용을 수정하고 다시 push를 한다는게 또 center 브랜치에다가 해버렸다.. 왜그러니 정말😫😫😫
결국 내가 원하는 작업은 해당 커밋을 center 브랜치에 다시 커밋&푸시하고 싶은 것이었다.
해결방법을 찾다보니 3가지 해결책에 대해 알게 되었다.
1. cherry-pick
다른 브랜치에 있는 커밋을 선택적으로 내 브랜치에 적용시킬 때 사용하는 명령어이다.
git cherry-pick 커밋아이디
git log를 통해 커밋 히스토리를 확인한다 (브랜치 별로 커밋 히스토리를 볼 수 있다)
❗️창 종료하려면:q- 해당 커밋을 적용하고 싶은 브랜치로 이동:
git checkout 브랜치명 - 해당 커밋을 체리픽 해오기: `git cherry-pick 커밋 아이디
- 만약 해당 커밋이 2개 이상일 경우 여러개를 한꺼번에 적용하는 것도 가능하다
git cherry-pick XXXX YYYYY
git cherry-ppick XXXX..YYYY(XXXX..YYYY를 이용해 XXXX에서 YYYY 사이에 있는 모든 커밋을 체리픽 하는 것도 가능. 단 XXXX(가장 처음 커밋)에는 cherry-pick이 적용되지 않음 유의) - push 까지 해줘야 제대로 풀리퀘스트에 적용됨:
git push origin 브랜치명
2. git reset vs git revert
Reset rewinds history(files + commits) back to the previous commits
Revert rewinds your files back to the previous commits by adding a new commit to show this.
reset은 이력을 남기지 않고 원하는 커밋 시점으로 완전히 돌아가고 싶을 때 사용
revert은 과거로 돌아가겠다는 이력을 남기고 원하는 시점으로 돌아간다. 즉 이전의 커밋 내역을 남겨두고 새로운 커밋 내용도 만든다.
둘의 공통점은 과거로 돌아간다지만 가장 큰 차이점은 과거로 돌아간다는 내용을 커밋 이력으로 남기느냐 아니냐라고 볼 수 있다.
git reset
commit 히스토리에 빨간 네모 안에 있는 커밋은 사라지게 된다.
git reset --soft 커밋아이디: 커밋된 파일들의 커밋을 취소하고 staging area로 돌려놓음
git reset --mixed 커밋아이디(default): 커밋된 파일들을 add하기 전 상태로 돌려놓음
git reset --hard 커밋아이디: 파일을 완전히 삭제하므로 working directory와 stage 어디에도 남아있지 않게 된다.
git revert
revert를 통해 B커밋으로 돌아가려면
git revert d1d1d1// D커밋 revertgit revert c1c1c1// C커밋 revert
그리고 각각 revert한 내용이 커밋 이력으로 남게 된다.
git reset vs git revert의 사용용법
git reset은 커밋을 완전 삭제하면서 과거 커밋으로 돌아가는 것이기 때문에 원격저장소 및 팀원들이 작업하는 타 브랜치와 추후에 충돌을 일으킬 수 있다.
만약 혼자서 작업하는 레포지토리라면 로컬과 원격의 커밋 히스토리가 일치하지 않아도 git push --force를 통해 연결할 수 있지만 협업 프로젝트에서는 충돌 위험이 있다.
이렇게 협업 프로젝트일 경우에는 git revert를 써서 이전 커밋으로 돌아가는 방법이 안전하다.
