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

Muy a menudo, Git and Rails parece magia … como en el primer capítulo del libro Tutorial de Rails 3 , habla sobre Git:

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

y prácticamente dice "simplemente funciona" sin decir demasiado sobre lo que son y comienzan a hablar sobre ramificación. La búsqueda en la networking muestra que git remote add es para agregar un "nombre corto", como el origin , y también puede ser cualquier nombre, que es como un alias de una URL. Y el origin es la ruta habitual a la que apunta el repository remoto. (en http://git-scm.com/book/es/Git-Basics-Working-with-Remotes en "Agregar repositorys remotos")

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

Además, ¿por qué necesita ser tan detallado para usar git push origin master ? ¿No puede ser el origen y el maestro por defecto? Descubrí que la primera vez, se necesita el origin master , pero después de una pequeña edición y confirmación, entonces git push es todo lo que necesita (sin necesidad de un origin master ). ¿Alguien que sabe lo que está pasando puede dar algunos detalles?

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

git es como UNIX. Fácil de usar, pero exigente con sus amigos. Es casi tan poderoso y fácil de usar como una tubería shell.

Dicho esto, una vez que comprenda sus paradigmas y conceptos, tiene la misma claridad zenlike que he llegado a esperar de las herramientas de command-line de UNIX. Debería considerar tomarse un time 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 comenzar.

Para responder a tu primera pregunta.

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

    Como probablemente sepa, git es un sistema de control de versiones distribuidas. La mayoría de las operaciones se realizan localmente. Para comunicarse con el mundo exterior, git usa lo que se llama remotes . Estos son repositorys que no son el de su disco local en el que puede push sus cambios (para que otras personas puedan verlos) o pull (para que pueda get otros cambios). El command git remote add origin git@github.com:peter/first_app.git crea un nuevo control remoto llamado origin ubicado en git@github.com:peter/first_app.git . Una vez que hagas esto, en tus commands push, puedes presionar hacia el origin lugar de tipear toda la URL.

  2. Qué es el git push origin master

    Este es un command que dice "push the commits en la twig local llamada master para el origin llamado remoto". Una vez que se haya ejecutado, todas las cosas que sincronizó por última vez con el origen se enviarán al repository remoto y otras personas podrán verlas allí.

Ahora sobre los transportes (es decir, lo que git:// ) significa. Las URL de repository remoto pueden ser de muchos types ( file:// , https:// etc.). Git simplemente confía en el mecanismo de authentication proporcionado por el transporte para encargarse de los permissions y demás. Esto significa que para las URL file:// , serán permissions de files UNIX, etc. El esquema git:// le pide a git que use su propio protocolo de transporte interno, que está optimizado para enviar git changesets. En cuanto a la URL exacta, es la forma en que es debido a la forma en que github ha configurado su server git .

Ahora la verbosidad. El command que ha tipeado es el general. Es posible decirle a git algo así como "la twig llamada master aquí es el espejo local de la twig llamada foo en la bar llamada remota". En git speak, esto significa que el master rastrea bar/foo . Cuando se clona por primera vez, obtendrá una twig llamada master y un origin llamado remoto (donde se clonó) con el set maestro local para rastrear el maestro en el origen. Una vez que esté configurado, puedes simplemente decir git push y lo hará. El command más largo está disponible en caso de que lo necesite (por ejemplo, git push puede presionar al repository público oficial y el git push review master se puede usar para enviar a un control remoto separado que su equipo usa para revisar el código). Puede configurar su twig para que sea una twig de seguimiento utilizando la opción --set-upstream del command git branch .

Sentí que git (a diferencia de la mayoría de las otras aplicaciones que he usado) se comprende mejor desde adentro. Una vez que comprenda cómo se almacenan y mantienen los datos dentro del repository, los commands y lo que hacen se vuelven claros como el cristal. Estoy de acuerdo con usted en que hay un poco de elitismo entre muchos usuarios de git pero también encontré que con los usuarios de UNIX alguna vez, y valió la pena pasarlos para aprender el sistema. ¡Buena suerte!

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

Su resumen de lo que son los controles remotos, como un apodo para la URL de un repository, es correcto.

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

Las dos URL que ha mencionado indican que se deben usar dos protocolos de transporte diferentes. El que comienza con git:// es para el protocolo git, que generalmente solo se usa para acceder solo a los repositorys. El otro, git@github.com:peter/first_app.git , es una de las forms diferentes de especificar el acceso a un repository a través de SSH; esta es la "syntax de estilo scp" descrita en la documentation . Que el nombre de usuario en la syntax de estilo scp es git se debe a la forma en que GitHub trata con la identificación de usuarios: esencialmente ese nombre de usuario se ignora, y el usuario se identifica en function del par de keys SSH que utilizaron para autenticarse.

En cuanto a la verbosidad del git push origin master de git push origin master , habrás notado que después del primer empujón, puedes hacer git push . Esto se debe a una serie de valores pnetworkingeterminados difíciles de recordar, pero generalmente útiles 🙂

  • Si no se especifica ningún control remoto, se utiliza el control remoto configurado para la bifurcación actual (en remote.master.url en su caso). Si eso no está configurado, entonces se usa el origin .
  • Si no se especifica "refspec" (por ejemplo, master , master:my-experiment , etc.), entonces git usa de manera pnetworkingeterminada cada twig local que tenga el mismo nombre que una sucursal en el control remoto. Si solo tiene una twig llamada master en común entre su repository y el remoto, eso será lo mismo que enviar su master al master remoto.

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

 git push origin master 

… para evitar empujar accidentalmente otras twigs.


En respuesta a sus comentarios sobre una de las otras respuestas, me parece que está aprendiendo sobre git de forma descendente de manera muy efectiva: ha descubierto que los valores pnetworkingeterminados funcionan y su pregunta es sobre por qué; seamos más serios, git se puede usar esencialmente tan simple como SVN, pero conocer un poco sobre los controles remotos y las ramificaciones significa que puedes usarlo mucho más flexible y esto realmente puede cambiar la forma en que trabajas para mejor. Su comentario sobre un curso semestral me hace pensar en algo que Scott Chacon dijo 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 rara vez control de versiones. Los sistemas de control de versiones distribuidas como git y Mercurial son ahora tan importantes, y tan flexibles, que valdría la pena impartir cursos sobre ellos para proporcionar a las personas una buena base.

Mi punto de vista es que con git , esta curva de aprendizaje vale la pena: trabajar con muchas twigs temáticas, fusionarlas fácilmente y empujarlas y tirar de ellas entre diferentes repositorys es fantásticamente útil una vez que confías en el sistema. Es desafortunado que:

  • La documentation principal para git es tan difícil de analizar para los recién llegados. (Aunque yo argumentaría que si busca en Google casi cualquier pregunta de git, el útil material de tutorial (o las respuestas de Stack Overflow :)) aparecen hoy en día.
  • Hay algunos comportamientos extraños en git que son difíciles de cambiar ahora porque muchos scripts pueden depender de ellos, pero son confusos para las personas.
  1. El .git al final del nombre del repository es solo una convención. Normalmente, en los serveres de git los repositorys se guardan en directorys llamados project.git . El protocolo y el cliente de GIT respetan esta convención al probar project.git cuando solo se especifica el project .

  2. git://git@github.com/peter/first_app.git no es una URL de git válida. Los repositorys de git se pueden identificar y acceder a través de varios esquemas de URL especificados aquí . git@github.com:peter/first_app.git es la url ssh mencionada en esa página.

  3. git es flexible. Le permite rastrear su sucursal local contra casi cualquier sucursal de cualquier repository. Mientras que el origin/master seguimiento master (su sucursal pnetworkingeterminada local) (la sucursal pnetworkingeterminada remota) es una situación popular, no es universal. Muchas veces puede que no quieras hacer eso. Esta es la razón por la cual el primer git push es tan detallado. Le dice a git qué hacer con la twig master local cuando haces un git pull o un git push .

  4. El valor pnetworkingeterminado para git push y git pull es trabajar con el control remoto de la twig actual. Este es un mejor pnetworkingeterminado que el maestro de origen. La forma en que git push determina esto se explica aquí .

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