Git es un sistema de control de versiones pensado para tener un control sobre los cambios y ramificaciones del software al trabajar en un equipo de desarrolladores o en proyectos complejos
Un repositorio de trabajo creado con git init es para… trabajar
Un repositorio desnudo creado con git init --bare es para ... compartir.
Los repositorios creados con git init --bare se denominan repos desnudos. Están estructurados de manera un poco diferente a los directorios de trabajo. En primer lugar, no contienen una copia funcional o extraída de sus archivos fuente.
Los desarrolladores clonarán el repositorio descubierto compartido, realizarán cambios localmente en sus copias de trabajo del repositorio y luego volverán al repositorio compartido para que sus cambios estén disponibles para otros usuarios.
Por ejemplo, si un desarrollador está colaborando con un equipo de desarrollo, y necesita un lugar donde compartir los cambios realizados sobre un repositorio, será necesario crear un repositorio bare en un servidor centralizado donde todos los desarrolladores puedan enviar sus cambios (git push).
Una bifurcación es una diferencia dentro de una rama. Una rama, en cambio, tiene su propio nombre, esta monitorizada por Git de manera autonoma
Pregunta 4: Has creado una confirmación y la has enviado, ahora es pública. Sin embargo, has notado que todavía hay cosas que deben cambiarse. ¿Puedes hacerlo en la etapa de confirmación? y si es así, ¿Cómo?
Si, aún pueden realizarse cambios, incluso después del commit. La forma de hacerlo es emitiendo uno de los comandos git llamado revert.
El comando actuará como un "parche" para la confirmación que debe cambiarse. De esta manera, incluso si te has olvidado de cambiar algo antes de implementar la confirmación en la versión en vivo, aun puedes alterar y arreglar las cosas después.
Hace referencia a cuando decides elegir algún tipo de confirmación de una rama basada en Git y luego aplicar sus características a otra rama. Ahora, te preguntaras, ¿Por que esto se denomina "cherry-picking"? Sencillo, la mayoría de los demás comandos Git que se basan en transferencias de confirmación están diseñados para copiar simultáneamente múltiples confirmaciones. Con cherry-picking, podrás elegir una confirmación y aplicarla en otra rama.
Sirve para guardar el area de trabajo actual en una 'pila' provisional para poder luego recuperarla y seguir trabajando, dejando asi vacia/libre el workspace.
Muy util por ejemplo si, de repente, tienes que dejar apartado el trabajo que tienes entre manos para ponerte con otro que tiene urgencia.
Necesitas que no se pierdan los avances que llevas hechos en el workspace pero el trabajo tampoco esta terminado como para hacer un commit
En términos muy básicos push manda los cambios a tu repositorio remoto, mientras commit lo hace al repositorio local.
Git utiliza el lenguaje "C".
"C" permite que Git sea excepcionalmente rápido, algo que sería muy difícil de lograr con algunos de los lenguajes de programación más avanzados.
Cuando tomas un repositorio y creas tu propia rama después de esto, realizas algunos cambios y quieres fusionar dicha rama al proyecto principal.
Un commit puede existir (o no) en tu repositorio local o en cualquiera de tus repositorios remotos. Dicho esto, la única limitación es que tienes es no poder asociar un tag a un commit que no existe.
Puedes hacer commit, crear el tag, hacer push del commit y hacer push del tag. Puedes hacer commit, hacer push del commit, crear el tag y hacer push del tag.
No puedes crear el tag de un commit que no existe. Puedes hacer un commit y un tag, pero si quieres subir el tag deberán antes hacer push del commit pues de lo contrario no habría referencia en el repositorio remoto hacia un commit que no ha sido subido