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

github com new (5)

Muy a menudo, Git y Rails parecen magia ... como en el primer capítulo del libro Tutorial Rails 3 , habla de Git:

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

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

Entonces, ¿por qué la URL no es git://[email protected]/peter/first_app.git pero 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 en [email protected] parece ser una cuenta de usuario en el servidor de git?

Además, ¿por qué tiene que ser tan detallado para usar git push origin master ? ¿No puede ser el origen y 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, todo lo que necesita es git push (no es necesario el origin master ). ¿Alguien que sabe lo que está pasando puede dar algunos detalles?

A veces se siente como mucha magia sin explicación ... y otras veces la persona que la usa es tan confiada y cuando se le pregunta por qué, no puede explicarlo y responde con algo como "así es como es". A veces muy práctico y pragmático. No es malo ser práctico, pero probablemente no sea práctico hasta el punto de no saber qué está pasando.

El .git al final del nombre del repositorio es solo una convención. Por lo general, en los servidores de git, los repositorios se guardan en directorios llamados project.git . El cliente y el protocolo de git cumplen esta convención al probar project.git cuando solo se especifica el project .
git://[email protected]/peter/first_app.git no es una URL de git válida. Los repositorios de git se pueden identificar y acceder a través de varios esquemas de URL especificados aquí . [email protected]:peter/first_app.git es la URL ssh mencionada en esa página.
git es flexible. Le permite rastrear su sucursal local contra casi cualquier sucursal de cualquier repositorio. Si bien el origen de master (su rama local predeterminada) origin/master (la rama remota remota) es una situación popular, no es universal. Muchas veces no querrás hacer eso. Esta es la razón por la que el primer git push es tan detallado. Le dice a git qué hacer con la rama master local cuando haces un git pull o un git push .
El valor predeterminado para git push y git pull es trabajar con el control remoto de la rama actual. Este es un valor predeterminado mejor que el maestro de origen. La manera en que git push determina esto se explica here .

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

Git remoto agregar origen:

Centraliza su código fuente a los otros proyectos. Se desarrolla en base a Linux, completa fuente abierta y hace que su código sea útil para los demás usuarios de git. Lo llamamos como referencia

Inserta su código en el repositorio de git utilizando la URL remota del concentrador de git.

Usted usa git puede ser que eres programador. Si eres un programador entonces puedes entender que variables son!

Eche un vistazo a la sintaxis para agregar un repositorio remoto.

git remote add origin <url_of_remote repository>

Ejemplo:

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

Analicemos el comando:

git remote se utiliza para administrar sus servidores centrales para alojar sus repositorios git.

Puede ser que estés usando Github para tus cosas del repositorio central. Te daré un ejemplo y te explicaré el comando git remote add origin

Supongamos que estoy trabajando con GitHub y BitBucket para los servidores centrales de los repositorios de git y he creado repositorios en ambos sitios web para el proyecto de mi primera aplicación .

Ahora, si quiero enviar mis cambios a ambos servidores git, entonces tendré que decirle a git cómo llegar a estos repositorios centrales. Así que tendré que añadir estos,

Para GitHub

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

Y para BitBucket

git remote add bb_origin https://[email protected]/user/first-app-git.git

He usado dos variables (en la medida en que es fácil para mí llamarlas variables) gh_origin (gh FOR GITHUB) y bb_origin (bb para BITBUCKET) solo para explicarles que podemos llamar a origen como queramos.

Ahora, después de realizar algunos cambios, tendré que enviar (empujar) todos estos cambios a los repositorios centrales para que otros usuarios puedan ver estos cambios. Así que llamo

Empujando a GitHub

git push gh_origin master

Empujando a BitBucket

git push bb_origin master

gh_origin es el valor de retención de https://github.com/user/first-app-git.git y bb_origin es el valor de retención de https://[email protected]/user/first-app-git.git

Estas dos variables me están haciendo la vida más fácil.

como siempre que necesito enviar los cambios de código, necesito usar estas palabras en lugar de recordar o escribir la URL para el mismo.

La mayoría de las veces no verá nada excepto el origen, ya que la mayoría de las veces tratará solo con un repositorio central como Github o BitBucket, por ejemplo.

git es como UNIX. Fácil de usar pero exigente con sus amigos. Es tan potente y tan fácil de usar como un shell shell.

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

Para contestar tu primera pregunta.

¿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 a nivel local. Para comunicarse con el mundo exterior, git usa lo que se llama remotes . Estos son repositorios distintos al que está en su disco local en el que puede push sus cambios (para que otras personas puedan verlos) o desde (para que pueda obtener otros cambios). El comando git remote add origin [email protected]:peter/first_app.git crea un nuevo control remoto llamado origin localizado en [email protected]:peter/first_app.git . Una vez que haga esto, en sus comandos push, puede empujar a origin lugar de escribir la URL completa.
¿Qué es git push origin master
Este es un comando que dice "empujar las confirmaciones en la rama local denominada master al origin denominado remoto". Una vez que se ejecuta esto, todas las cosas que sincronizó por última vez con el origen se enviarán al repositorio remoto y otras personas podrán verlas allí.

Ahora sobre transportes (es decir, qué significa git:// ). Las URL de repositorios remotos pueden ser de muchos tipos ( file:// , https:// etc.). Git simplemente se basa en el mecanismo de autenticación proporcionado por el transporte para hacerse cargo de los permisos y demás. Esto significa que para las URL de file:// , serán permisos de archivos UNIX, etc. El esquema git:// le pide a git que use su propio protocolo de transporte interno, que está optimizado para enviar conjuntos de cambios de git. En cuanto a la URL exacta, es la forma en que se debe a la forma en que github ha configurado su servidor git .

Ahora la verbosidad. El comando que has escrito es el general. Es posible decirle a git algo como "la rama llamada master aquí es un espejo local de la rama llamada foo en el control remoto llamada bar ". En git speak, esto significa que las pistas master bar/foo . Cuando clona por primera vez, obtendrá una rama llamada master y un origin remoto llamado (desde donde clonó) con el conjunto maestro local para rastrear el maestro en origen. Una vez que esto esté configurado, simplemente puedes decir git push y lo hará. El comando más largo está disponible en caso de que lo necesite (por ejemplo, git push podría ingresar al repositorio público oficial y git push review master puede usarse para enviar un control remoto separado que su equipo utiliza para revisar el código). Puede configurar su rama para que sea una rama de seguimiento mediante la opción --set-upstream del comando git branch .

Sentí que git (a diferencia de la mayoría de las otras aplicaciones que he usado) se entiende mejor desde adentro hacia afuera. Una vez que entienda 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 un poco de elitismo entre muchos usuarios de git , pero también descubrí que con los usuarios de UNIX había una vez, y valía la pena pasar por delante de ellos para aprender el sistema. ¡Buena suerte!

Actualización: tenga en cuenta que la respuesta actualmente aceptada perpetúa un longair.net/blog/2011/02/27/… sobre el comportamiento de git push , que no se ha corregido a pesar de que un comentario lo señala.

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

Entonces, ¿por qué la URL no es git: //[email protected]/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 en el principiante parece ser una cuenta de usuario en el servidor de git?

Las dos URL que ha mencionado indican que deben usarse dos protocolos de transporte diferentes. El que comienza con git:// es para el protocolo git, que generalmente solo se usa para acceso de solo lectura a los repositorios. La otra, [email protected]: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 . El hecho de que el nombre de usuario en la sintaxis de estilo scp sea git se debe a la forma en que GitHub trata de identificar a los usuarios; básicamente, ese nombre de usuario se ignora y el usuario se identifica según el par de claves SSH que utilizaron para autenticar.

En cuanto a la verbosidad de git push origin master , has notado que después de la primera pulsación, puedes hacer git push . Esto se debe a una serie de valores por defecto difíciles de recordar, pero en general útiles :)

Si no se especifica ningún control remoto, se utiliza el control remoto configurado para la rama actual (en remote.master.url en su caso). Si eso no está configurado, entonces se utiliza el origin .
Si no se especifica "refspec" (p. Ej., master , master:my-experiment , etc.), entonces git por defecto empujará cada rama local que tenga el mismo nombre que una rama en el control remoto. Si solo tiene una rama llamada master en común entre su repositorio y el remoto, eso será lo mismo que empujar su master al master remoto.

Personalmente, ya que tiendo a tener muchas ramas temáticas (y, a menudo, varios controles remotos) 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 parece que estoy aprendiendo sobre git de una manera muy eficaz de arriba a abajo: ha descubierto que los valores predeterminados funcionan y su pregunta es sobre por qué;) Para ser más serios, git puede usarse esencialmente como SVN, pero saber un poco acerca de los controles remotos y las sucursales significa que puede usarlo con mayor flexibilidad y esto realmente puede cambiar la forma en que trabaja para mejorar. Su 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 el 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 que las personas tengan una buena base.

Mi opinión es que con git , esta curva de aprendizaje vale absolutamente la pena: trabajar con muchas ramas temáticas, fusionarlas fácilmente, y empujarlas y tirar de ellas entre diferentes repositorios es extremadamente útil una vez que confíe en el sistema. Es simplemente desafortunado 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 para casi cualquier pregunta de git, en la actualidad aparece material útil de tutoriales (o respuestas de desbordamiento de pila :)).
Hay algunos comportamientos extraños en git que son difíciles de cambiar ahora porque muchos scripts pueden confiar en ellos, pero son confusos para las personas.