|
개발자들이 깃(Git)과 같은 소스 제어 시스템을 사용하는 중요한 이유 중 하나는 각종 재난을 최대한 방지하기 위해서다. 단순하게는 실수로 파일 하나를 삭제하는 경우부터 여러 파일을 잘못 변경하는 실수까지 여러 가지 사고가 일어날 수 있지만, 깃이 있으면 간단히 되돌릴 수 있다.
이중에는 경험 많은 깃 사용자라 해도 되돌리기가 어려운 실수도 있다. 설령 프로그래머들이 듣더라고 깜짝 놀랄 최악의 실수를 저질렀다 해도 패닉에 빠지지 않고 신중하게 대처하면 롤백이 가능하다.
깃에서 저지를 수 있는 큰 실수와 함께 이를 되돌리고 애초에 방지하기 위한 팁을 소개한다. 목록 마지막으로 갈수록 더 심각한 사고다.
깃 실수 1: 마지막 커밋에 깜박하고 변경을 추가하지 않았을 때 깃 실수 중에서 복구하기가 가장 쉬운 실수에 속한다. 예를 들어 로컬 분기에 작업을 커밋한 이후에 필요한 일부 파일을 스테이징하지 않았다는 사실을 알게 되거나, 커밋 메시지에 세부 정보를 추가하지 않았다는 것을 뒤늦게 깨닫는 경우다.
걱정할 필요 없다. 먼저 스테이징할 새로운 변경 사항이 있다면 스테이징을 한다. 그 다음 git commit --amend를 입력해서 커밋 메시지를 편집한다. Esc를 누른 다음 :xq를 입력해서 저장하고 편집기에서 나온다. (기본 깃 편집기의 특징을 잘 모르는 깃 초보자는 이 마지막 단계에서 당황하는 경우가 많다.)
파일만 변경하고 커밋 메시지를 수정할 필요는 없다면 git commit --amend --no-edit를 사용해서 파일을 추가하고 메시지 편집 과정을 생략할 수 있다.
이와 같은 종류의 실수를 피하려면 깃에서 커밋하는 방법을 바꿔야 한다. 증분적 리비전을 추적하기 위해 수시로 작게 커밋하는 작업은 임시 분기에서 한다. 그리고 이 과정에서 중요한 변경은 git commit 명령을 하는 시점까지 기다리지 말고 다른 곳에 문서로 작성한다. 그런 다음 중요한 이정표에 도달하면 임시 분기에서 git merge --squash를 사용해서 정규 작업 분기에 하나의 깔끔한 커밋으로 결과를 저장하고, 앞서 작성한 문서를 커밋 메시지로 사용한다.
깃 실수 2: 로컬 마스터에 변경을 커밋했을 때 이것도 흔한 실수다. 일단의 변경을 충실하게 커밋하긴 했는데, 원래 커밋해야 할 새 분기 또는 중대한 변경을 위해 따로 마련해둔 dev 분기가 아닌 마스터 분기에 커밋하는 경우다.
방법은 있다. 다음의 3가지 명령으로 실수를 되돌릴 수 있다.
git branch new-branch git reset HEAD~ --hard git checkout new-branch
첫 번째 명령은 작업할 새 분기(new)를 만든다. 두 번째 명령은 주 분기를 마지막 커밋 직전으로 리셋하되, 변경 사항은 new 분기에 남겨둔다. 마지막으로 변경사항이 기다리고 있는 new 분기로 전환한다.
여러 번 커밋한 경우에는 git reset HEAD~ --hard를 사용한다. 여기서 은 되돌리고자 하는 커밋의 수다. 대상 커밋의 해시 ID를 알고 있다면 git reset 을 사용해도 된다. 이 대상 커밋의 해시 ID다.
이 실수를 방지하려면 코드 세션을 시작할 때마다 무조건 새 분기를 만들어(나중에 그냥 버릴 분기라 해도) 그 분기로 전환하는 습관을 들이는 것이 좋다.
깃 실수 3: 파일이나 디렉터리를 버렸을 때 실수로 파일의 내용을 버린 다음 여러 번 커밋한 이후 그 사실을 알게 되는 것도 자주 일어나는 사고 중 하나다. 다행히 이 실수는 쉽게 되돌릴 수 있다.
먼저 git log를 사용하거나 IDE에 내장된 깃 툴을 사용해서 파일이 수정되기 전의 커밋에 대한 해시 ID를 찾는다. 그 다음 git checkout hash_id -- /path/to/file을 사용해서 문제의 커밋에서 그 파일만 체크아웃한다. 경로는 프로젝트 루트 기준의 상대 경로여야 한다. 이렇게 하면 이전 버전의 파일이 프로젝트의 스테이징 영역에 생성된다.
단순히 n번 커밋 전으로 되돌아가려면 해시 ID도 필요 없고 git checkout HEAD~ -- /path/to/file 명령만 입력하면 된다. 은 되돌아갈 커밋의 수다.
파일의 전체 디렉터리를 체크아웃하려면 파일 경로에 깃의 와일드카드 형식을 사용한다. 예를 들어 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: git push로 원격 분기를 손상시켰을 때 필자는 전에 깃허브 리포지토리의 로컬 사본에서 작업하면서 실수로 --force 옵션을 붙여 마스터 분기를 원격 사본으로 푸시한 적이 있다. 그 결과 리포지토리의 공개 사본은 당시 사용할 수 없는 상태가 됐다. 큰 실수였다.
이와 같은 실수를 저지른 경우, 리포지토리가 충분히 최근에 원격 리포지토리와 동기화됐다면 원격 리포지토리 분기의 사본을 사용해서 해결할 수 있다. 다시 동기화해야 하는 분기로 전환해서 다음 명령을 실행한다.
git reset --hard /@{1}
이렇게 하면 의 사본이 의 마지막으로 동기화된 버전으로 리셋된다. 필자의 경우 master 분기였고 원격 리포지토리는 origin이었으므로 git reset --hard origin/master@{1}을 사용할 수 있었다.
그 다음 git push -f 를 사용해서 원격 리포지토리를 이전 상태로 복원한다.
이런 사고가 발생하지 않도록 하는 방법은 강제 푸시를 허용하지 않는 것이다. 다음 명령으로 원격 깃 리포지토리에서 구성할 수 있다.
git config --system receive.denyNonFastForwards true
강제 푸시를 해야 할 때도 있지만 필요할 때만 활성화하고 필요 없을 때는 끄는 것이 최선이다.
깃 실수 6: 공개 리포지토리에 비공개 정보를 커밋해버렸을 때 깃에서 최악의 실수이자 대처하기도 가장 어려운 상황, 공개 리포지토리에 민감한 데이터를 커밋했고 문제의 파일만 리포지토리에서 수술하듯 도려내야 하는 경우다. 이전 커밋으로 돌아가더라도 민감한 데이터가 발견되지 않도록 해야 하지만, 이 과정에서 다른 것은 아무것도 건드리면 안 된다.
문제의 파일이 예를 들어 6주 전에 커밋됐고 이후 다른 중요한 작업이 다량 커밋됐다면 대처하기는 더욱 어렵다. 파일이 추가되기 전으로 간단히 롤백하는 방법은 사용할 수 없다. 그렇게 하면 다른 모든 것을 잃게 된다.
다행히 출중한 깃 전문가들이 만든, 깃 리포지토리에서 부적절한 데이터를 제거하기 위한 용도의 BFG Repo-Cleaner라는 툴이 있다. BFG Repo-Cleaner를 사용하면 깃에서 특정 와일드카드와 일치하거나 특정 텍스트가 포함된 모든 파일을 제거하는 등의 일반적인 작업을 신속하게 수행할 수 있다. 원하지 않는 모든 텍스트를 목록으로 정리한 파일 하나를 만들어 전달할 수도 있다.
사실상 BFG Repo-Cleaner는 여러 단계로구성되는 git filter-branch 사용 과정을 자동화한 것이다. 수동으로 하는 편을 선호한다면 깃허브에서 제공하는 자세한 안내를 참고하면 된다. 그러나 BFG 툴을 사용하면 대다수의 일반적인 사용 사례에 대처할 수 있으며 이러한 사용 사례 중 상당수는 툴의 명령줄 옵션에 내장돼 있다. 또한 길고 복잡한 과정인 만큼 수작업으로 할 경우 자기 발등에 총을 쏘는 실수를 저지를 가능성이 매우 높다.
참고로, 다른 곳에서 동기화해야 하는 로컬 분기의 데이터를 삭제하는 경우 강제 푸시 외에는 달리 동기화할 방법이 없다. 전체 커밋 트리를 다시 써야 하므로 사실상 원격에 완전히 새로운 히스토리를 쓰는 것이다. 또한 변경 이후 다른 모든 사람의 리포지토리는 더 이상 유효하지 않으므로 이들도 다시 작성된 리포지토리의 사본을 가져오도록 해야 한다. editor@itworld.co.kr
|
