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

Te damos la bienvenida a nuestro espacio, en este sitio vas a encontrar la respuesta de lo que necesitas.

Solución:

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

Dicho esto, una vez que comprenda sus paradigmas y conceptos, tendrá la misma claridad zen que espero 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 sabes, 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 usa lo que se llama remotes. Estos son repositorios distintos al de su disco local que puede push sus cambios en (para que otras personas puedan verlos) o pull de (para que pueda obtener otros cambios). El comando git remote add origin [email protected]:peter/first_app.gitcrea un nuevo control remoto llamado origin situado en [email protected]:peter/first_app.git. Una vez que haga esto, en sus comandos push, puede presionar para origin en lugar de escribir la URL completa.

2. Que es git push origin master

   Este es un comando que dice “enviar las confirmaciones en la rama local llamada master al control 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 los transportes (es decir, qué git://) medio. Las URL del 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 hacerse cargo de los permisos y demás. Esto significa que para file:// URL, serán permisos de archivo UNIX, etc. git:// El 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 la forma en que es debido a la forma en que github ha configurado su git servidor.

Ahora la verbosidad. El comando que ha 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 git speak, esto significa que masterpistasbar/foo. Cuando clone por primera vez, obtendrá 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, simplemente puede decir git push y lo hará. El comando más largo está disponible en caso de que lo necesite (p. Ej. git push podría empujar al repositorio público oficial y git push review master se puede usar para presionar 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 utilizando el --set-upstream opción de la git branch mando.

Creo 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 claros como el cristal. Estoy de acuerdo contigo en que hay cierto elitismo entre muchos git usuarios, pero también encontré eso con los usuarios de UNIX una vez, y valió la pena pasar 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 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 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 para principiantes parece ser una cuenta de usuario en el servidor git?

Las dos URL que ha mencionado 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 el acceso de solo lectura a los repositorios. El otro, [email protected].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 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 función del SSH key-par que solían autenticar.

En cuanto a la verbosidad de git push origin master, has 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 🙂

• Si no se especifica ningún remoto, el remoto configurado para la rama actual (en remote.master.url en su caso) se utiliza. Si eso no está configurado, entonces origin se utiliza.
• Si no hay “refspec” (p. Ej. master, master:my-experiment, etc.) especificado, luego git por defecto empuja cada rama local que tiene el mismo nombre que una rama en el control remoto. Si solo tienes una rama llamada master en común entre su repositorio y el remoto, será lo mismo que empujar su master al 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án aprender sobre git de forma descendente de forma muy eficaz: ha descubierto que los valores predeterminados funcionan y su pregunta es por qué;) Para ser más serio, git pueden ser utilizado esencialmente tan simplemente como SVN, pero saber un poco sobre controles remotos y sucursales significa que puede usarlo con mucha más flexibilidad y esto realmente puede cambiar la forma en que trabaja 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 ciencias de la computación 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 brindar a las personas una buena base.

Mi punto de vista es que con git, esta curva de aprendizaje vale absolutamente la pena: trabajar con muchas ramas temáticas, fusionarlas fácilmente y empujarlas y moverlas entre diferentes repositorios es fantásticamente útil una vez que se sienta 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 busca en Google casi cualquier pregunta de git, hoy en día aparece material útil de tutorial (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 confunden a las personas.

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

git remote add origin 

Ejemplo:

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

Analicemos el comando:

git remoto esto se usa para administrar sus servidores centrales para alojar sus repositorios git.

Puede que estés usando Github para su repositorio central. Te daré un ejemplo y te explicaré el git remoto agregar origen mando

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

Ahora, si quiero enviar mis cambios a ambos servidores de 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 (en la medida en que me es fácil llamarlas variables) gh_origin (gh PARA GITHUB) y bb_origin (bb para BITBUCKET) solo para explicarle que podemos llamar al origen lo que queramos.

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

Empujar a GitHub

git push gh_origin master

Empujar a BitBucket

git push bb_origin master

gh_origin tiene valor de tenencia de https://github.com/user/first-app-git.git y bb_origin tiene valor de tenencia de https: //[email protected]/user/first-app-git.git

Estas dos variables me facilitan la vida

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

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

Aquí puedes ver las comentarios y valoraciones de los usuarios

---

---

Utiliza Nuestro Buscador