ICT CoC 멤버가 자유롭게 소통할 수 있는 커뮤니티입니다.
ICT CoC 멤버가 자유롭게
소통할 수 있는 커뮤니티입니다.
| 제목 | 깃 사용자가 가장 흔히 저지르는 6가지 실수와 대처 방법 |
|---|---|
| 날짜 | 2020-01-31 |
| 첨부파일 | 없음 |
|
개발자들이 깃(Git)과 같은 소스 제어 시스템을 사용하는 중요한 이유 중 하나는 각종 재난을 최대한 방지하기 위해서다. 단순하게는 실수로 파일 하나를 삭제하는 경우부터 여러 파일을 잘못 변경하는 실수까지 여러 가지 사고가 일어날 수 있지만, 깃이 있으면 간단히 되돌릴 수 있다. 이중에는 경험 많은 깃 사용자라 해도 되돌리기가 어려운 실수도 있다. 설령 프로그래머들이 듣더라고 깜짝 놀랄 최악의 실수를 저질렀다 해도 패닉에 빠지지 않고 신중하게 대처하면 롤백이 가능하다. 깃에서 저지를 수 있는 큰 실수와 함께 이를 되돌리고 애초에 방지하기 위한 팁을 소개한다. 목록 마지막으로 갈수록 더 심각한 사고다. 깃 실수 1: 마지막 커밋에 깜박하고 변경을 추가하지 않았을 때깃 실수 중에서 복구하기가 가장 쉬운 실수에 속한다. 예를 들어 로컬 분기에 작업을 커밋한 이후에 필요한 일부 파일을 스테이징하지 않았다는 사실을 알게 되거나, 커밋 메시지에 세부 정보를 추가하지 않았다는 것을 뒤늦게 깨닫는 경우다.걱정할 필요 없다. 먼저 스테이징할 새로운 변경 사항이 있다면 스테이징을 한다. 그 다음 git commit --amend를 입력해서 커밋 메시지를 편집한다. Esc를 누른 다음 :xq를 입력해서 저장하고 편집기에서 나온다. (기본 깃 편집기의 특징을 잘 모르는 깃 초보자는 이 마지막 단계에서 당황하는 경우가 많다.)파일만 변경하고 커밋 메시지를 수정할 필요는 없다면 git commit --amend --no-edit를 사용해서 파일을 추가하고 메시지 편집 과정을 생략할 수 있다.이와 같은 종류의 실수를 피하려면 깃에서 커밋하는 방법을 바꿔야 한다. 증분적 리비전을 추적하기 위해 수시로 작게 커밋하는 작업은 임시 분기에서 한다. 그리고 이 과정에서 중요한 변경은 git commit 명령을 하는 시점까지 기다리지 말고 다른 곳에 문서로 작성한다. 그런 다음 중요한 이정표에 도달하면 임시 분기에서 git merge --squash를 사용해서 정규 작업 분기에 하나의 깔끔한 커밋으로 결과를 저장하고, 앞서 작성한 문서를 커밋 메시지로 사용한다.깃 실수 2: 로컬 마스터에 변경을 커밋했을 때이것도 흔한 실수다. 일단의 변경을 충실하게 커밋하긴 했는데, 원래 커밋해야 할 새 분기 또는 중대한 변경을 위해 따로 마련해둔 dev 분기가 아닌 마스터 분기에 커밋하는 경우다.방법은 있다. 다음의 3가지 명령으로 실수를 되돌릴 수 있다. git branch new-branchgit reset HEAD~ --hardgit checkout new-branch첫 번째 명령은 작업할 새 분기(new)를 만든다. 두 번째 명령은 주 분기를 마지막 커밋 직전으로 리셋하되, 변경 사항은 new 분기에 남겨둔다. 마지막으로 변경사항이 기다리고 있는 new 분기로 전환한다. 여러 번 커밋한 경우에는 git reset HEAD~를 사용한다. 여기서 git reset 을 사용해도 된다. 이 실수를 방지하려면 코드 세션을 시작할 때마다 무조건 새 분기를 만들어(나중에 그냥 버릴 분기라 해도) 그 분기로 전환하는 습관을 들이는 것이 좋다. 깃 실수 3: 파일이나 디렉터리를 버렸을 때실수로 파일의 내용을 버린 다음 여러 번 커밋한 이후 그 사실을 알게 되는 것도 자주 일어나는 사고 중 하나다. 다행히 이 실수는 쉽게 되돌릴 수 있다.먼저 git log를 사용하거나 IDE에 내장된 깃 툴을 사용해서 파일이 수정되기 전의 커밋에 대한 해시 ID를 찾는다. 그 다음 git checkout hash_id -- /path/to/file을 사용해서 문제의 커밋에서 그 파일만 체크아웃한다. 경로는 프로젝트 루트 기준의 상대 경로여야 한다. 이렇게 하면 이전 버전의 파일이 프로젝트의 스테이징 영역에 생성된다.단순히 n번 커밋 전으로 되돌아가려면 해시 ID도 필요 없고 git checkout HEAD~ 명령만 입력하면 된다. 파일의 전체 디렉터리를 체크아웃하려면 파일 경로에 깃의 와일드카드 형식을 사용한다. 예를 들어 git checkout HEAD~1 -- ./src/**를 입력하면 한 커밋 전으로 되돌아가서 프로젝트 루트에 있는 /src 디렉터리의 모든 파일을 복구한다.깃 실수 4: 실수로 분기를 삭제했을 때이제 우리 모두가 두려워하는 시나리오, 리포지토리에서 분기 전체를 실수로 삭제하는 경우를 보자. 상황에 따라 아주 쉽게 복구할 수도 있고, 다소 까다로울 수도 있다.먼저 git reflog를 사용해서 분기에 적용된 마지막 커밋을 찾는다. 그 다음 이 해시 ID를 사용해서 다음과 같이 새 분기를 만든다.git checkout -b restored-branch 단, 해당 분기가 이미 병합된 경우에만 복구된다. 병합되지 않은 분기를 강제로 삭제했다면, 리포지토리에서 git gc를 실행하지 않았다는 전제하에 찾을 수 있는 방법이 하나 더 있다.git fsck --full --no-reflogs --unreachable --lost-found이렇게 하면 삭제된 분기를 포함해 더 이상 도달할 수 없는 객체의 모든 커밋 해시 목록이 표시된다. 목록의 맨 밑에서부터 위로 올라오며 “unreachable commit” 항목을 찾아서 그 해시 ID를 새 분기로 복원해 문제의 분기인지 확인한다. 아니라면 위로 올라가며 다음 분기를 확인하는 과정을 반복해 복구 가능한 분기를 찾는다. 기본적으로 분기를 강제 삭제하지 않는다는 규칙에 따라야 한다. 강제 삭제할 경우 유의미한 항목이 아직 남아 있는, 병합되지 않은 분기가 파괴되는 불상사가 곧잘 발생하기 때문이다. 분기를 습관적으로 강제 삭제하고 있다면 분기 작업 습관을 바꿔야 한다는 신호다. 깃 실수 5: 필자는 전에 깃허브 리포지토리의 로컬 사본에서 작업하면서 실수로 |
|
