¿Cuál es la diferencia entre clone y mkdir-> cd-> init-> remote-add-> pull?

Question

Después de configurar un repositorio en Github, parece haber dos formas de llevar ese repositorio a un repositorio local.

En primer lugar, podría crear un directorio, inicializar un repositorio en blanco, agregar un control remoto y luego extraer los cambios del control remoto.

> mkdir "exampleProject" 
> cd "exampleProject" 
> git init 
> git remote add origin git@github.com:exampleUser/exampleProject.git 
> git pull origin master 

En segundo lugar, podría clonar el control remoto.

> git clone git@github.com:exampleUser/exampleProject.git 

¿Es la clonación solo un acceso directo para la versión de 5 pasos anterior o también hace algo más? ¿Me encontraré con dificultades si utilizo un método sobre el otro?

Answer 1

Muchos comandos, ya sean comandos git o programas comunes, hacen cosas en una línea que de otro modo podrían hacer en diez. ¡Siempre es bueno ahorrar trabajo!

Dicho esto, sus pasos están cerca, pero no del todo como lo que hace git clone. Se me ocurren algunas diferencias, todo tiene que ver con las ramas:

• Si, por alguna razón, la cabeza del mando a distancia es no maestro, el clon va a hacer lo correcto - le dan una rama llamada la lo mismo que el control remoto, en lugar de maestro. Esto es raro, pero hay que tener en cuenta un buen detalle.

• Su git pull no creará ramas remotas. Si el control remoto tiene varias ramas, el clon crea ramas remotas remotes/origin/foo, remotes/origin/bar, ... en su repositorio. Un git fetch origin se encargaría de eso en los pasos enumerados.

• Tampoco ha configurado su rama principal para rastrear el origen, que hace el clon. Puede agregar esto a los pasos enumerados como git config branch.master.remote origin; git config branch.master.merge refs/heads/master. Esto es muy significativo: con sus pasos, si tiene el maestro desprotegido y escribe git pull, no sabrá qué hacer.

Es posible que me haya perdido una o dos cosas. En cuanto a las dificultades de una manera u otros, incluso suponiendo que allanar todas las diferencias entre un clon defecto y un "clon manual", mi consejo es que no es reinventar git clone:

• Es corto. ¿Por qué hacer más trabajo?

• Tiene opciones prácticas para cambiar su comportamiento. Cosas como --shared serían realmente difíciles de agregar a los comandos enumerados.

• Se garantiza que hará lo correcto ahora y en el futuro. ¿Qué pasa si te perdiste un detalle, como los de arriba? ¿Qué pasa si git agregó un parámetro de configuración global que afectó a los clones? Tendría que cambiar sus comandos para tenerlo en cuenta, pero git clon ya lo sabría.