106 votos

¿Qué es "git remote add..." y "git push origin master"?

Bastante a menudo, Git and Rails parece mágico... como en el primer capítulo del libro tutorial de Rails 3 habla de Git:

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

y dice más o menos "simplemente funciona" sin decir demasiado sobre lo que son y empiezan a hablar de ramificación. La búsqueda en la red muestra que git remote add es añadir un "nombre corto", como origin y también puede ser cualquier nombre, que es como un alias para una URL. Y origin es el camino habitual de donde apunta el repo remoto. (en http://git-scm.com/book/en/Git-Basics-Working-with-Remotes en "Añadir depósitos remotos")

Entonces, ¿por qué la URL no es git://git@github.com/peter/first_app.git pero en la otra sintaxis ¿qué sintaxis es? ¿Por qué debe terminar con .git ? Traté de no usar .git al final y también funciona. Si no es así .git ¿Qué más puede ser? El git en git@github.com parece ser una cuenta de usuario en el servidor de Git?

Además, ¿por qué tiene que ser tan verborreico usar git push origin master ? ¿No pueden ser el origen y el maestro? Encontré que la primera vez, el origin master es necesario, pero después de una pequeña edición y commit, entonces git push es todo lo que necesita (no hay necesidad origin master ). ¿Puede alguien que sabe lo que está pasando dar algunos detalles?

A veces parece mucha magia sin explicación... y a veces la persona que la usa tiene tanta confianza y cuando se le pregunta por qué, no puede explicarla, y responde con algo como "así es como es". A veces es muy práctico y pragmático. No está mal ser práctico, pero probablemente no sea práctico hasta el punto de no saber lo que está pasando.

147voto

Noufal Ibrahim Puntos 32200

git es como el UNIX. Fácil de usar pero exigente con sus amigos. Es tan poderoso y tan fácil de usar como un oleoducto de Shell.

Dicho esto, una vez que entiendes sus paradigmas y conceptos, tiene la misma claridad zen que he llegado a esperar de las herramientas de línea de comandos de UNIX. Deberías considerar tomarte un tiempo libre para leer uno de los muchos buenos tutoriales de git disponibles en línea. El libro de Pro Git es un buen lugar para empezar.

Para responder a su primera pregunta.

  1. ¿Qué es git remote add ...

    Como probablemente sepas, git es un sistema de control de versiones distribuido. La mayoría de las operaciones se realizan localmente. Para comunicarse con el mundo exterior, git utiliza lo que se llama remotes . Estos son depósitos distintos al de su disco local que pueden push sus cambios en (para que otras personas puedan verlos) o pull de (para que puedas conseguir otros cambios). El comando git remote add origin git@github.com:peter/first_app.git crea un nuevo mando a distancia llamado origin situado en git@github.com:peter/first_app.git . Una vez que hagas esto, en tus comandos de empuje, puedes empujar a origin en lugar de escribir toda la URL.

  2. ¿Qué es git push origin master

    Este es un comando que dice "empuja el commits en la rama local llamada master al mando a distancia llamado origin ". Una vez que esto se ejecute, todas las cosas que sincronizaste por última vez con el origen serán enviadas al repositorio remoto y otras personas podrán verlas allí.

Ahora sobre los transportes (es decir, lo que git:// ) significa. Las URL de los depósitos remotos pueden ser de muchos tipos ( file:// , https:// etc.). Git simplemente confía en el mecanismo de autenticación proporcionado por el transporte para encargarse de los permisos y cosas. Esto significa que para file:// URLs, serán permisos de archivos UNIX, etc. El git:// está pidiendo a git que use su propio protocolo de transporte interno, que está optimizado para enviar git changesets. En cuanto a la URL exacta, es así por la forma en que gitub ha establecido su git servidor.

Ahora la verborrea. El comando que has escrito es el general. Es posible decirle a git algo como "la rama llamada master aquí está el espejo local de la rama llamada foo en el mando a distancia llamado bar ". En palabras de git, esto significa que master pistas bar/foo . Cuando se clona por primera vez, se obtiene una rama llamada master y un mando a distancia llamado origin (de donde se clonó) con el maestro local configurado para rastrear el maestro en el origen. Una vez que esto está configurado, puedes simplemente decir git push y lo hará. El comando más largo está disponible en caso de que lo necesites. git push podría empujar al público oficial de repo y git push review master puede ser usado para empujar a un control remoto separado que tu equipo usa para revisar el código). Puedes configurar tu rama para que sea una rama de seguimiento usando el --set-upstream de la opción de la git branch comando.

He sentido que el git (a diferencia de la mayoría de las otras aplicaciones que he usado) se entiende mejor de adentro hacia afuera. Una vez que entiendes cómo se almacenan y mantienen los datos dentro del repositorio, los comandos y lo que hacen se vuelven muy claros. Estoy de acuerdo contigo en que hay cierto elitismo entre muchos git pero también encontré que con los usuarios de UNIX había una vez, y valía la pena arar más allá de ellos para aprender el sistema. ¡Buena suerte!

19voto

Mark Longair Puntos 93104

Actualización: observe que la respuesta actualmente aceptada perpetúa una un malentendido común sobre el comportamiento de git push que no ha sido corregido a pesar de un comentario que lo señala.

Tu resumen de lo que son los mandos a distancia - como un apodo para la URL de un repositorio - es correcto.

Entonces, ¿por qué la URL no es git://git@github.com/peter/first_app.git sino en la otra sintaxis qué sintaxis es? ¿Por qué debe terminar con .git? Intenté no usar .git al final y también funciona. Si no es .git, ¿qué más puede ser? El git del principiante parece ser una cuenta de usuario en el servidor git?

Los dos URL que ha mencionado indican que deben utilizarse dos protocolos de transporte diferentes. El que comienza con git:// es para el protocolo git, que normalmente sólo se utiliza para el acceso de sólo lectura a los depósitos. El otro, git@github.com:peter/first_app.git es una de las diferentes formas de especificar el acceso a un repositorio a través de SSH - esta es la "sintaxis de estilo scp" descrita en la documentación . Que el nombre de usuario en la sintaxis del estilo scp es git se debe a la forma en que GitHub se ocupa de identificar a los usuarios - esencialmente ese nombre de usuario es ignorado, y el usuario es identificado en base al par de claves SSH que usaron para autenticarse.

En cuanto a la verborrea de git push origin master te has dado cuenta de que después del primer empujón, puedes hacer git push . Esto se debe a una serie de incumplimientos difíciles de recordar pero generalmente útiles :)

  • Si no se especifica ningún mando a distancia, el mando configurado para la rama actual (en remote.master.url en su caso) se utiliza. Si eso no está establecido, entonces origin se utiliza.
  • Si no hay "refspec" (por ejemplo. master , master:my-experiment especificadas, y luego el git se encarga por defecto de empujar cada rama local que tenga el mismo nombre que una rama en el remoto. Si sólo tienes una rama llamada master en común entre su depósito y el remoto, eso será lo mismo que empujar su master al remoto master .

Personalmente, como tiendo a tener muchas ramas temáticas (y a menudo varios mandos a distancia) siempre uso el formulario:

git push origin master

...para evitar empujar accidentalmente otras ramas.


En respuesta a sus comentarios sobre una de las otras respuestas, me suena como si son aprendiendo sobre git de una forma muy efectiva de arriba a abajo - has descubierto que los valores por defecto funcionan, y tu pregunta es por qué ;) Para ser más serio, git puede ser usado esencialmente de forma tan simple como el SVN, pero conocer un poco sobre los mandos y las ramas significa que puedes usarlo de forma mucho más flexible y esto puede cambiar realmente la forma de trabajar para mejor. Tu comentario sobre un curso de un semestre me hace pensar en algo que dijo Scott Chacon en una entrevista de podcast - a los estudiantes se les enseña todo tipo de herramientas básicas en informática e ingeniería de software, pero muy raramente control de versiones. Los sistemas de control de versiones distribuidos como git y Mercurial son ahora tan importantes, y tan flexibles, que valdría la pena impartir cursos sobre ellos para dar a la gente una buena base.

Mi opinión es que con git trabajar con muchas ramas temáticas, fusionarlas fácilmente, y empujarlas y tirar de ellas entre diferentes depósitos es fantásticamente útil una vez que te sientes seguro con el sistema. Es una lástima que:

  • La documentación principal de git es muy difícil de analizar para los recién llegados. (Aunque diría que si buscas en Google casi cualquier pregunta sobre git, hoy en día aparece material tutorial útil (o respuestas sobre el desbordamiento de la pila :)).
  • Hay algunos comportamientos extraños en el git que son difíciles de cambiar ahora porque muchos scripts pueden depender de ellos, pero son confusos para la gente.

2voto

anshul Puntos 2964
  1. El .git al final del nombre del depósito es sólo una convención. Típicamente, en los servidores git los repositorios se mantienen en directorios llamados project.git . El cliente y el protocolo de git honran esta convención probando para project.git cuando sólo project se especifica.

  2. git://git@github.com/peter/first_app.git no es una url válida de git. Los repositorios de git pueden identificarse y accederse a través de varios esquemas de url especificados aquí . git@github.com:peter/first_app.git es el ssh url mencionada en esa página.

  3. git es flexible. Te permite rastrear tu sucursal local contra casi cualquier sucursal de cualquier repositorio. Mientras que master (su sucursal local por defecto) de seguimiento origin/master (la rama remota por defecto) es una situación popular, no es universal. Muchas veces puede que no quieras hacer eso. Es por eso que la primera git push es tan verborreico. Le dice al imbécil qué hacer con el local master rama cuando haces una git pull o un git push .

  4. El valor por defecto de git push y git pull es trabajar con el control remoto de la sucursal actual. Esto es mejor por defecto que el maestro de origen. La forma en que el empuje del git determina esto se explica aquí .

git es bastante elegante y comprensible, pero hay una curva de aprendizaje que recorrer.

Iteramos.com

Iteramos es una comunidad de desarrolladores que busca expandir el conocimiento de la programación mas allá del inglés.
Tenemos una gran cantidad de contenido, y también puedes hacer tus propias preguntas o resolver las de los demás.

Powered by:

X