
우선, 오늘도 열심히 코딩을하고 github에 기록을 남기기 위해서 열심히 commit 하는 당신 정말 칭찬합니다.
👏👏👏👏👏
github는 개발자에게는 남에게 자신의 공부기록을 보여주는 일기장 같은 공간인데 기왕이면 예쁘게 보여야 하지않을까요 ? 일관성은 개발자의 덕목이기도 하지않습니까 ! (저만 그런가요)

커밋 하나가지고 너무 예민한거아니야?? 라고 생각할 수 도있습니다.
하지만 "연습은 실전처럼, 실전은 연습처럼" 모든 분야에 통용되는 말이지만 일관성에 살고 일관성에 죽는 개발분야에선 더욱이 중요하다고 생각이 드네요. 취미가아닌 그 분야를 업으로 삼을 생각을 한다면 사소한 것이라도 프로의 마음 가짐으로 임해야한다고 생각합니다.
커밋 메세지는 우리가 단순히 커밋 이력만 보고서도 현재까지 어떤 개발이 진행되었고, 어떤 커밋에서 문제가 발생했는지 등을 확인할 수 있게 됩니다. 특히나 규모가 큰 개발일수록 이 커밋 메세지는 더욱 중요해집니다.
저기 맘에 안드는 커밋 너무 불편하지않나요?? 저는 마치 저의 매끈한 얼굴피부에 작은 여드름이 난거같이 신경쓰이네요.
자, 서론이 길었네요. 이제 지우러 가봅시다.
git log

reset 하려는 위치를 파악해주고
git reset --hard 55092430422

git log
local 의 HEAD가 맘에 안드는 커밋 이전 커밋을 잘 가리키고 있습니다.
origin/main 은 아직 맘에 안드는 커밋을 가리키고 있습니다. (중요)
자 여기서 비극이 시작됩니다. (집중)
속마음 : 후 맘에 안드는 커밋을 지웠다 ㅎㅎ 이제 본격적으로 개발을 진행해볼까~
(타닥타닥) <- 코딩하는 소리
속마음 : 자 이제 내가 코딩한걸 깃에 올려볼까 ~
git add .
git commit -m "Feat : NewProductItem API 구현"
git push

에러는 해결하는 재미아니겠습니까 ㅎㅎ
자 이제부터 결론입니다.
왜 이런일이 발생했냐? (맥북 고장난거 아님. 비싼거라 돈값합니다ㅎㅎ)
orign/main, origin/HEAD (깃허브에서의 커밋log)

HEAD -> main (local에서의 커밋log)

아래의 커밋은 같지만 가장 최근의 한 커밋이 다르네요
git hist

아까 저는
'Refactor : 공백 및 사용안되는 import 정리' 라는 커밋을 기준으로 reset 을 했습니다.
그리고
'Feat : NewProductItem API 구현' 커밋을 했죠
local 에는 잘 반영되있습니다. 하지만 git 은 그 사실을 인지하지 못해요. 심지어 push를 했지만 깃허브의 커밋 줄기와 다르다고 push 를 거부합니다.
해결방법
git push -f

push 가 성공적으로 올라가는 모습입니다.
깃허브와 local의 커밋내용도 일치되었습니다.
(HEAD -> main 과 origin/main, origin/HEAD) 이 동일선상에 있으면 깃허브와 local 이 같은 상태라는 것을 뜻합니다.
cli 와 terminal 명령어중에 -f (force) 명령어는 지양하는게 좋습니다.
force. 말그대로 무식하게 힘을 쓴다는 것. 어쩔 수 없는 상황에선 힘으로 밀어버려야하지만 에초에 그상황까지 가지않도록 신중히 생각하며 명령어를 사용하기 바랍니다.
문신을 한번 새기면 지울 수 없는것처럼 깃허브 커밋도 커밋 메세지정도는 바꿀 수 있지만 커밋 내용을 바꿀순 없습니다.
push는 local의 unStaging 영역에서 Staging 영역을 거친 나의 코드가 신성한 github로 코드가 옮겨지는 명령어 이기때문에 항상 경우의 수를 생각하고 더이상 변수가 없다 싶을때 신중을 가해서 하길바랍니다.