¿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 de Git:

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

y casi dice "simplemente funciona" sin decir demasiado acerca de lo que son y comenzar a hablar de ramificación. La búsqueda en la red muestra que git remote addse debe agregar un "nombre corto", como origin, y también puede ser cualquier nombre, que es como un alias a una URL. Y origines 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://git@github.com/peter/first_app.gitsino en la otra sintaxis? ¿Qué sintaxis es? ¿Por qué debe terminar con .git? Intenté no usarlo .gital final y también funciona. Si no .git, ¿qué más puede ser? El giten el git@github.comque parece ser una cuenta de usuario en el servidor git?

Además, ¿por qué debe ser tan detallado de usar git push origin master? ¿No puede el valor predeterminado ser origen y maestro? Descubrí que la primera vez origin masteres necesaria, pero después de una pequeña edición y confirmación, git pushes todo lo que necesita (no es necesario origin master). ¿Puede alguien que sabe lo que está pasando dar algunos detalles?

A veces se siente mucha magia sin explicación ... y a veces la persona que lo usa tiene tanta confianza y cuando se le pregunta por qué, no puede explicarlo y responde con algo como "así 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 lo que está sucediendo.

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

Dicho esto, una vez que comprende 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 libre 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 responder a tu primera pregunta.

1. Que es git remote add ...

   Como probablemente sepa, gites un sistema de control de versiones distribuido. La mayoría de las operaciones se realizan localmente. Para comunicarse con el mundo exterior, gitutiliza lo que se llama remotes. Estos son repositorios distintos del que está en su disco local en el que puede realizar pushsus cambios (para que otras personas puedan verlos) o pulldesde (para que pueda obtener otros cambios). El comando git remote add origin git@github.com:peter/first_app.gitcrea un nuevo control remoto llamado originubicado en git@github.com:peter/first_app.git. Una vez que haga esto, en sus comandos push, puede presionar en originlugar de escribir la URL completa.

2. Que es git push origin master

   Este es un comando que dice "empujar los commits en la rama local llamada masteral remoto llamado origin". Una vez que esto se ejecute, 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é git://) significa. Las URL de repositorio remoto pueden ser de muchos tipos ( file://, https://etc.). Git simplemente se basa en el mecanismo de autenticación proporcionado por el transporte para encargarse de los permisos y demás. Esto significa que para las file://URL, serán permisos de archivos UNIX, etc. El git://esquema le pide a git que use su propio protocolo de transporte interno, que está optimizado para enviar los conjuntos de cambios de git. En cuanto a la URL exacta, es como es debido a la forma en que github ha configurado su gitservidor.

Ahora la verbosidad. El comando que ha escrito es el general. Es posible decirle a git algo como "la rama llamada masteraquí es un espejo local de la rama llamada fooen el control remoto llamado bar". En git speak, esto significa que master sigue bar/foo . Cuando clones por primera vez, obtendrás una rama llamada mastery una llamada remota origin(desde donde clonaste) con el maestro local configurado para rastrear el maestro en origen. Una vez que esté configurado, simplemente puede decir git pushy lo hará. El comando más largo está disponible en caso de que lo necesite (por ejemplo, git pushpodría pasar al repositorio público oficial y git push review masterpuede usarse para pasar a un control remoto separado que su equipo usa para revisar el código). Puede configurar su rama para que sea una rama de seguimiento utilizando el--set-upstreamopción del git branchcomando.

He sentido que git (a diferencia de la mayoría de las otras aplicaciones que he usado) se entiende mejor de adentro hacia afuera. Una vez que comprenda cómo se almacenan y mantienen los datos dentro del repositorio, los comandos y lo que hacen se vuelven claros. Estoy de acuerdo con usted en que hay un cierto elitismo entre muchos gitusuarios, pero también descubrí que con los usuarios de UNIX había una vez, y valió la pena pasarlos por alto para aprender el sistema. ¡Buena suerte!

Actualización: tenga en cuenta 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 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 en el principiante parece ser una cuenta de usuario en el servidor git?

Las dos URL que ha mencionado indican que se deben usar dos protocolos de transporte diferentes. La primera git://es para el protocolo git, que generalmente solo se usa para el acceso de solo lectura a los repositorios. La otra 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 . El nombre de usuario en la sintaxis de estilo scp gitse 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 función del par de claves SSH que utilizaron para autenticar.

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

• Si no se especifica ningún control remoto, remote.master.urlse utiliza el control remoto configurado para la rama actual ( en su caso). Si eso no está configurado, entonces originse usa.
• Si no se especifica "refspec" (p master. Ej . master:my-experiment, Etc.), el valor predeterminado de git es empujar cada rama local que tenga el mismo nombre que una rama en el control remoto. Si solo tiene una rama llamada masteren común entre su repositorio y el remoto, eso será lo mismo que empujarlo masteral control remoto master.

Personalmente, dado 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 está aprendiendo sobre git de arriba hacia abajo de manera muy efectiva: ha descubierto que los valores predeterminados funcionan y su pregunta es preguntar por qué;) Para ser más serio, git puedese puede usar esencialmente como SVN, pero saber un poco sobre los controles remotos y las ramas significa que puedes usarlo con mucha más flexibilidad y esto realmente puede cambiar tu forma de trabajar para mejor. Su comentario sobre un curso semestral me hace pensar en algo que dijo Scott Chacon en una entrevista de podcast: a los estudiantes se les enseña sobre todo tipo de herramientas básicas en informática e ingeniería de software, pero muy raramente en el control de versiones. Los sistemas de control de versiones distribuidos como git y Mercurial ahora son tan importantes y tan flexibles que valdría la pena impartir cursos sobre ellos para darles a las personas una buena base.

Mi opinión es que git, con esta curva de aprendizaje, vale la pena: trabajar con muchas ramas temáticas, fusionarlas fácilmente y empujarlas y arrastrarlas entre diferentes repositorios es fantásticamente útil una vez que tenga confianza en el sistema. Es lamentable que:

• La documentación principal para git es muy difícil de analizar para los recién llegados. (Aunque diría que si buscas en Google casi cualquier pregunta de git, hoy en día aparecerá material de ayuda útil (o respuestas de Stack Overflow :)).
• 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.

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

git remote add origin <url_of_remote repository>

Ejemplo:

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

Analicemos el comando:

git remote esto se usa 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 explicaré el comando git remote add origin

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

Ahora, si quiero enviar mis cambios a estos dos servidores git, tendré que decirle a git cómo llegar a estos repositorios centrales. Entonces tendré que agregar 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://user@bitbucket.org/user/first-app-git.git

He usado dos variables (hasta ahora es fácil para mí llamarlas variables) gh_origin (gh FOR GITHUB) y bb_origin (bb for BITBUCKET) solo para explicarle que podemos llamar al origen lo que queramos.

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

Empujando a GitHub

git push gh_origin master

Empujando a BitBucket

git push bb_origin master

gh_origin tiene el valor de https://github.com/user/first-app-git.git y bb_origin tiene el valor de https: //user@bitbucket.org/user/first-app-git.git

Estas dos variables me hacen la vida más fácil.

ya que cada vez que necesito enviar mis cambios de código, necesito usar estas palabras en lugar de recordar o escribir la URL de la misma.

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

1. El .gitfinal del nombre del repositorio es solo una convención. Por lo general, en los servidores git, los repositorios se guardan en directorios con nombre project.git. El cliente y el protocolo git honran esta convención probando project.gitcuándo solo projectse especifica.

2. git://git@github.com/peter/first_app.gitno es una url git válida. Los repositorios 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 sshurl mencionada en esa página.

3. gitEs flexible. Le permite rastrear su sucursal local contra casi cualquier sucursal de cualquier repositorio. Si bien masterel seguimiento (su sucursal predeterminada local) origin/master(la sucursal predeterminada remota) es una situación popular, no es universal. Muchas veces es posible que no quieras hacer eso. Es por eso que el primero git pushes tan detallado. Le dice a git qué hacer con la mastersucursal local cuando haces una git pullo una git push.

4. El valor predeterminado para git pushy git pulles trabajar con el control remoto de la sucursal actual. Este es un mejor valor predeterminado 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 por la que caminar.

Git remoto agregar origen:

Centraliza su código fuente a los otros proyectos. Está desarrollado en base a Linux, completa el código abierto y hace que su código sea útil para otros usuarios de git. Lo llamamos como referencia

Introduce tu código en el repositorio de git utilizando la url remota del git hub.