Git은 소프트웨어를 개발하는 동안 소스 코드의 변경 사항을 추적하는 데 주로 사용되는 분산 버전 제어 시스템입니다. GitHub는 Git 기반 버전 관리를 위한 온라인 호스팅 서비스입니다. 이 두 서비스 모두 소프트웨어 개발에 널리 사용됩니다. 그러나 최근 사용자가 "git" 명령을 실행할 수 없다는 보고가 많이 있습니다.
당신은 혼자가 아닙니다. 이전에 본 적이 없는 오류가 발생할 때까지 Git 워크플로를 마스터했다고 생각합니다. Git으로 작업하는 동안 당혹스럽고 때로는 위협적인 오류 메시지를 만나는 것은 거의 피할 수 없는 일입니다. 따라서 가장 먼저 기억해야 할 것은 다른 Git 사용자가 귀하의 처지에 관련될 수 있다는 것입니다.
Git 사용자는 이 성가신 Git Fatal:'Origin'이 git 저장소가 아닌 것으로 보입니다. 오류. 그리고 어디를 봐야할지 모를 경우 근본 원인을 찾는 것이 어려울 수 있습니다. 하지만 Git을 포기하기 전에 이 오류의 원인, 진단 방법, 향후 방지 방법을 빠르게 배울 수 있습니다.
전문가 팁:Mac에서 성능 문제, 정크 파일, 유해한 앱 및 보안 위협을 검사하십시오.
시스템 문제를 일으키거나 성능을 저하시킬 수 있습니다.
치명적인 것:'Origin'은 git 저장소가 아닌 것으로 보입니다. 문제?
git init 명령은 새 Git 리포지토리 생성을 시작합니다. 이 명령은 단순히 폴더를 Git 리포지토리로 설정합니다. 한 저장소를 다른 저장소에 연결하지 않습니다.
반면에 git clone 명령은 로컬 저장소를 원격 저장소에 연결합니다. Git은 프로젝트 코드의 출처를 알고 복제한 위치를 사용하여 커밋을 푸시할 위치를 예측하기 때문입니다.
새 리포지토리를 만들고 코드를 푸시해야 하는 위치에 대해 먼저 Git에 지시하지 않고 코드를 커밋하려고 하면 "치명적인:'origin'이 git 리포지토리로 표시되지 않습니다" 오류가 표시됩니다.
Git 저장소란 무엇입니까?
GIT 리포지토리에는 프로젝트의 다양한 버전에서 가져온 파일 모음이 포함되어 있습니다. 이러한 파일은 파일 내용에 대한 추가 업데이트 및 수정을 위해 저장소에서 사용자의 로컬 서버로 가져옵니다. VCS 또는 버전 제어 시스템은 이러한 버전을 생성하고 저장소라고 하는 위치에 저장하는 데 사용됩니다. 복제는 다양한 Git 도구를 사용하여 기존 Git 저장소에서 콘텐츠를 복사하는 프로세스입니다.
복제 프로세스가 완료되면 사용자는 자신의 로컬 시스템에서 전체 저장소를 받습니다. 복제가 완료되면 Git은 저장소에 대한 모든 향후 작업이 사용자로 수행될 것이라고 가정합니다. 사용자는 새 리포지토리를 생성하거나 기존 리포지토리를 삭제할 수도 있습니다. 저장소를 삭제하는 가장 간단한 방법은 저장소의 폴더를 삭제하는 것입니다.
Git 리포지토리로 작업할 때 기본적으로 Git 프로젝트로 구성된 디렉터리로 작업하게 됩니다. Git은 로컬 컴퓨터나 원격 서버에 거의 모든 디렉토리를 만드는 데 사용할 수 있습니다.
Git 프로젝트가 명령을 수락하지 않는 이유 또는 원격 저장소가 인식되지 않는 이유를 올바르게 진단하려면 먼저 Git이 저장소와 상호 작용을 시도할 때 찾는 항목을 이해해야 합니다.
로컬이든 원격이든 모든 디렉토리는 Git으로 초기화되어야 합니다. 즉, git init 명령을 실행해야 합니다.
로컬 디렉터리에서 이 명령을 실행하면 해당 디렉터리가 Git 리포지토리로 변환됩니다. 명령이 성공했음을 나타내는 성공 메시지가 나타납니다. 또한 모든 Git 저장소에는 .git 디렉토리가 있습니다. 중요한 파일과 참조 포인트가 저장되는 곳입니다.
반면에 –bare를 사용하는 것이 일반적입니다. 원격 저장소를 초기화할 때 옵션:git init –bare
이것은 본질적으로 Git으로 초기화되고 전송된 Git 명령을 수신하고 실행할 수 있는 빈 디렉토리인 "베어" 리포지토리를 생성합니다. 베어 리포지토리는 한 명 이상의 Git 사용자가 프로젝트를 복제, 푸시 및 풀할 수 있는 훌륭한 "허브"입니다.
Git 리포지토리는 원격 리포지토리에 자동으로 연결되지 않습니다. 먼저 위치를 지정하지 않고 원격 저장소에 변경 사항을 푸시하려고 하면 "치명적인:'origin'은 git 저장소가 아닌 것으로 보입니다" 오류가 발생합니다.
치명적인 'Origin'이 git 저장소로 보이지 않는 이유 오류?
Git 리포지토리로 인식되지 않는 디렉터리에서 복제하거나 다른 명령을 실행하려고 하면 "치명적인:'origin'이 git 리포지토리로 표시되지 않습니다."라는 오류가 발생합니다. 디렉토리 또는 원격 파일 경로가 Git을 초기화하지 않았거나 활성 저장소로 액세스하려는 파일 경로가 올바르지 않을 수 있습니다. 이 오류를 유발하는 요인은 다음과 같습니다.
- Missing Origin:"Origin" 필드가 누락된 경우 이 오류가 발생합니다. "Github-Fork"에 대한 참조가 없으면 일부 명령이 제대로 작동하지 않습니다.
- 잘못된 URL:경우에 따라 애플리케이션에서 설정한 URL 구성이 올바르지 않을 수 있으므로 변경해야 합니다. 그 결과 일부 명령이 제대로 작동하지 않을 수 있습니다.
Git은 기본적으로 작업하려는 리포지토리를 Git 프로젝트로 인식할 수 없음을 나타냅니다. 그렇기 때문에 모든 것이 올바르게 설정되었다고 생각되면 오류가 실망스러울 수 있습니다. 하지만 걱정하지 마세요. 단순한 오타로 인해 오류가 발생했을 수 있습니다.
문제의 본질에 대한 기본적인 이해를 돕기 위해 이제 솔루션에 접근할 것입니다. 이 오류를 진단하고 치료하기 위해 무엇을 할 수 있는지 알아보려면 계속 읽으십시오.
치명적인 문제 해결 방법:'Origin/Master'가 git 저장소가 아닌 것 같습니다' 오류
이 오류가 발생하면 방해가 되고 시간이 오래 걸리므로 답답할 수 있습니다. "치명적인 출처는 git 리포지토리가 아닌 것 같습니다"와 같은 결함이 발생하지 않도록 하는 한 가지 방법은 Outbyte MacAries를 사용하여 정기적으로 기기를 스캔하는 것입니다. 이 도구는 사소한 문제가 누적되어 완전한 혼란으로 바뀌는 것을 방지합니다.
그러나 이 오류가 발생하면 다음 단계를 통해 쉽게 해결할 수 있습니다.
수정 #1:Origin 추가
git init 명령으로 생성된 새로 생성된 git 리포지토리에 커밋하려고 하면 "치명적인:'origin'이 git 리포지토리로 표시되지 않습니다" 오류가 발생합니다. 이것은 git init가 로컬 저장소를 원격 저장소에 연결하지 않기 때문입니다. 다음을 입력하여 테스트할 수 있습니다. git remote -v
origin이라는 원격 저장소가 없는 경우 , 아래 해결 방법에 따라 수동으로 추가해야 합니다.
- “명령 " 및 "스페이스 " 버튼을 동시에 누릅니다. 그러면 Spotlight가 열립니다.
- “터미널 입력 "를 누르고 "Return을 누릅니다. .”
- 다음 명령을 입력하고 "Return " 키:git remote -v
- "Origin이라는 원격 저장소가 있는지 확인 "가 나열됩니다.
- 없으면 "원점"이 누락된 것입니다.
- 다음 명령을 사용하여 Origin을 추가합니다. git remote add origin url/to/your/fork
문제가 여전히 존재하는지 확인하십시오.
수정 #2:원격 저장소의 파일 경로를 확인하십시오.
원격 리포지토리에서 콘텐츠를 복제, 푸시 또는 풀하려고 할 때 Git 사용자는 "원본이 치명적인 git 리포지토리로 표시되지 않습니다" 오류가 자주 발생합니다. 원격 저장소의 파일 경로를 다시 확인하십시오. 이에 대한 몇 가지 접근 방식이 있습니다.
복제하는 경우 필요한 저장소 액세스 권한이 있는지 다시 확인하십시오. GitHub에서 공개 리포지토리를 복제하지 않는 한 SSH를 통해 연결하고 있을 것입니다. 마찬가지로 복제 명령의 구문을 검사해야 합니다. 다음은 HTTP를 통해 저장소에 연결하는 기본 복제 명령의 예입니다. git clone https://github.com/WordPress/WordPress.git
선호하는 터미널 에뮬레이터에서 이 명령을 실행하면 모든 WordPress 코어 파일이 포함된 "WordPress"라는 디렉터리가 생성됩니다. 여기에는 .git 디렉토리와 전체 프로젝트 기록도 포함됩니다. 결과적으로 이 디렉토리는 완전히 작동하는 로컬 git 저장소가 됩니다. 또한 원격 저장소 정보(GitHub)가 올바르게 설정됩니다.
그러나 HTTP 액세스 권한이 없는 개인 서버와 통신하는 경우 적절한 권한이 있는 서버 사용자를 포함하도록 이 구문을 수정해야 합니다. 그렇기 때문에 비공개 Git 서버를 구성할 때 저장소 액세스 권한이 있는 특별한 "Git" 사용자를 만드는 것이 좋습니다. git clone [email protected]:/home/user/production.git
GitHub의 HTTP 변형과 달리 이 복제 URL에는 [email protected]이 포함됩니다. 이 경우 "사용자"는 서버의 Git 저장소에 대한 액세스 및 권한이 있는 서버 사용자입니다. 접속하려는 서버의 호스트 이름, 도메인 이름 또는 IP 주소가 대상입니다. 사용자 및 서버 선언은 파일 경로와 콜론(:)으로 구분됩니다.
이 경우 파일 경로가 중요합니다. 저장소의 정확한 위치와 이름은 파일 경로로 표시됩니다. 앞의 예에서 저장소는 production.git이라는 디렉토리입니다.
저장소 디렉토리에는 항상 .git 확장자를 사용하십시오. Production.git 디렉토리는 사용자의 홈 디렉토리인 /home/user에 있습니다.
이 구문을 정확하게 복제해야 합니다. 그렇지 않으면 "치명적인:'origin'이 git 저장소로 표시되지 않습니다" 오류가 표시됩니다.
수정 #3:Origin을 Master로 변경
마스터에서 가져오려는 경우 원격 리포지토리를 추가하거나 제거하기 전에 먼저 원본을 마스터로 변경해야 합니다. 결과적으로 이 단계에서는 Origin을 Master로 변경합니다. 이렇게 하려면:
- “명령 " 및 "스페이스 " 버튼을 동시에 누릅니다. 그러면 Spotlight가 열립니다.
- “터미널 입력 "를 누르고 "Return을 누릅니다. .”
- 여기에 명령을 입력하여 Origin을 마스터로 변경합니다. git pull origin master
"fatal:'origin'이 git 저장소가 아닌 것 같습니다" 문제가 사라졌는지 확인합니다.
수정 #4:손상된 HEAD 파일 수정
위의 문제 해결 단계로 문제가 해결되지 않으면 HEAD 파일에 문제가 있을 수 있습니다. 이 파일에는 현재 분기에 대한 포인터 역할을 하는 한 줄이 포함되어 있습니다.
Git을 처음 사용하는 경우 "분기"라는 용어도 생소할 수 있습니다. 분기는 프로젝트 변경 사항을 테스트하는 데 사용할 수 있는 저장소 버전입니다. 모든 리포지토리에는 진실의 소스 역할을 하는 메인 브랜치가 있으며 프로덕션에 배포되는 버전이어야 합니다. 기본 분기를 변경하려는 경우 프로젝트 또는 분기의 별도 버전을 만들어 변경 사항을 테스트할 수 있습니다. Git은 새 분기를 만들 때 현재 작업 분기를 반영하도록 HEAD 파일을 업데이트합니다.
그러나 경우에 따라 HEAD 파일이 손상되어 치명적:'Origin'이 Git 저장소가 아닌 것으로 나타납니다 오류. HEAD 파일을 확인하려면 cat .git/HEAD를 사용할 수 있습니다. 내용을 인쇄하는 명령입니다.
이 명령을 실행하면 현재 분기의 이름이 표시되어야 합니다. 작업 중인 현재 분기가 포함되어 있지 않으면 파일을 업데이트해야 합니다. 다음 명령을 입력하면 됩니다. echo 'ref:refs/heads/
마무리
Fatal:'Origin'은 Git Repository 오류가 아닌 것으로 보입니다. 이 문제가 발생하면 Git이 현재 작업 디렉토리가 추적되지 않는다는 알림을 시도한다는 점을 염두에 두십시오. 따라서 아래에 요약된 이 문서에 요약된 기본 단계를 따르세요.
- Origin을 수동으로 추가합니다.
- 디렉토리 이름을 올바르게 입력했는지 확인하세요.
- 리포지토리를 올바르게 생성했는지 확인합니다. 디렉토리에 .git 저장소가 없으면 git init를 사용하세요. 저장소를 올바르게 초기화하거나 기존 저장소를 복제합니다.
- 현재 분기의 HEAD 파일에 올바른 정보가 포함되어 있는지 확인하십시오. 그렇지 않은 경우 파일의 내용을 ref:refs/heads/
으로 변경합니다.
위에 설명된 문제 해결 단계를 따르면 거의 모든 경우에 몇 분 안에 오류를 해결할 수 있습니다.