mv
명령어의 경우 파일을 이동시킬 수도 있지만 파일의 이름을 수정할 수도 있습니다.
$ mv README.md LICENSE
하지만 working directory에 존재하는 파일을 위와 같은 명령어를 통해 수정한 후 git status를 확인해보면 기존에 존재하던 REAMME.md파일이 삭제된 상태로 확인되는 것을 확인할 수 있습니다.
사실은 README.md파일을 LICENSE로 바꾼 것일 뿐이지만, README.md파일이 삭제되었다고 기록되기 때문에 단순히 mv명령어만으로는 정확한 이력을 남기기가 쉽지 않습니다.
이 경우 mv명령어 앞에 git을 붙여 사용해주면 해결됩니다.😊
$ git mv server.py main.py -> renamed
undoing의 경우 working directory에서 작업이 일어난 후 그 작업을 취소하고 싶을 때 사용을 할 수 있습니다.
//해당파일에 대한 resotre
$ git restore { file_name }
//모든 파일에 대한 restore
$ git restore *
unstaging의 경우 staging area에 올라간 내용을 내릴 때 사용을 할 수 있습니다. 즉, git add한 내용을 다시 내릴 때 사용할 수 있습니다.
$ git reset HEAD {filename}
하지만 reset
명령어의 경우 주의해서 사용하기를 권장합니다. reset명령어에 --hard라는 플래그가 붙는 경우 commit도 지울 수 있기 때문입니다. 잘 못 사용하다가 레포지토리를 지울 수도 있습니다. 오랜시간 걸려 만든 프로젝트를 한번에 날리게 되는 것입니다.
따라서 reset명령어를 사용하는 경우에는 정말 신중하게 사용하는 것을 권장합니다.
$ git commit --amend
위 명령어를 사용하면 가장 최신의 commit메세지를 변경할 수 있습니다. $ git commit --amend
명령어를 통해 commit메세지를 수정한 후 git status를 이용해 상태를 확인해보면, commit메세지를 수정했다는 이력도 남기 때문에 안전하게 사용할 수 있습니다.
물론, 최근 commit메세지 뿐만 아니라 이전 commit메세지를 수정할 수도 있습니다. (rebase
명령어 사용) 하지만 사용하지 않고, commit메세지를 작성할 때 항상 신중하게 작성을 하는 습관을 들이는 것을 권장합니다.
reset
명령어를 사용하면 commit메세지를 삭제할 수 있습니다. reset명령어의 경우 혼자 프로젝트를 진행하는 경우 문제가 되지 않지만, 협업시 큰 문제를 가지고 올 수 있습니다.
내 로컬레포에서는 commit메세지가 사라지더라도 다른 사람들의 레포에서는 사라지지 않기 때문에 협업 시 다른 cloned repo에 존재하던 commit log로 인해 파일이 살아나거나, 과거 이력이 깔끔히 사라져 commit log tracking이 힘들지게 됩니다.
따라서 reset명령어보다는 revert명령어를 통해 잘못한 이력도 commit으로 박제하고 수정한 이력을 남기는 것이 좋습니다.
가장 최근 3개의 커밋을 수정
$ git revert --no-commit HEAD~3..
$ git commit
$ git push origin <branch>
revert를 통해 commit 메세지를 삭제하는 경우 삭제 이력이 남길 수 있습니다. 즉, commit 메세지를 만들었던 내역과 삭제를 한 내역이 모두 남기 때문에 협업 시 혼란을 야기하는 것을 방지할 수 있습니다.
--no-commit플래그를 사용해 3개의 커밋을 되돌아가 한번에 수정을 할 수 있습니다.