github pushed - O que é “git remote add…” e “git push origin master”?



of histories (5)

  1. O .git no final do nome do repositório é apenas uma convenção. Normalmente, em servidores git, os repositórios são mantidos em diretórios denominados project.git . O cliente e o protocolo git honram esta convenção testando project.git quando somente o project é especificado.

  2. git://[email protected]/peter/first_app.git nã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 . [email protected]:peter/first_app.git é o URL do ssh mencionado nessa página.

  3. git é flexível. Ele permite que você rastreie sua filial local em quase qualquer ramo de qualquer repositório. Embora o master (sua ramificação padrão local) rastreando origin/master (a ramificação padrão remota) seja uma situação popular, ela não é universal. Muitas vezes você pode não querer fazer isso. É por isso que o primeiro git push é tão detalhado. Ele diz ao git o que fazer com o branch master local quando você faz um git pull ou um git push .

  4. O padrão para git push e git pull é trabalhar com o controle remoto da ramificação atual. Este é um padrão melhor que o mestre de origem. O modo como o git push determina isso é explicado here .

git é bastante elegante e compreensível, mas existe uma curva de aprendizado para percorrer.

Muitas vezes, o Git and Rails parece mágica ... como no primeiro capítulo do livro Tutorial do Rails 3 , ele fala sobre o Git:

git remote add origin [email protected]:peter/first_app.git
git push origin master

e praticamente diz "simplesmente funciona" sem dizer muito sobre o que eles são e começar a falar sobre ramificação. Pesquisar na net mostra que git remote add é para adicionar um "nome abreviado", como origin , e pode ser qualquer nome também, que é como um alias para um URL. E origin é o caminho usual de 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 a URL não é git://[email protected]/peter/first_app.git mas na outra sintaxe - qual é a sintaxe? Por que deve terminar com .git ? Eu tentei não usar o .git no final e funciona também. Se não .git , o que mais pode ser? O git em [email protected] parece ser uma conta de usuário no servidor git?

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

Às vezes parece muita magia sem explicação ... e às vezes a pessoa que a usa é tão confiante e quando perguntada por que, 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 ao ponto de não saber o que está acontecendo.


Atualização: observe que a resposta aceita atualmente perpetua um longair.net/blog/2011/02/27/… sobre o comportamento do git push , que não foi corrigido apesar de um comentário ter sido exibido.

Seu resumo de quais remotas são - como um apelido para o URL de um repositório - está correto.

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

As duas URLs que você mencionou indicam que dois protocolos de transporte diferentes devem ser usados. O que começa com git:// é para o protocolo git, que geralmente é usado apenas para acesso somente leitura a repositórios. O outro, [email protected]:peter/first_app.git , é uma das maneiras diferentes de especificar o acesso a um repositório via SSH - essa é a "sintaxe do estilo scp" descrita na documentação . O nome de usuário na sintaxe scp-style é git devido à maneira como o GitHub lida com os usuários que identificam - 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 do git push origin master , você notou que após o primeiro push, você pode fazer o git push . Isto é 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 (em remote.master.url no seu caso) será usado. Se isso não estiver configurado, a origin será usada.
  • Se não houver nenhum "refspec" (por exemplo, master , master:my-experiment , etc.) especificado, o git assumirá como padrão pressionar todos os ramos locais que tenham o mesmo nome de um ramo no controle remoto. Se você tiver apenas uma ramificação chamada master em comum entre o seu repositório e o remoto, isso será o mesmo que empurrar seu master para o master remoto.

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 ramos.

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

Minha opinião é que, com o git , essa curva de aprendizado é absolutamente valiosa - trabalhar com muitos tópicos, mesclá-los facilmente e empurrá-los e empurrá-los entre diferentes repositórios é extraordinariamente útil quando você se torna confiante com o sistema. É apenas lamentável que:

  • A documentação primária do git é tão difícil de analisar para os recém-chegados. (Apesar de eu argumentar que, se você fizer o Google por quase qualquer dúvida, o material de tutorial útil (ou o responde :)) aparecerá 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.

Você usa git pode ser você é programador. Se você é um programador, você pode entender quais são as variáveis!

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

git remote add origin <url_of_remote repository>

Exemplo:

git remote add origin [email protected]:peter/first_app.git

Deixe-nos dissecar o comando:

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

Pode ser que você esteja usando o Github para o seu 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 tenha criado repositórios em ambos os sites para o meu primeiro projeto de aplicativo .

Agora, se eu quiser empurrar minhas alterações para ambos os servidores git, então precisarei informar ao git como chegar a esses repositórios centrais. Então eu vou ter que adicionar esses

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://[email protected]/user/first-app-git.git

Eu usei duas variáveis ​​(na medida em que é fácil para mim chamá-las de variáveis) gh_origin (gh PARA GITHUB) e bb_origin (bb para BITBUCKET) só para explicar você podemos chamar de origem qualquer coisa que quisermos.

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

Empurrando para o GitHub

git push gh_origin master

Empurrando 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://[email protected]/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 verá nada além da origem, pois na maioria das vezes você lidará com apenas um repositório central como o Github ou o BitBucket, por exemplo.


Git remoto adicionar origem:

Ele centraliza o código-fonte nos outros projetos. Ele é desenvolvido com base no Linux, completa o código-fonte aberto e torna seu código útil para os outros usuários git. Chamamos isso de referência.

Empurra seu código no repositório git usando o url remoto do hub git.


git pull = git fetch + git merge 




git github