¿Qué es "git remoto add..." y "git push origin master"?
Muy a menudo, Git y Ruby on Rails parecen mágicos... como en el primer capítulo del libro Tutorial de Ruby on Rails 3 , se 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 empezar a hablar de ramificación. La búsqueda en Internet muestra que git remote addhay que agregar un "nombre corto", como origin, y también puede ser cualquier nombre, que es como un alias de una URL.
Y origines la ruta habitual a la que 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, sino 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? ¿ La gitentrada [email protected]parece ser una cuenta de usuario en el servidor Git?
Además, ¿por qué es necesario que su uso sea tan detallado git push origin master? ¿No pueden ser los valores predeterminados origen y maestro? Descubrí que la primera vez, origin masteres necesario, pero después de una pequeña edición y confirmación, git pushes todo lo que necesita (no es necesario origin master). ¿Alguien que sepa lo que está pasando puede dar algunos detalles?
A veces se siente como mucha magia sin explicación... y a veces la persona que la usa tiene tanta confianza que 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 está mal ser práctico, pero probablemente no lo sea hasta el punto de no saber qué está pasando.
Git es como Unix. Es fácil de usar, pero exigente con sus amigos. Es tan poderoso y fácil de usar como un shell pipeline.
Dicho esto, una vez que comprendes sus paradigmas y conceptos, tiene la misma claridad Zen que espero 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 Pro Git es un buen lugar para comenzar.
Para responder a 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 localmente. Para comunicarse con el mundo exterior, Git utiliza los llamados "remotos" . Estos son repositorios distintos al de su disco local en los que puede insertar sus cambios (para que otras personas puedan verlos) o extraerlos (para poder obtener otros cambios). El comando
git remote add origin [email protected]:peter/first_app.gitcrea un nuevo control remoto llamadooriginubicado en[email protected]:peter/first_app.git. Una vez que haga esto, en sus comandos de inserción, puede enviar al origen en lugar de escribir la URL completa.Qué es
git push origin master?Este es un comando que dice "enviar las confirmaciones en la rama local denominada master al origen remoto denominado ". Una vez ejecutado esto, todo el material que sincronizaste por última vez con Origin se enviará al repositorio remoto y otras personas podrán verlo allí.
Ahora sobre transportes (es decir, qué git://) significa. 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 encargarse de los permisos y demás. Esto significa que para file://las 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 conjuntos de cambios de Git. En cuanto a la URL exacta, es así debido 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 llamado bar ". En lenguaje Git, esto significa que las pistas maestras bar/foo . Cuando clones por primera vez, obtendrás una rama llamada master y un control remoto llamado origin (desde donde clonaste) con el master local configurado para rastrear al master en el origen.
Una vez configurado esto, simplemente puede decirlo git pushy lo hará. El comando más largo está disponible en caso de que lo necesite (por ejemplo, git pushpuede enviarse al repositorio público oficial y git push review masterpuede usarse para enviarlo a un control remoto separado que su equipo usa para revisar el código). Puede configurar su sucursal para que sea una sucursal de seguimiento usando la --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 desde 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 muy claros. Estoy de acuerdo contigo en que hay cierto elitismo entre muchos usuarios de Git, pero también descubrí que hubo una vez con los usuarios de Unix, y valió la pena superarlos 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 qué 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 para principiantes parece ser una cuenta de usuario en el servidor Git?
Las dos URL que mencionó indican que se deben utilizar 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.gites 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 se gitdebe a la forma en que GitHub identifica a los usuarios; esencialmente, se ignora el nombre de usuario y el usuario se identifica en función del par de claves SSH que utilizó para autenticarse.
En cuanto a la verbosidad de git push origin master, habrás notado que después del primer empujón, puedes simplemente hacer git push. Esto se debe a una serie de valores predeterminados difíciles de recordar pero generalmente útiles :)
remote.master.urlSi no se especifica ningún control remoto, se utiliza el control remoto configurado para la sucursal actual (en su caso). Si eso no está configurado, entoncesoriginse usa.- Si no se especifica ninguna "refspec" (p. ej.
master,master:my-experiment, etc.), entonces Git por defecto envía cada rama local que tiene el mismo nombre que una rama en el control remoto. Si solo tiene una rama llamadamasteren común entre su repositorio y el remoto, será lo mismo que enviar su archivomasteral remotomaster.
Personalmente, como tiendo a tener muchas ramas temáticas (y a menudo varias remotas), 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 como si estuviera aprendiendo sobre Git de arriba hacia abajo de manera muy efectiva: ha descubierto que los valores predeterminados funcionan y su pregunta es por qué;) Para ser más serio, Git se puede usar esencialmente tan simple como SVN, pero saber un poco sobre controles remotos y ramas significa que puedes usarlo de manera mucho más flexible y esto realmente puede cambiar para mejor tu forma de trabajar.
Su comentario sobre un curso semestral me hace pensar en algo que dijo Scott Chacón en una entrevista en podcast: a los estudiantes se les enseña todo tipo de herramientas básicas en ciencias de la computación 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 brindar a la gente 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 moverlas y moverlas entre diferentes repositorios es increíblemente útil una vez que te vuelves seguro con el sistema. Es simplemente lamentable que:
- La documentación principal de Git es muy difícil de analizar para los recién llegados. (Aunque yo diría que si buscas en Google casi cualquier pregunta sobre Git, hoy en día aparece material tutorial útil (o respuestas de Stack Overflow :)).
- Hay algunos comportamientos extraños en Git que son difíciles de cambiar ahora porque muchos scripts pueden depender de ellos, pero resultan 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 [email protected]:peter/first_app.git
Analicemos el comando:
git remoto esto se utiliza para administrar sus servidores centrales para alojar sus repositorios Git.
Quizás estés usando GitHub para tu 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 mi proyecto de primera aplicación .
Ahora, si quiero enviar mis cambios a ambos 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://[email protected]/user/first-app-git.git
He usado dos variables (hasta ahora es fácil para mí llamarlas variables) gh_origin (gh para GitHub ) y bb_origin (bb para Bitbucket ) solo para explicarle que podemos llamar origen como queramos.
Ahora, después de realizar algunos cambios, tendré que enviar (enviar) todos estos cambios a los repositorios centrales para que otros usuarios puedan verlos. 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: //[email protected] /user/first-app-git.git
Estas dos variables me están haciendo la vida más fácil.
ya que cada vez que necesito enviar cambios en mi código, necesito usar estas palabras en lugar de recordar o escribir la URL del mismo.
La mayoría de las veces no verá nada excepto el origen , ya que la mayoría de las veces tratará con un solo repositorio central como GitHub o Bitbucket, por ejemplo.
