Что такое «git remote add…» и «git push origin master»?

Довольно часто Git и Rails выглядят как волшебство ... например, в первой главе учебника по Rails 3 говорится о Git:

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). Может ли кто-нибудь, кто знает, что происходит, дать некоторые подробности?

Иногда это кажется большим количеством волшебства без объяснения ... и иногда человек, использующий это, настолько уверен, и когда его спрашивают, почему, не может объяснить это, и отвечает что-то вроде "это так". Иногда очень практично и прагматично. Неплохо быть практичным, но, вероятно, не практичным до такой степени, чтобы не знать, что происходит.

gitэто как UNIX. Удобный, но требовательный к своим друзьям. Он такой же мощный и удобный для пользователя, как конвейер оболочки.

При этом, как только вы поймете его парадигмы и концепции, у него будет та же ясность дзен, как я ожидал от инструментов командной строки 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. Как только вы сделаете это, в ваших командах push вы можете нажать 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 говорят, что это означает, что master треки bar/foo . Когда вы клонируете в первый раз, вы получите вызываемую ветвь masterи удаленный origin(откуда вы клонировали) с локальным мастером, настроенным на отслеживание мастера по источнику. Как только это настроено, вы можете просто сказать, git pushи это будет сделано. Более длинная команда доступна в том случае, если она вам нужна (например, git pushможет подтолкнуть к официальному публичному репо и git push review masterможет использоваться для передачи на отдельный пульт, который ваша команда использует для просмотра кода). Вы можете установить свою ветку как отслеживающую ветку, используя--set-upstreamвариант git branchкоманды.

Я чувствовал, что Git (в отличие от большинства других приложений, которые я использовал) лучше понять изнутри. Как только вы поймете, как данные хранятся и хранятся в хранилище, команды и то, что они делают, становятся кристально понятными. Я согласен с вами в том, что среди многих gitпользователей есть некоторый элитарность, но я также обнаружил, что когда-то давно с пользователями UNIX было, и стоило вспомнить их, чтобы изучить систему. Удачи!

Обновление: обратите внимание, что принятый в настоящее время ответ увековечивает распространенное заблуждение о поведении git push, которое не было исправлено, несмотря на комментарий, указывающий на это.

Ваше краткое изложение того, что такое пульты - например, псевдоним для URL хранилища - является правильным.

Так почему URL-адрес не git: //git@github.com/peter/first_app.git, а в другом синтаксисе - какой это синтаксис? Почему это должно заканчиваться на .git? Я пытался не использовать .git в конце, и это тоже работает. Если нет .git, что еще это может быть? Git у новичка кажется учетной записью пользователя на сервере Git?

Два URL-адреса, которые вы упомянули, указывают, что следует использовать два разных транспортных протокола. Первый начинается с git://протокола git, который обычно используется только для доступа к репозиториям только для чтения. Другой git@github.com:peter/first_app.gitспособ - это один из различных способов указания доступа к хранилищу по SSH - это «синтаксис в стиле scp», описанный в документации . То, что имя пользователя в синтаксисе в стиле scp gitявляется следствием того, что GitHub имеет дело с идентификацией пользователей - по сути, это имя пользователя игнорируется, и пользователь идентифицируется на основе пары ключей SSH, которую они использовали для аутентификации.

Что касается многословия git push origin master, вы заметили, что после первого нажатия вы можете просто сделать git push. Это из-за серии трудных для запоминания, но в целом полезных значений по умолчанию :)

• Если пульт не указан, используется пульт, настроенный для текущей ветви ( remote.master.urlв вашем случае). Если это не настроено, то originиспользуется.
• Если «refspec» (например master, master:my-experimentи т. Д.) Не указан, то git по умолчанию отправляет каждую локальную ветвь с тем же именем, что и ветка на удаленном компьютере. Если у вас просто есть ветка, вызываемая masterмежду вашим репозиторием и удаленной, это будет то же самое, что и ваша ветка masterна удаленную master.

Лично, поскольку у меня, как правило, много веток тем (и часто несколько удаленных), я всегда использую форму:

git push origin master

... чтобы случайно не толкнуть другие ветви.

В ответ на ваши комментарии на одном из других ответов, это звучит для меня , как будто будут очень эффективно узнавать о мерзавце в нисходящем пути - вы обнаружили , что по умолчанию работает, и ваш вопрос спрашивает о том, почему;) To будь серьезнее, мерзавец можетиспользовать его по сути так же просто, как SVN, но, зная немного о пультах и ​​ветвях, вы можете использовать его гораздо гибче, и это может реально изменить вашу работу к лучшему. Ваше замечание по поводу семестрового курса заставляет меня думать о том, что Скотт Чакон сказал в интервью подкаста: студентов учат всем видам базовых инструментов в области компьютерных наук и разработки программного обеспечения, но очень редко - контролю версий. Распределенные системы контроля версий, такие как git и Mercurial, теперь настолько важны и настолько гибки, что стоило бы проводить курсы по ним, чтобы дать людям хорошее основание.

С моей точки зрения git, эта кривая обучения абсолютно стоит того - работать с множеством веток тем, легко объединять их, а также перемещать и перемещать их между различными репозиториями, становится фантастически полезным, как только вы становитесь уверенными в системе. Просто жаль, что:

• Первичную документацию по git так сложно разобрать новичкам. (Хотя я бы поспорил, что если вы используете Google практически для любого git-вопроса, в настоящее время подойдет полезный учебный материал (или ответы Stack Overflow :)).)
• В git есть несколько странных поведений, которые трудно изменить сейчас, потому что многие скрипты могут полагаться на них, но они вводят людей в заблуждение.

Посмотрите на синтаксис для добавления удаленного репо.

git remote add origin <url_of_remote repository>

Пример:

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

Давайте рассмотрим команду:

git remote используется для управления центральными серверами для размещения ваших git-репозиториев.

Может быть, вы используете Github для центрального хранилища. Я дам вам пример и объяснить Git удаленных добавить происхождение команды

Предположим, я работаю с GitHub и BitBucket для центральных серверов для репозиториев git и создал репозитории на обоих веб-сайтах для моего проекта первого приложения .

Теперь, если я хочу отправить свои изменения на оба этих сервера git, мне нужно будет указать git, как получить доступ к этим центральным репозиториям. Так что мне придется добавить это,

Для GitHub

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

И для BitBucket

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

Я использовал две переменные (насколько мне легко называть их переменными): gh_origin (gh FOR GITHUB) и bb_origin (bb для BITBUCKET) просто для того, чтобы объяснить вам, что мы можем вызывать origin как угодно.

Теперь после внесения некоторых изменений мне нужно будет отправить (отправить) все эти изменения в центральные репозитории, чтобы другие пользователи могли видеть эти изменения. Так я звоню

Нажав на GitHub

git push gh_origin master

Нажав на BitBucket

git push bb_origin master

gh_origin содержит значение https://github.com/user/first-app-git.git, а bb_origin содержит значение https: //user@bitbucket.org/user/first-app-git.git.

Эти две переменные делают мою жизнь проще

как всякий раз, когда мне нужно отправить изменения в моем коде, мне нужно использовать эти слова вместо того, чтобы запоминать или вводить URL для того же самого.

В большинстве случаев вы не увидите ничего, кроме источника, поскольку в большинстве случаев вы будете иметь дело только с одним центральным репозиторием, например, Github или BitBucket.

1. В .gitконце имени хранилища это просто соглашение. Как правило, на git-серверах репозитории хранятся в именованных каталогах project.git. Клиент git и протокол соблюдают это соглашение, проверяя, project.gitкогда projectуказано только .

2. git://git@github.com/peter/first_app.gitне является действительным URL-адресом git. git-репозитории могут быть идентифицированы и доступны через различные схемы URL, указанные здесь . git@github.com:peter/first_app.git является sshURL , упомянутые на этой странице.

3. gitгибкий Это позволяет вам отслеживать вашу локальную ветку практически против любой ветки любого репозитория. Хотя masterотслеживание (ваша локальная ветвь по умолчанию) origin/master(удаленная ветвь по умолчанию) является популярной ситуацией, оно не является универсальным. Много раз вы можете не захотеть этого делать. Вот почему первое git pushнастолько многословно. Он говорит git, что делать с локальной masterветкой, когда вы делаете a git pullили a git push.

4. По умолчанию git pushи git pullиспользуется для работы с пультом текущего филиала. Это лучше по умолчанию, чем мастер оригинала. Способ, которым git push определяет это, объясняется здесь .

git довольно элегантный и понятный, но есть кривая обучения, чтобы пройти.

Git Remote добавить источник:

Он централизует ваш исходный код для других проектов. Он разработан на основе Linux, полностью открыт с открытым исходным кодом и делает ваш код полезным для других пользователей git. Мы называем его справочным

Вставляет ваш код в репозиторий git, используя удаленный URL-адрес git-хаба.