Git commit은 Git 버전 관리 시스템에서 변경 사항을 저장하고 커밋 메시지를 추가하는 작업입니다.
$ git commit -m "커밋 메시지"
우선 커밋에 대해 알아야할 점이 있다.
2가지 수정 사항이 있는 상황을 가정해본다.
A파일의 A1코드에 버그가 있어서 수정했는데, 이에 영향받는 B, C 파일의 코드를 고쳤다. 수정하다 보니 A파일의 A2코드의 성능을 개선할 여지가 생겨서, A2코드를 리팩토링하고 이에 영향받는 D, E 파일을 수정했다.
이제 작업을 마무리한 것 같아 커밋을 하려고 보면 A, B, C, D, E 파일을 커밋해야 한다.
그래서 커밋 메시지를 고민하다가, "A컴포넌트의 XX버그를 고치고, A컴포넌트의 YY한 부분을 리팩토링" 이렇게 적었다.
이런 경우는 의식의 흐름(?)이라고 부를 수 있는 일하는 흐름에 따라 커밋했다고 할 수 있다.
그러나 일반적으로 일하는 의식의 흐름대로 커밋하면, 추후에 이런 문제를 겪을 수도 있다.
A1 버그 처리한 것이 못되어 되돌려야 하는 상황이다. 그러나 되돌리기가 간단하지 않다.
분명 버그 수정과 성능 개선은 각기 다른 코드를 수정했다.
하지만 일일이 버그 수정 내용을 수동으로 되돌리거나 커밋을 Revert하고 다시 성능 개선 작업을 진행해야 한다.
설령 코드를 Ctrl + C, Ctrl + V 하더라도 여러모로 귀찮은 일이 아닐 수 없다.
의식의 흐름대로 커밋하는 것은 분명 일의 효율이 올라간다.
커밋하는 시간이 짧다면 짧은 시간이지만, 집중을 깨뜨리기에도 충분한 시간이기 때문이다.
액션대로 커밋을 한 경우에는 위와 동일한 상황이지만, 버그를 처리한 시점에서 한번 커밋을 한다. 성능 개선은 커밋 후에 한다.
커밋 메시지는 당연히, "A컴포넌트의 XX 버그 수정"과 "A컴포넌트의 YY한 부분을 리팩토링"으로 2개다.
커밋을 되돌려야 하는 상황에서도, 버그 처리한 커밋만 Revert 하면 되고, 성능 개선한 커밋은 그대로 들고 갈 수 있다.
물론 현실에서 항상 예시처럼 딱딱 맞는 상황이 발생할 것이라고는 기대할 수 없다.
일부러 예시에서도 덜어냈지만, 버그 수정한 것을 바탕으로 성능을 개선한 경우도 충분히 존재할 수 있기 때문이다. 이 경우에는 예시와 같이 할 수밖에 없다.
의식의 흐름대로 작업을 다 끝낸 후 커밋해도 괜찮은 경우가 있다. 각각의 액션들이 각기 다른 파일에만 영향을 미치면 된다.
버그 수정은 A파일에서 하고 리팩토링은 B, C파일에서, 성능개선은 D, E파일에서 하는 경우다.
만약에 성능 개선이 A파일을 조금 건드렸더라도, A파일 커밋할 때만 잠깐 메모장에 복사해 놨다가 다시 성능 개선 커밋할 때 붙여 넣는 방법도 있다.
다만 이 경우에도 커밋 메시지를 "버그 수정 & 리팩토링 & 성능개선"과 같이 작성하여 한번에 커밋하는 것은 좋지 않다. 시간이 조금 더 걸리더라도, 세 번에 걸쳐서 커밋하는 것이 좋다.
결국 커밋은 파일 단위로 하게 된다. 한 커밋의 한 파일에서 2가지 액션이 들어가는 순간, 해당 커밋은 복잡한 커밋이 된다.
$ git commit --amend -m "message"
$ git push -f origin <branch>
$ git reset --soft <commit_ID> # commit 이력 *되돌리기*, 변경 내용 유지, Staged
$ git reset --mixed <commit_ID> # commit 이력 되돌리기, 변경 내용 유지, Unstaged
$ git reset --hard <commit_ID> # commit 이력 되돌리기, 변경 내용 삭제
$ git revert HEAD # 바로 직전의 commit 되돌리는 commit 생성
$ git revert <commit_ID> # 해당 ID의 commit 이전 상태로 되돌리는 commit 생성
참고한 글 : https://jaeheon.kr/257