¿La creación de un repository GitHub crea un repository Git?

He creado muchos repositorys en GitHub, pero todavía no he subido ninguno de ellos a Git.

Al download mis repositorys, en GitHub, usando el button verde en la esquina superior derecha de la list de files del repository, me he dado count de que puedes download el repository a través de Git usando un enlace, aunque no he subido el repository a Git . También he notado que los enlaces se ven así: https://github.com/Dog-Face-Development/Bars.git , y señalan un Bars.git (o el que sea el nombre del repository) que no conozco tener en mi list de files.

La pregunta es: ya que puedo download mi repository de GitHub a través de Git, aunque no he subido el repository a Git, y como parece que hay un file con la extensión .git , ¿eso significa que mi repo se carga automáticamente? y agregado a Git sin que yo haga nada, y luego puedo comprometerme con el repository de Git usando mi computadora y las herramientas Git de línea de command?

La pregunta es: dado que puedo download mi repository de GitHub a través de Git aunque no he cargado el repository a Git, y dado que parece haber un file .git, ¿eso significa que mi repository se carga automáticamente

(énfasis mío)

No. Sin embargo, la respuesta a la pregunta que hizo en el asunto es "sí": la creación de un repository de GitHub crea un repository de Git.

La parte difícil aquí es que un repository GitHub es un repository Git. Lo que GitHub agrega (su "valor agregado" como service) es, bueno, más de una cosa, así que digamos que incluye en lugar de hacerlo, que el repository que crean está almacenado en sus computadoras, donde se hace una copy de security y es accesible de toda la web, y demás.

They-GitHub-también agrega un montón de capas de comunicación, y cosas como "requestes de extracción" con un solo button, y tenedores, y así sucesivamente. Pero todo comienza cuando crean un repository de Git.

El caso es que su repository Git es, en este punto, totalmente independiente de su repository Git, ¡si es que tiene uno todavía!

La forma en que dos repositorys Git diferentes (independientes) se comunican entre sí es, al less normalmente, usar git fetch y / o git push . Estos commands de Git le dicen a su Git que llame a algún otro Git, generalmente a través de una dirección http o https o ssh. Una vez que tu Git está hablando con ese otro Git por cualquier canal de comunicación que sea, me gusta llamarlo conversación telefónica, lo que puede ser significativo para aquellos que usan sus teléfonos inteligentes para hacer llamadas reales 🙂 -tu Git y su Git intercambia información sobre quién se compromete y un Git (el emisor) envía confirmaciones y otros objects al otro Git (el receptor).

Si aún no tiene un repository de Git, puede usar un process de cuatro pasos:

  1. crear un nuevo repository totalmente vacío;
  2. agregar un control remoto (normalmente denominado origin ) que almacena una URL como https://github.com/path/to/repo.git ;
  3. ejecute git fetch en este nuevo repository vacío para recostackr todas las confirmaciones en el otro Git que responde al teléfono de Internet en ese https "número de teléfono"; y última
  4. ejecuta git checkout master para crear una nueva twig llamada master en tu nuevo repository usando el mismo commit encontrado por el nombre de origin/master que el paso 3 creó en tu repository, basado en lo que su Git tiene en su master .

O bien, puede ejecutar git clone , que hace esos pasos por usted.

De cualquier manera, ahora hay dos repositorys Git.

Sin embargo, hay otra cosa a tener en count.

GitHub puede crear un repository totalmente vacío, o uno con 1 compromiso

Cuando utilizas el button "crear repository" en la interfaz web de GitHub, eso crea un repository de Git allí. Ahora elige si desea crearlo con un file README y / o un file .gitignore y / o un file LICENSE, usando cuadros de clic y botones de menu desplegable.

Para crear un repository con files, GitHub realmente debe comenzar creando un repository completamente vacío, y luego agregar inmediatamente una única confirmación cuyos contenidos son los files que usted eligió.

Ellos dicen:

Esto le permitirá inmediatamente clonar el repository en su computadora. Omita este paso si está importando un repository existente.

pero eso no es realmente cierto. También puede clonar el repository vacío inmediatamente. El problema es que un repository vacío se comporta de manera bastante extraña.

Ahora, si usas git init para hacer tus propios repositorys, esos también están vacíos. También se comportan de forma bastante extraña, pero puede que no lo hayas notado, porque tan pronto como haces tu primer commit, comienzan a comportarse normalmente … y cualquier rareza puede ser eliminada con bastante facilidad. Esto es less para el command git clone , que realmente quiere finalizar con un paso de git checkout .

Aún así, puedes clonar un repository vacío. El resultado es otro repository vacío. Luego puede crear un primer commit aquí, y usar git push para enviarlo de vuelta al repository (todavía vacío) en GitHub. Una vez que crea una confirmación en su clon, ya no está vacía y comienza a comportarse normalmente; cuando ejecutas git push , tu Git llama al Git en GitHub en el "número de teléfono" almacenado, les envía tu (s) compromiso (s) y les hace crear una twig master , o cualquier twig que hayas creado y empujado, y ahora su repository también comienza a comportarse normalmente.

¿Qué sucede si los haces hacer 1 commit, pero haces tu primer commit?

Si piensas en lo anterior, verás que podrías hacer que GitHub creara un repository y pusiera uno en él, y luego podrías git init tu propio repository y poner tu primer compromiso en él. Entonces puedes git add origin https://github.com/... para configurar tu Git para que llame a su Git, y testing a ejecutar git fetch .

Esto funcionará bien. Tu Git llamará a su Git y hará que su Git te envíe sus confirmaciones, que serán su única confirmación de raíz con los files Léame, Ignorar y / o Licencia. Tu Git registrará la ID hash de ese commit bajo el nombre de origin/master tu Git.

Mientras tanto, tu propio Git tiene tu primer commit registrado bajo tu nombre master . Tu primer commit tiene todo lo que le pongas, tal vez files diferentes a los que GitHub de hasta tres creará para ti.

Lo curioso de esto es que ambas confirmaciones son confirmaciones de raíz . Tienen su compromiso único, que no está relacionado con tu compromiso único; y ahora tienes su único compromiso, y tu uno se compromete.

Puedes pedirle a tu Git que combine estos dos commits. Algunas versiones de Git lo harán sin cuestionar. Las versiones más recientes (2.9 o posterior) objetarán: ¡Oye, tu master y su origin/master parecen no tener relación! Para que estos Gits más nuevos fusionen estos historiales no relacionados, debe agregar la --allow-unrelated-histories . Para get más información al respecto, consulte la respuesta de VonC a una pregunta relacionada .

GitHub es un alojamiento de repository de Git. Usted crea el repository en GitHub, y luego puede clonar a través de Git y comprometerse allí también.

Como se sugirió, solo siga la guía de introducción .

Ya que puedo download mi repository de GitHub a través de Git, aunque no he subido el repository a Git

El repository inicializado en GitHub por usted, una vez creado, es un repository simple .

… y como parece que hay un file .git

Esto no es un file El sufijo .git (no una extensión de file) es solo una convención de nomenclatura para repositorys simples.

… eso significa que mi repo se carga automáticamente y se agrega a Git sin que yo haga nada, y luego puedo comprometerme con el repository de Git usando mi computadora y las herramientas Git de la línea de command

No. El repository remoto, vacío, desnudo, solo se "carga" con su código en su primer command de git push realizado desde su repository local .

Regla de oro: todo en Git sucede localmente , solo cambiarás tu repository "remoto" de GitHub cada vez que hagas empujones.