O que são “git remote add…” e “git push origin master”?

Muitas vezes, o Git e o Rails parecem mágicos ... como no primeiro capítulo do livro Tutorial do Rails 3 , ele fala sobre o Git:

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

e praticamente diz "simplesmente funciona" sem falar muito sobre o que são e começar a falar sobre ramificação. A pesquisa na rede mostra que git remote addé para adicionar um "nome abreviado", como origin, e também pode ser qualquer nome, que é como um alias para um URL. E originé o caminho usual para onde o repositório remoto aponta. (em http://git-scm.com/book/en/Git-Basics-Working-with-Remotes em "Adicionando repositórios remotos")

Então, por que o URL não está git://git@github.com/peter/first_app.gitalém da outra sintaxe - qual é a sintaxe? Por que deve terminar .git? Tentei não usar .gitno final e funciona também. Se não .git, o que mais pode ser? O gitin git@github.comparece ser uma conta de usuário no servidor git?

Além disso, por que ele precisa ser tão detalhado para usar git push origin master? O padrão não pode ser origem e mestre? Descobri que a primeira vez origin masteré necessário, mas depois de uma pequena edição e confirmação, git pushé tudo o que precisa (sem necessidade origin master). Alguém que sabe o que está acontecendo pode dar alguns detalhes?

Às vezes parece muita mágica sem explicação ... e às vezes a pessoa que a usa é tão confiante e, quando perguntada por quê, não consegue explicar e responde com algo como "é assim que é". Às vezes, muito prático e pragmático. Não é ruim ser prático, mas provavelmente não é prático a ponto de não saber o que está acontecendo.

gité como o UNIX. Fácil de usar, mas exigente com seus amigos. É tão poderoso e amigável quanto um pipeline de shell.

Dito isto, depois de entender seus paradigmas e conceitos, ele tem a mesma clareza que eu esperava das ferramentas de linha de comando do UNIX. Você deve tirar um tempo para ler um dos muitos bons tutoriais do git disponíveis on-line. O livro Pro Git é um bom lugar para começar.

Para responder sua primeira pergunta.

1. O que é git remote add ...

   Como você provavelmente sabe, gité um sistema de controle de versão distribuído. A maioria das operações é feita localmente. Para se comunicar com o mundo exterior, gitusa o que é chamado remotes. Estes são repositórios diferentes do disco local em que você pode pushalterar (para que outras pessoas possam vê-lo) ou pullde (para que você possa obter outras alterações). O comando git remote add origin git@github.com:peter/first_app.gitcria um novo controle remoto chamado originlocalizado em git@github.com:peter/first_app.git. Depois de fazer isso, em seus comandos push, você pode pressionar para, em originvez de digitar o URL inteiro.

2. O que é git push origin master

   Este é um comando que diz "envie as confirmações na ramificação local nomeada masterpara o controle remoto nomeado origin". Uma vez executado, todas as coisas que você sincronizou pela última vez com a origem serão enviadas para o repositório remoto e outras pessoas poderão vê-las lá.

Agora, sobre transportes (ou seja, o que git://) significa. URLs de repositório remoto podem ser de vários tipos ( file://, https://etc.). O Git simplesmente depende do mecanismo de autenticação fornecido pelo transporte para cuidar de permissões e outras coisas. Isso significa que, para file://URLs, haverá permissões de arquivo UNIX, etc. O git://esquema está solicitando ao git que use seu próprio protocolo de transporte interno, otimizado para o envio de conjuntos de alterações do git. Quanto ao URL exato, é assim porque o github configurou seu gitservidor.

Agora a verbosidade. O comando que você digitou é o geral. É possível dizer ao git algo como "o ramo chamado masteraqui é o espelho local do ramo chamado foono controle remoto chamado bar". No git speak, isso significa que master acompanha bar/foo . Quando você clona pela primeira vez, recebe uma ramificação chamada mastere uma remota chamada origin(de onde clonou) com o mestre local configurado para rastrear o mestre na origem. Uma vez que isso esteja configurado, você pode simplesmente dizer git pushe fará. O comando mais longo está disponível no caso de você precisar (por exemplo, git pushpode enviar por push para o repositório público oficial e git push review masterpode ser usado para enviar para um controle remoto separado que sua equipe usa para revisar o código). Você pode definir sua ramificação para ser uma ramificação de rastreamento usando o--set-upstreamopção do git branchcomando.

Eu senti que o git (diferente da maioria dos outros aplicativos que usei) é melhor compreendido de dentro para fora. Depois de entender como os dados são armazenados e mantidos dentro do repositório, os comandos e o que eles fazem ficam claros. Eu concordo com você que há algum elitismo entre muitos gitusuários, mas também descobri isso com os usuários do UNIX uma vez, e valeu a pena passar por eles para aprender o sistema. Boa sorte!

Atualização: observe que a resposta atualmente aceita perpetua um mal-entendido comum sobre o comportamento de git push, que não foi corrigido apesar de um comentário apontar.

Seu resumo do que são controles remotos - como um apelido para a URL de um repositório - está correto.

Então, por que o URL não git: //git@github.com/peter/first_app.git, mas na outra sintaxe - qual é a sintaxe? Por que deve terminar com .git? Tentei não usar o .git no final e também funciona. Se não .git, o que mais pode ser? O git no iniciante parece ser uma conta de usuário no servidor git?

Os dois URLs que você mencionou indicam que dois protocolos de transporte diferentes devem ser usados. O primeiro começa com git://o protocolo git, que geralmente é usado apenas para acesso somente leitura aos repositórios. A outra,, git@github.com:peter/first_app.gité uma das diferentes maneiras de especificar o acesso a um repositório através do SSH - esta é a "sintaxe do estilo scp" descrita na documentação . O nome de usuário na sintaxe no estilo scp deve-se gità maneira como o GitHub lida com a identificação de usuários - essencialmente esse nome de usuário é ignorado e o usuário é identificado com base no par de chaves SSH que eles usaram para autenticar.

Quanto à verbosidade de git push origin master, você notou que após o primeiro empurrão, você pode simplesmente fazer git push. Isso ocorre devido a uma série de padrões difíceis de lembrar, mas geralmente úteis :)

• Se nenhum controle remoto for especificado, o controle remoto configurado para a ramificação atual ( remote.master.urlno seu caso) será usado. Se isso não estiver configurado, originserá usado.
• Se não houver "refspec" (por exemplo master, master:my-experimentetc.) especificado, o git usará como padrão o envio de todas as ramificações locais com o mesmo nome de ramificação no controle remoto. Se você apenas tem um ramo chamado masterem comum entre o repositório e o remoto, será o mesmo que enviar o seu masterpara o remoto master.

Pessoalmente, como tenho muitas ramificações de tópicos (e muitas vezes vários controles remotos), sempre uso o formulário:

git push origin master

... para evitar empurrar acidentalmente outros galhos.

Em resposta a seus comentários sobre uma das outras respostas, parece-me que estão aprendendo sobre git de forma top-down de forma muito eficaz - você descobriu que os padrões de trabalho, e sua pergunta é perguntar sobre o porquê;) Para ser mais sério, o git podeser usado essencialmente tão simples quanto o SVN, mas conhecer um pouco sobre controles remotos e ramificações significa que você pode usá-lo com muito mais flexibilidade e isso pode realmente mudar a maneira como você trabalha para melhor. Sua observação sobre um curso semestral me faz pensar em algo que Scott Chacon disse em uma entrevista em podcast - os alunos são ensinados sobre todos os tipos de ferramentas básicas em ciência da computação e engenharia de software, mas raramente em controle de versão. Agora, sistemas de controle de versão distribuídos, como git e Mercurial, são tão importantes e flexíveis que valeria a pena ministrar cursos sobre eles para dar às pessoas uma boa base.

Minha opinião é que git, com , essa curva de aprendizado vale a pena - trabalhar com várias ramificações de tópicos, mesclá-las facilmente e empurrá-las e puxá-las entre diferentes repositórios é extraordinariamente útil quando você se torna confiante com o sistema. É lamentável que:

• A documentação principal do git é tão difícil de analisar para os novatos. (Embora eu argumente que, se você pesquisar no Google quase todas as perguntas do git, o material tutorial útil (ou as respostas do Stack Overflow :)) surgem hoje em dia.)
• Existem alguns comportamentos estranhos no git que são difíceis de mudar agora, porque muitos scripts podem confiar neles, mas são confusos para as pessoas.

Dê uma olhada na sintaxe para adicionar um repositório remoto.

git remote add origin <url_of_remote repository>

Exemplo:

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

Vamos dissecar o comando:

O git remote é usado para gerenciar seus servidores Central para hospedar seus repositórios git.

Pode ser que você esteja usando o Github para o seu material de repositório central. Vou dar um exemplo e explicar o comando git remote add origin

Suponha que eu esteja trabalhando com o GitHub e o BitBucket para os servidores centrais dos repositórios git e criei repositórios nos dois sites para o meu primeiro projeto de aplicativo .

Agora, se eu quiser enviar minhas alterações para esses dois servidores git, precisarei dizer ao git como alcançar esses repositórios centrais. Então eu vou ter que adicionar estes,

Para o GitHub

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

E para BitBucket

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

Eu usei duas variáveis ​​(até onde é fácil chamá-las de variáveis) gh_origin (gh FOR GITHUB) e bb_origin (bb para BITBUCKET) apenas para explicar que podemos chamar de origem o que quisermos.

Agora, depois de fazer algumas alterações, terei que enviar (enviar por push) todas essas alterações para os repositórios centrais, para que outros usuários possam ver essas alterações. Então eu ligo

Enviando para o GitHub

git push gh_origin master

Enviando para BitBucket

git push bb_origin master

gh_origin está mantendo o valor de https://github.com/user/first-app-git.git e bb_origin está mantendo o valor de https: //user@bitbucket.org/user/first-app-git.git

Essas duas variáveis ​​estão facilitando minha vida

como sempre que preciso enviar minhas alterações de código, preciso usar essas palavras em vez de lembrar ou digitar o URL para o mesmo.

Na maioria das vezes você não vê nada além de origem, pois na maioria das vezes você lida com apenas um repositório central como o Github ou o BitBucket, por exemplo.

1. O .gitfinal do nome do repositório é apenas uma convenção. Normalmente, nos repositórios de servidores git são mantidos em diretórios nomeados project.git. O cliente e o protocolo git respeitam esta convenção testando project.gitquando somente projecté especificado.

2. git://git@github.com/peter/first_app.gitnão é um URL git válido. Os repositórios git podem ser identificados e acessados ​​através de vários esquemas de URL especificados aqui . git@github.com:peter/first_app.git é o sshURL mencionado nessa página.

3. gité flexível. Ele permite que você rastreie sua filial local em praticamente qualquer filial de qualquer repositório. Embora mastero rastreamento (sua filial padrão local) origin/master(a filial padrão remota) seja uma situação popular, não é universal. Muitas vezes você pode não querer fazer isso. É por isso que o primeiro git pushé tão detalhado. Diz ao git o que fazer com a masterramificação local quando você faz um git pullou um git push.

4. O padrão para git pushe git pullé trabalhar com o controle remoto da filial atual. Este é um padrão melhor que o mestre de origem. A maneira como o git push determina isso é explicada aqui .

git é bastante elegante e compreensível, mas existe uma curva de aprendizado a ser percorrida.

Origem remota de adição remota do Git:

Ele centraliza seu código-fonte para outros projetos. É desenvolvido com base no Linux, completa código-fonte aberto e torna seu código útil para outros usuários do git.

Empurra seu código para o repositório git usando o URL remoto do hub git.