“git remote add…”와“git push origin master”는 무엇입니까?


288

Git과 Rails는 종종 Rails 3 Tutorial book첫 번째 장 에서와 같이 마술처럼 보입니다 .

git remote add origin git@github.com:peter/first_app.git
git push origin master

그리고 그것이 무엇인지에 대해 너무 많이 말하지 않고 "단지 작동"한다고 말하고 분기에 대해 이야기하기 시작합니다. 인터넷에서 검색 git remote add하면과 같은 "짧은 이름"을 추가하는 origin것으로 표시되며 URL의 별칭과 같은 이름도 가능합니다. 그리고 origin원격 저장소가 가리키는 일반적인 경로입니다. ( "원격 저장소 추가"아래의 http://git-scm.com/book/en/Git-Basics-Working-with-Remotes )

URL이 아닌 git://git@github.com/peter/first_app.git다른 구문으로 된 이유는 무엇입니까? 왜 끝나야 .git합니까? 나는 .git마지막에 사용하지 않으려 고 노력했다 . 그렇지 않다면 .git다른 무엇을 할 수 있습니까? git에서이 git@github.com망할 놈의 서버에 사용자 계정을 것 같다?

또한 왜 그렇게 장황하게 사용해야 git push origin master합니까? 기본값은 출발지와 주인이 될 수 없습니까? 나는 처음 origin master에는 필요하다는 것을 알았지 만 작은 편집과 커밋 후에 필요한 git push것만 필요했습니다 origin master. 무슨 일이 일어나고 있는지 아는 사람이 세부 사항을 줄 수 있습니까?

때로는 설명이없는 많은 마술처럼 느껴질 때가 있습니다 ... 때로는 그것을 사용하는 사람이 너무 자신감이 있고 왜 물었을 때 설명 할 수 없으며 "그 방식대로"와 같은 것으로 응답합니다. 때로는 매우 실용적이고 실용적입니다. 실용적이 나쁘지는 않지만, 무슨 일이 일어나고 있는지 알지 못할 정도로 실용적이지 않을 수 있습니다.

답변:


344

gitUNIX와 같습니다. 사용자 친화적이지만 친구에 대해 까다 롭습니다. 쉘 파이프 라인만큼 강력하고 사용자 친화적입니다.

다시 말해, 패러다임과 개념을 이해하면 UNIX 명령 줄 도구에서 기대할 수있는 것과 동일한 선명도를 갖습니다. 온라인에서 사용할 수있는 많은 훌륭한 git 자습서 중 하나를 읽으려면 시간을 내야합니다. Pro Git 책은 시작하기에 좋은 곳입니다.

첫 번째 질문에 답하십시오.

  1. 뭐가 git remote add ...

    아시다시피 git분산 버전 제어 시스템입니다. 대부분의 작업은 로컬에서 수행됩니다. 외부 세계와 의사 소통하려면 git이라는 것을 사용하십시오 remotes. 이들은 로컬 디스크에있는 저장소 이외의 저장소 push로, 다른 사람이 볼 수 pull있도록 또는 다른 사람이 변경할 수 있도록 변경할 수 있습니다. 이 명령 git remote add origin git@github.com:peter/first_app.git은에 origin위치한 새 리모콘을 만듭니다 git@github.com:peter/first_app.git. 이렇게하면 푸시 명령 origin에서 전체 URL을 입력하는 대신 푸시 할 수 있습니다 .

  2. 뭐가 git push origin master

    이것은 " master원격으로 명명 된 로컬 브랜치에 커밋을 푸시"하는 명령입니다 origin. 일단 이것이 실행되면, 당신이 원점과 마지막으로 동기화 한 모든 것들이 원격 저장소로 보내지고 다른 사람들은 그것들을 볼 수 있습니다.

이제 운송에 대해 (즉, git://) 의미합니다. 원격 저장소 URL은 다양한 유형 ( 등) file://일 수 있습니다 https://. Git은 단순히 전송 및 권한 관리를 위해 제공되는 인증 메커니즘에 의존합니다. 즉 file://, URL의 경우 UNIX 파일 권한 등이됩니다. git://스킴은 git 변경 세트를 전송하는 데 최적화 된 자체 내부 전송 프로토콜을 사용하도록 git에 요청합니다. 정확한 URL은 github이 git서버를 설정 한 방식 때문입니다 .

이제 자세한 내용입니다. 입력 한 명령이 일반적인 명령입니다. git에게 " master여기서 호출 한 분기는 호출 foo된 원격지에서 호출 된 분기의 로컬 미러 "와 같은 것을 말할 수 있습니다 bar. git speak에서 이것은 master 추적 bar/foo 합니다. 처음 복제 할 때 로컬 마스터 세트를 사용하여 호출 된 브랜치 master와 원격 호출 origin(복제 된 위치)을 얻을 수 있습니다. 이것이 설정되면 간단하게 말하면 git push됩니다. 필요한 경우 더 긴 명령을 사용할 수 있습니다 (예 : git push공식 공개 저장소 git push review master로 푸시하고 팀에서 코드를 검토하는 데 사용하는 별도의 리모컨으로 푸시하는 데 사용될 수 있음). 지점을 사용하여 지점을 추적 지점으로 설정할 수 있습니다.--set-upstreamgit branch명령 옵션 .

git (내가 사용한 대부분의 다른 앱과 달리)은 내부에서 더 잘 이해된다고 생각했습니다. 리포지토리 내부에서 데이터를 저장하고 유지 관리하는 방법을 이해하면 명령과 그 내용이 명확 해집니다. 나는 많은 git사용자 들 사이에 엘리트주의가 있다는 것에 동의 하지만, 유닉스 사용자들에게는 옛날 옛적에 시스템을 배우는 것이 가치가 있다고 생각합니다. 행운을 빕니다!


8
당신은 그 설명 전송에 대한 귀하의 단락에 메모를 추가 할 수 git@github.com:peter/first_app.git는 IS scp자식에서 SSH URL의 스타일 구문. 또 다른 점은 즉, 기본적으로의 상류 구성이 master의 동작에 영향을주지 않습니다 git push 하지 않는 한 당신이 한 push.default설정을 tracking(또는 upstream이후 버전) - 나는 혼란이 소스에 대한 블로그 게시물을했다 : longair.net/blog/2011 / 02 / 27 /…
마크 롱 에어

1
push.default업스트림 구성이 없는 해당 주석에 대한 약간의 수정은을 사용할 때 기본 원격을 찾는 데 사용 git push되지만 심판의 매핑에는 영향을 미치지 않습니다.
마크 롱 에어

1
왜 보통 "블랙 박스"가 "내부"라고 배우기 매우 쉬운 지 궁금합니다. 인터페이스는 입력 한 것과 입력 한 것을 아주 잘 정의되고 희망적으로도 간단합니다. 사용자가 신경 써야 할 것은 "인터페이스"뿐이며 실제로 내부에 무엇이 있는지 알 필요는 없습니다. 사용자가 특별한 구현 방법을 더 알고 싶다면 일반적으로 선택 사항입니다.
nonopolarity

3
Apropos Black Boxen과 Inside Out. Git은 "인터페이스"보다는 실제로 배우기 가 더 쉬운 첫 번째 문제 입니다. 그것이 올바른 길인지 아닌지 논란의 여지가 있습니다. git에 관해서는 내부가 더 효과적이라고 말하고 있습니다.
Noufal Ibrahim

9
"git은 유닉스와 비슷하다. 사용하기는 쉽지만 친구에 대해서는 까다 롭다." 티셔츠에 인쇄하고 싶네요.
proflux

41

업데이트 : 현재 받아 들여지는 답변 은의 행동에 대한 일반적인 오해를 계속 git push하며 주석이 지적되었지만 수정되지 않았습니다.

리포지토리 URL의 별명과 같은 원격 장치에 대한 요약이 정확합니다.

그렇다면 왜 URL이 git : //git@github.com/peter/first_app.git이 아닌 다른 구문입니까? 어떤 구문입니까? 왜 .git로 끝나야합니까? 끝에 .git을 사용하지 않았으며 작동합니다. .git이 아니라면 다른 무엇을 할 수 있습니까? 초보자의 자식은 자식 서버의 사용자 계정 인 것 같습니다.

언급 한 두 URL은 서로 다른 두 가지 전송 프로토콜을 사용해야 함을 나타냅니다. 먼저 시작하는 git://것은 git 프로토콜에 대한 것이며, 일반적으로 리포지토리에 대한 읽기 전용 액세스에만 사용됩니다. 다른 하나 git@github.com:peter/first_app.git는 SSH를 통해 저장소에 대한 액세스를 지정하는 다른 방법 중 하나입니다. 이는 "scp 스타일 구문"에 설명되어 있습니다. . 이는 설명서에 입니다. scp 스타일 구문의 사용자 이름은 gitGitHub가 사용자 식별을 처리하는 방식 때문입니다. 기본적으로 사용자 이름은 무시되며 사용자는 인증에 사용한 SSH 키 쌍을 기반으로 식별됩니다.

자세한 내용은 git push origin master 는 첫 번째 푸시 후에는 할 수 있음을 알았습니다 git push. 이것은 기억하기 쉽지 않지만 일반적으로 유용한 일련의 기본값 때문입니다. :)

  • 원격이 지정되지 않은 경우 현재 분기에 대해 구성된 원격 remote.master.url 이 사용됩니다 (귀하의 경우). 설정되지 않은 경우 origin사용됩니다.
  • "refspec"(예 : master, master:my-experiment등)이 지정 되지 않은 경우, git은 기본적으로 리모컨의 분기와 이름이 같은 모든 로컬 분기를 푸시합니다. 당신은 단지라는 지점이있는 경우 master저장소와 원격 일 사이에 공통점, 즉 당신의 밀어와 동일 할 것이다 master리모트 master.

개인적으로, 나는 많은 토픽 브랜치 (그리고 종종 여러 리모트)를 가지고 있기 때문에 항상 다음 형식을 사용합니다.

git push origin master

... 실수로 다른 가지를 밀지 않도록합니다.


다른 답변 중 하나에 대한 귀하의 의견에 답하면 마치 마치 마치 마치 되어 매우 효율적으로 하향식 (top-down) 방식으로 자식에 대한 학습 - 당신은 기본값이 작동한다는 것을 발견했습니다, 그리고 귀하의 질문에 이유에 대해 질문입니다) 대상을 더 심각한, 자식이 될 기본적으로 SVN처럼 간단하게 사용되지만 리모컨 및 분기에 대해 조금만 알고 있으면 훨씬 더 유연하게 사용할 수 있으며 더 나은 작업 방식을 실제로 바꿀 수 있습니다. 학기 과정에 대한 당신의 발언은 팟 캐스트 인터뷰에서 Scott Chacon이 말한 것을 생각하게합니다. 학생들은 컴퓨터 과학 및 소프트웨어 공학의 모든 기본 도구에 대해 배우지 만, 거의 버전 관리는하지 않습니다. git 및 Mercurial과 같은 분산 버전 제어 시스템은 이제 매우 중요하고 유연하여 사람들에게 좋은 접지를 제공하는 코스를 가르치는 것이 좋습니다.

내 견해 git로는이 학습 곡선은 그만한 가치가 있다는 것입니다. 많은 토픽 브랜치로 작업하고 쉽게 병합하고 시스템에 자신감이 생기면 다른 리포지토리간에 밀고 당기는 것이 환상적으로 유용합니다. 불행히도 :

  • git의 기본 문서는 초보자를 위해 파싱하기가 너무 어렵습니다. (거의 모든 git 질문에 대해 Google을 사용하면 유용한 자습서 자료 (또는 스택 오버플로 답변 :))가 요즘 등장한다고 주장합니다.
  • git에는 약간의 이상한 행동이 있는데, 지금은 변경하기 어려운 스크립트가 많기 때문에 사람들에게는 혼란 스러울 수 있습니다.

pro git book은 훌륭한 자료이며 초보자도 쉽게 이해할 수 있다고 생각합니다. 학습 곡선을 상당히 부드럽게합니다. 또한 SVN 및 기타 중앙 집중식 개념을 git에 "매핑"하려고하면 도로가 매끄럽지 않고 어려워집니다. 완전한 재설정은 내 경험에서 더 빠르고 쉬운 방법입니다.
Noufal Ibrahim

@Noufal Ibrahim : 모든 요점에 동의합니다. 나는 SVN 개념을 자식들에게 "매핑 (mapping)"하는 것을 제안하려고하지 않았다. 왜냐하면 나는 끔찍한 혼란을 일으킬 수 있기 때문이다.
Mark Longair

9

원격 저장소를 추가하는 구문을 살펴보십시오.

git remote add origin <url_of_remote repository>

예:

git remote add origin git@github.com:peter/first_app.git

명령을 해부하자 :

git remote 이것은 git 저장소를 호스팅하기 위해 Central 서버를 관리하는 데 사용됩니다.

중앙 저장소에 Github 을 사용하고있을 수 있습니다 . 예를 들어 git remote add origin 명령을 설명하겠습니다.

git 리포지토리의 중앙 서버를 위해 GitHubBitBucket 과 함께 작업 하고 있으며 첫 번째 앱 프로젝트를 위해 두 웹 사이트 모두에 리포지토리를 만들었습니다 .

이제이 git 서버 모두에 변경 사항을 적용하려면 git 에게이 중앙 리포지토리에 도달하는 방법을 알려 주어야합니다. 이걸 추가해야합니다.

GitHub의 경우

git remote add gh_origin https://github.com/user/first-app-git.git

비트 버킷

git remote add bb_origin https://user@bitbucket.org/user/first-app-git.git

나는 (지금까지로는 나를 그 변수를 호출하기 쉽게) 두 변수를 사용했다 gh_origin (GH위한 GitHub의)와 bb_origin (BB에 대한의 bitbucket) 단지 우리가 우리가 원하는 원점 아무것도 호출 할 수 있습니다 당신을 설명합니다.

이제 약간의 변경을 한 후에 다른 모든 사용자가 이러한 변경 사항을 볼 수 있도록 이러한 모든 변경 사항을 중앙 리포지토리로 보내야합니다. 그래서 전화

GitHub로 푸시

git push gh_origin master

BitBucket으로 푸시

git push bb_origin master

gh_originhttps://github.com/user/first-app-git.git의 값을 보유 하고 있고 bb_originhttps : //user@bitbucket.org/user/first-app-git.git의 값을 보유 하고 있습니다 .

이 두 변수는 내 인생을 더 쉽게 만들고 있습니다

코드 변경 사항을 보내야 할 때마다 URL을 기억하거나 입력하는 대신이 단어를 사용해야합니다.

대부분의 경우 Github 또는 BitBucket과 같은 하나의 중앙 리포지토리 만 처리 할 때 원산지 이외의 것은 표시되지 않습니다 .


5
  1. .git저장소 이름 끝에 그냥 컨벤션입니다. 일반적으로 git 서버의 저장소는라는 디렉토리에 보관됩니다 project.git. git 클라이언트와 프로토콜 은 지정된 시간 project.git만 테스트하여이 규칙을 준수 project합니다.

  2. git://git@github.com/peter/first_app.git유효한 자식 URL이 아닙니다. git 저장소는 여기에 지정된 다양한 URL 체계를 통해 식별하고 액세스 할 수 있습니다 . git@github.com:peter/first_app.git 는 IS ssh해당 페이지에 언급 된 URL입니다.

  3. git유연합니다. 리포지토리의 거의 모든 지점에 대해 로컬 지점을 추적 할 수 있습니다. 동안 master(해당 지역의 기본 분기) 추적 origin/master(원격 기본 분기)의 인기 상황, 그것은 보편적 없습니다. 여러 번 그렇게하고 싶지 않을 수도 있습니다. 이것이 첫 번째 git push가 너무 장황한 이유 입니다. mastera git pull또는 a 를 수행 할 때 git에게 로컬 브랜치 로 수행 할 작업을 알려줍니다 git push.

  4. 기본값은 대한 git pushgit pull현재 지점의 원격으로 작업하는 것입니다. 이것은 오리진 마스터보다 더 나은 기본값입니다. git push가 이것을 결정하는 방법은 여기 에 설명되어 있습니다 .

git 상당히 우아하고 이해하기 쉽지만 학습 곡선이 있습니다.


1
다른 답변에 대해 언급했듯이 git의 기본 구성 에서 푸시 할 원격 참조를 결정하기 위해 git push설정된 구성 변수를 사용하지 않습니다 git branch/checkout --track. 그러나 git pull이 이것을 사용하는 것이 맞습니다.
Mark Longair

0

Git 원격 원점 추가 :

소스 코드를 다른 프로젝트로 중앙 집중화합니다. Linux를 기반으로 개발되었으며 완전한 오픈 소스이며 다른 git 사용자에게 유용한 코드를 제공합니다.

자식 허브의 원격 URL을 사용하여 코드를 자식 저장소에 푸시합니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.