일반적인 Git 실수 (그리고 해결 방법)

Source: Dev.to

1. main에 직접 커밋하고 기능 브랜치를 만들지 않은 경우

Fix:

git checkout -b feature-branch
git reset --soft HEAD~1
git commit

이렇게 하면 변경 사항을 잃지 않고 새 브랜치로 커밋을 옮길 수 있습니다.

2. 잘못된 브랜치에서 작업한 경우

Fix:

git checkout -b new-branch

작업 내용은 그대로 유지됩니다.

3. 커밋 메시지가 부실한 경우

Fix:

git commit -m "Fix null pointer error in user login"

좋은 커밋 메시지는 리뷰와 디버깅 시간을 절약해 줍니다.

4. 민감한 파일(예: .env)을 실수로 커밋한 경우

Fix:

git rm --cached .env
echo ".env" >> .gitignore
git commit -m "Remove env file from repo"

이미 푸시한 비밀 정보가 있다면 즉시 교체(rotate)하세요.

5. 남아있는 충돌 마커와 함께 머지 충돌이 발생한 경우

Fix: 충돌을 해결하고 >>>>>> 마커를 제거한 뒤:

git add .
git commit

6. 공유 히스토리를 재작성하지 않고 변경을 되돌려야 할 때

Fix:

git revert 

공유 히스토리는 절대 필요하지 않은 한 절대 재작성하지 마세요.

7. reset 또는 rebase 후 커밋을 잃어버린 경우

Fix:

git reflog

커밋 해시를 찾아 복구합니다:

git checkout 

Git은 거의 절대 작업을 완전히 삭제하지 않습니다.

8. 공유 브랜치에서 git push --force를 사용한 경우

Fix:

git push --force-with-lease

이 방법이 더 안전하며 다른 사람의 작업을 덮어쓰는 일을 방지합니다.

9. 불필요한 머지 커밋을 만든 경우

Fix:

git pull --rebase

히스토리를 깔끔하게 유지하고 불필요한 머지 커밋을 피할 수 있습니다.

10. 하나의 커밋에 서로 관련 없는 여러 변경을 포함한 경우

Guideline:

• 하나의 기능
• 하나의 수정
• 하나의 아이디어를 각각 별도 커밋에

Git 실수는 누구에게나 일어납니다. 중요한 것은 복구 방법을 아는 것이죠. Git이 히스토리를 어떻게 추적하는지 이해하면 스트레스가 아니라 강력한 안전망이 됩니다. 도구를 익히고, 공유 브랜치를 존중하며, 당황하지 마세요—대부분의 경우 Git은 여러분 편입니다.