기사 디렉토리
1. 문제 소개
git을 사용하여 프로젝트 파일을 원격 창고로 전송할 때 다음과 같은 네트워크 연결 오류가 자주 발생합니다.
fatal: unable to access 'https://github.com/biluko/RegionCLIP.git/': Failed to connect to github.com port 443 after 21106 ms: Timed out
다른 예시:
error: failed to push some refs to 'https://github.com/biluko/RegionCLIP.git'
hint: Updates were rejected because the tip of your current branch is behind
hint: its remote counterpart. Integrate the remote changes (e.g.
hint: 'git pull ...') before pushing again.
hint: See the 'Note about fast-forwards' in 'git push --help' for details.
다른 예시:
fatal: unable to access 'https://github.com/biluko/RegionCLIP.git/': OpenSSL SSL_read: Connection was reset, errno 10054
이런 비슷한 경우가 많은데 매번 답답하네요 오늘 오후에 5번이나 업로드를 시도했는데 네트워크 문제로 모두 실패했습니다 이 문제를 해결하기 위해 안정적으로 올릴 수 있는 방법을 찾고 싶었습니다.
다음은 가장 원활한 업로드 프로세스입니다.
둘, 완전한 과정
2.1 초기화
명령줄 터미널 또는 Git Bash를 열고 Git 리포지토리로 초기화하려는 디렉터리로 변경한 후 다음 명령을 실행합니다.
git init
Git은 현재 디렉토리에 ".git"이라는 하위 디렉토리를 만들고 Git 리포지토리로 설정합니다. 이 시점에서 버전 제어를 위해 Git을 사용할 수 있습니다.
모두 제대로 진행되면 다음과 유사한 출력이 표시됩니다.
Initialized empty Git repository in /path/to/your/repository/.git/
이 시점에서 해당 폴더를 살펴보겠습니다.
2.2 원격 웨어하우스에서 최신 변경 사항을 가져와서 현재 브랜치에 병합
git pull 명령은 원격 저장소에서 최신 변경 사항을 가져와서 현재 브랜치에 병합하는 데 사용됩니다. 다음 명령을 사용하여 원격 리포지토리 https://github.com/biluko/RegionCLIP.git에서 로컬 브랜치로 변경 사항을 가져올 수 있습니다.
git pull https://github.com/biluko/RegionCLIP.git
이 명령을 실행하기 전에 Git 리포지토리(git init로 초기화할 수 있음)를 초기화했는지 확인하십시오. 또한 원격 저장소에 액세스할 수 있는 적절한 액세스 권한이 있는지 확인하십시오.
git pull 명령을 실행한 후 Git은 원격 저장소의 최신 변경 사항을 현재 브랜치에 자동으로 병합하려고 시도합니다. 충돌이 있는 경우 수동으로 충돌을 해결하고 커밋해야 합니다. 병합이 완료되면 로컬 분기에 원격 저장소의 최신 변경 사항이 포함됩니다.
이전에 원격 저장소와 연결한 경우(git remote add 명령 사용) URL 대신 원격 저장소의 별칭을 직접 사용할 수 있습니다.
git pull origin
origin을 사용 중인 원격 별칭으로 바꿉니다.
그러나이 명령을 사용하면 다음과 같은 오류가 보고됩니다.
2.3 원격 웨어하우스의 SSH URL
위의 HTTP 프로토콜을 사용하면 네트워크 불안정이 발생하므로 방법을 개선하여 SSH URL을 사용하려고 합니다.
git pull git@github.com:biluko/RegionCLIP.git
git pull [email protected]:biluko/RegionCLIP.git은 SSH 프로토콜을 사용하여 원격 웨어하우스에서 업데이트를 가져오는 명령입니다. 이 명령은 SSH URL [email protected]:biluko/RegionCLIP.git에 해당하는 원격 웨어하우스에서 최신 변경 사항을 가져와 현재 브랜치에 병합하려고 시도합니다.
SSH 키를 올바르게 구성하고 GitHub 계정에 추가했는지 확인하십시오.
이 명령을 실행하면 Git은 인증을 위해 구성한 SSH 키를 사용하여 SSH 프로토콜을 사용하여 통신합니다. 모든 것이 정상이면 Git은 원격 저장소에서 최신 변경 사항을 가져와 현재 브랜치에 병합하려고 시도합니다.
이 명령을 실행하기 전에 올바른 원격 웨어하우스 주소를 초기화하고 설정하기 위해 로컬 Git 웨어하우스 디렉토리에서 git init 명령을 실행했는지 확인하십시오.
오류가 발생하면 SSH 키가 올바르게 구성되어 있고 원격 리포지토리에 액세스할 수 있는지 확인하십시오.
비고:
git pull [email protected]:biluko/RegionCLIP.git 명령을 실행할 때 원격 저장소의 SSH URL을 사용했습니다. 그러나 이 명령의 구문이 완전하지 않아 별칭(원격) 및 원격 웨어하우스의 분기 이름이 누락되었습니다.
올바른 구문은 다음과 같아야 합니다.
git pull <remote> <branch>
원격 리포지토리의 별칭과 가져오려는 브랜치의 이름으로 바꿔야 합니다. 원격 저장소에 별칭을 추가하지 않은 경우 git remote add 명령을 사용하여 원격 저장소를 추가할 수 있습니다.
git remote add origin git@github.com:biluko/RegionCLIP.git
이렇게 하면 원격 저장소의 별칭이 origin으로 설정됩니다.
그런 다음 다음 명령을 사용하여 원격 저장소의 지정된 분기에 대한 최신 변경 사항을 가져올 수 있습니다.
git pull origin <branch>
<branch>가져오려는 분기의 이름으로 바꾸 십시오 .
로컬에서 초기화(git init 명령 사용)하고 올바른 SSH 키를 구성하여 원격 리포지토리에 액세스할 수 있도록 해야 합니다.
2.4 준비 영역에 추가
git add . 명령은 후속 제출을 위해 현재 디렉터리의 모든 변경 사항(새로 추가된 파일 및 수정된 파일 포함)을 Git의 임시 저장소 영역에 추가하는 데 사용됩니다.
git add . 명령을 실행한 후 Git은 현재 디렉터리와 하위 디렉터리의 모든 파일을 검색하고 임시 저장소 영역에 추가합니다. 즉, Git은 이러한 파일의 변경 사항을 추적하고 커밋 작업을 수행할 때 커밋에 포함합니다.
git add . 명령은 추적되지 않은 파일을 포함하여 현재 디렉터리와 해당 하위 디렉터리의 모든 파일을 스테이징 영역에 추가합니다. 새로 추가되거나 추적되지 않은 파일이 아닌 수정된 파일만 스테이징 영역에 추가하려면 git add -u 명령을 사용할 수 있습니다.
git add . 또는 git add -u 실행 후 git status 명령을 사용하여 임시 저장 영역의 상태를 보고 추가된 파일이 올바른지 확인할 수 있습니다.
커밋을 실행하기 전에 git commit 명령을 실행하여 임시 저장 영역의 변경 사항을 로컬 웨어하우스에 제출해야 할 수도 있습니다.
git add .
위의 결과는 표시된 결과 중 일부일 뿐입니다!
2.5 제출 작업
git commit -m "RegionCLIP"
git commit -m "RegionCLIP"은 작업을 제출하는 명령이며, 임시 저장 영역의 변경 사항을 로컬 창고에 제출하고 제출에 설명 제출 정보를 추가합니다.
이 명령을 실행할 때 git add 명령을 실행하여 제출할 파일을 임시 저장 영역에 추가했는지 확인하십시오.
명령의 다양한 부분을 설명하려면 다음을 수행하십시오.
git commit: 커밋 작업을 나타냅니다.
-m "RegionCLIP": 커밋 설명으로 -m 매개변수 다음의 큰따옴표 내용을 사용합니다. "RegionCLIP"을 보다 구체적인 제출 정보로 대체하여 이 제출 내용을 설명할 수 있습니다.
git commit -m "RegionCLIP" 명령을 실행한 후 Git은 임시 저장 영역의 변경 사항을 로컬 창고에 제출하고 지정된 제출 정보를 제출에 할당합니다.
이렇게 하면 로컬 리포지토리에만 커밋이 저장되고 원격 리포지토리와 동기화되지 않습니다. 로컬 커밋을 원격 웨어하우스로 푸시하려면 git push 명령을 실행하세요.
커밋 작업을 수행하면 스테이징된 파일의 변경 사항을 버전 기록에 기록하고 이 변경 사항에 대한 설명 정보를 제공할 수 있습니다. 이는 프로젝트 개발을 추적하고 팀원과 협업하는 데 유용합니다.
2.6 원격 웨어하우스를 Git 웨어하우스의 원격 별칭으로 추가
git remote add origin git@github.com:biluko/RegionCLIP.git
git remote add origin [email protected]:biluko/RegionCLIP.git은 원격 웨어하우스를 Git 웨어하우스의 원격 별칭(remote alias)으로 추가하는 것입니다. 이 명령을 사용하여 origin이라는 원격 별칭을 원격 리포지토리의 URL [email protected]:biluko/RegionCLIP.git과 연결합니다.
명령의 다양한 부분을 설명하려면 다음을 수행하십시오.
git remote add: 원격 별칭을 추가하는 작업을 나타냅니다.
origin: 원격 창고에 부여한 별칭이며 필요에 따라 의미 있는 이름을 선택할 수 있습니다. 일반적으로 기본 원격 웨어하우스 별칭으로 origin을 사용합니다.
[email protected]:biluko/RegionCLIP.git: 원격 웨어하우스의 SSH URL입니다.
git remote add origin [email protected]:biluko/RegionCLIP.git 명령을 실행하면 origin이라는 원격 별칭을 지정된 원격 저장소의 URL과 연결된 로컬 Git 저장소에 추가하게 됩니다.
원격 별칭을 추가한 후 원본 별칭을 사용하여 원격 웨어하우스를 참조할 수 있으므로 푸시 및 풀과 같은 원격 웨어하우스와의 대화형 작업에 편리합니다. git push origin <branch>예를 들어 로컬 분기를 원본 원격 리포지토리로 푸시하는 데 사용할 수 있습니다 .
이 명령을 실행하기 전에 Git 리포지토리를 초기화하고(git init를 사용하여 초기화) 올바른 SSH 키를 구성하여 원격 리포지토리에 액세스할 수 있는지 확인하십시오.
2.7 원격 창고로 푸시
git push origin master
git push origin master 로컬 마스터 브랜치를 origin이라는 원격 리포지토리로 푸시하는 명령입니다.
명령의 다양한 부분을 설명하려면 다음을 수행하십시오.
git push: 푸시 작업을 나타냅니다.
origin: 원격 웨어하우스의 URL을 참조하는 데 사용되는 원격 웨어하우스에 부여하는 별칭입니다. git remote add 명령을 실행할 때 일반적으로 원격 웨어하우스의 별칭을 origin으로 설정합니다.
master: 푸시할 로컬 브랜치의 이름을 나타냅니다. 이 경우 로컬 마스터 브랜치를 원격 리포지토리로 푸시합니다.
git push origin master 명령을 실행하면 Git은 로컬 마스터 브랜치의 커밋을 origin이라는 원격 리포지토리로 푸시합니다.
원격 웨어하우스에 마스터 브랜치를 생성하지 않은 경우 Git은 새 마스터 브랜치를 생성하고 로컬 마스터 브랜치의 커밋을 원격 웨어하우스로 푸시합니다.
이 명령을 실행하기 전에 원격 리포지토리의 URL을 원격 별칭으로 추가했는지(git remote add 명령 사용), 해당 원격 리포지토리에 푸시할 수 있는 충분한 권한이 있는지 확인하세요.
푸시 작업을 수행하기 전에 git commit을 수행하여 로컬 변경 사항을 로컬 웨어하우스에 제출하는 것이 좋습니다. 이렇게 하면 최신 변경 사항이 적용됩니다.
2.8 최종 결과
3. HTTP와 SSH의 이해
3.1 둘의 차이점
GitHub의 HTTP 및 SSH는 원격 리포지토리와 통신하고 코드를 밀고 당기는 두 가지 프로토콜입니다. 그들 사이의 주요 차이점은 다음과 같습니다.
3.1.1 인증 방식
HTTP는 사용자 이름과 암호 기반 인증을 사용하는 반면 SSH는 인증을 위해 공개 및 개인 키 쌍을 사용합니다.
- HTTP: HTTP 프로토콜을 사용하는 경우 인증을 위해 GitHub 사용자 이름과 암호를 제공해야 합니다. 즉, 원격 저장소와 통신할 때마다 비밀번호를 입력해야 합니다.
- SSH: SSH 프로토콜을 사용하는 경우 SSH 키 쌍(공용 및 개인)을 생성해야 합니다. 공개 키를 GitHub 계정에 추가하고 비공개 키는 로컬에 보관합니다. 원격 저장소와 통신할 때마다 인증을 위해 개인 키를 사용하십시오. 이 방법은 통신할 때마다 암호를 입력할 필요가 없기 때문에 더 안전합니다.
3.1.2 전송 프로토콜
HTTP는 데이터 전송에 HTTPS 프로토콜을 사용하고 SSH는 데이터 전송에 SSH 프로토콜을 사용합니다.
- HTTP: 데이터 전송에 HTTPS를 사용하고 암호화 및 인증을 통해 통신 보안을 보장합니다.
- SSH: 데이터 전송에 SSH 프로토콜을 사용하며 암호화 및 인증 기능도 있으며 공개 및 개인 키를 사용하여 통신 보안을 보장합니다.
3.1.3 창고 복제 방법
원격 리포지토리를 복제할 때 HTTP 또는 SSH를 사용하도록 선택할 수 있습니다.
- HTTP: HTTP를 사용하여 복제할 때 저장소의 HTTPS URL을 사용할 수 있습니다.
git clone https://github.com/username/repository.git
- SSH: SSH를 사용하여 복제할 때 저장소의 SSH URL을 사용할 수 있습니다.
git clone git@github.com:username/repository.git
전반적으로 SSH 프로토콜은 인증에 공개 및 개인 키를 사용하고 데이터 전송도 암호화하기 때문에 상대적으로 더 안전합니다. HTTP 프로토콜은 더 간단하며 높은 보안이 필요하지 않은 일부 시나리오에 적합합니다. 사용하기로 선택한 프로토콜은 기본 설정과 특정 요구 사항에 따라 다릅니다.
3.2 SSH 네트워크가 HTTP보다 안정적인 이유는 무엇입니까?
HTTP는 네트워크 통신 중에 다양한 네트워크 오류가 발생할 수 있으며 SSH가 상대적으로 안정적인 이유는 다음과 같습니다.
- 전송 프로토콜 차이점: HTTP는 텍스트 기반 프로토콜을 사용하고 SSH는 이진 프로토콜을 사용합니다. 텍스트 프로토콜과 비교할 때 바이너리 프로토콜은 전송 효율이 더 높고 데이터 전송이 더 안정적입니다.
- 긴 연결 및 짧은 연결: HTTP는 짧은 연결을 기반으로 하는 프로토콜입니다. 각 요청은 연결을 설정하고 종료해야 합니다. 이러한 빈번한 연결 설정 및 종료 작업은 네트워크 전송의 오버헤드 및 지연을 증가시킵니다. 그러나 SSH는 긴 연결을 설정하므로 연결 설정 및 종료 횟수가 줄어들고 데이터 전송의 효율성이 향상됩니다.
- 암호화 및 인증 메커니즘: SSH는 ID 인증 및 데이터 암호화를 위해 공개 및 개인 키 쌍을 사용합니다.이 메커니즘은 더 높은 보안 및 데이터 무결성을 제공하고 중간자 공격 및 데이터 변조를 효과적으로 방지합니다. HTTP의 인증 메커니즘은 사용자 이름과 암호에만 의존하는 비교적 단순하며 보안이 약합니다.
- 포트 제한: 일부 네트워크 환경에서는 특정 네트워크 포트에 대한 제한이 있을 수 있으며 SSH는 기본적으로 덜 제한적인 포트 22를 사용합니다. HTTP에서 사용하는 기본 포트는 80 또는 443이며 네트워크 환경 및 방화벽 설정에 따라 제한되거나 차단될 수 있습니다.
요약하면 SSH는 HTTP보다 안정성과 보안성이 높으며 특히 불안정한 네트워크, 높은 보안 요구 사항 또는 더 많은 제한이 있는 환경에서 보다 안정적인 원격 작업 및 데이터 전송을 위해 SSH 통신을 사용할 수 있습니다.