Git es un sistema de control de versiones distribuido DVCS , que es un software que le permite administrar el código fuente de un proyecto de software durante el desarrollo colaborativo sin necesidad de soporte de un servidor central. Gracias a Git, los programadores pueden registrar cada cambio que se realiza en el código a lo largo del tiempo, comparar diferentes versiones de un mismo archivo, colaborar simultáneamente en el mismo programa para implementar nuevas funciones sin interferir con el trabajo de otros miembros del equipo y hacer muchas otras cosas. que veremos en este artículo. Git es de código abierto y se puede usar en varios sistemas operativos (incluidos Windows, macOS y Linux) y es una herramienta realmente esencial para cualquier desarrollador de software: grandes empresas como Google, Microsoft,Twitter y Linkedin. usarlo, pero puede resultar realmente útil incluso para proyectos mucho más pequeños, incluso si los ejecuta un solo desarrollador. Las características de Git son tantas, en este artículo exploraremos las más importantes.
Repositorios Git
La principal funcionalidad de Git son los repositorios, archivos digitales en los que se almacena y gestiona el código fuente de un proyecto de software y que realizan un seguimiento de los cambios realizados en los archivos a lo largo del tiempo. Un repositorio le permite recuperar versiones anteriores, comparar las diferencias entre versiones y colaborar simultáneamente con otros desarrolladores en equipos sin interferir entre sí.
Los repositorios se pueden alojar en varios servicios de alojamiento que utilizan Git como sistema de control de versiones, como GitHub, GitLab y Bitbucket. Estas herramientas hacen que compartir, colaborar y administrar repositorios sea más fácil y eficiente a través de interfaces web y herramientas de administración de proyectos. Nosotros en este artículo explicaremos cómo usar Git a través de la plataforma GitHub.
En la imagen puedes ver un ejemplo de un repositorio alojado en GitHub:
Cómo instalar Git
Primero necesitamos instalar Git en nuestro sistema operativo. Verifiquemos que aún no lo esté abriendo una terminal del sistema y emitiendo el comando:
git --version
Si no se reconoce el comando, debemos proceder con la instalación según el sistema operativo que estemos usando.
Instalar Git en Windows
Descargue el archivo de instalación desde este enlace e instalarlo como cualquier otro programa:
Instalar Git en Linux
Para instalar Git desde Bash u otro shell del sistema Linux, el comando a utilizar dependerá de la distribución utilizada; Puede encontrar los comandos para las principales distribuciones en este enlace. Por ejemplo, si usa Debian o una distribución derivada como Ubuntu o PopOS, el comando sería:
sudo apt install git
Instalando Git en macOS
Podemos instalar Git a través del administrador de paquetes HomeBrew :
brew install git
Puede encontrar otros métodos de instalación en este enlace
Configurar información de usuario de Git
Como mencionamos, Git nos permite realizar un seguimiento de los diversos cambios realizados en el proyecto a lo largo del tiempo. Para ayudarnos a mantener la lista de estos cambios ordenada y útil, debemos seleccionar un nombre y una dirección de correo electrónico a través del comando git config —global . La configuración global (--global) nos permite configurar esta información solo una vez y usarla en todos los repositorios Git de nuestra computadora.
Elegimos cuidadosamente el nombre: se combinará con los distintos cambios que realice y podrá ser visto por cualquier colaborador que tenga acceso al mismo proyecto. Elegí el mismo nombre de usuario que uso en GitHub, pero también puedes usar tu nombre y apellido si quieres.
En cuanto a la dirección de correo electrónico, asegúrese de usar la dirección de correo electrónico de su cuenta de GitHub: esto le permitirá actualizar su gráfico de actividad en función de los diversos cambios que realice en sus repositorios.
Introduce tu email y tu nombre de usuario o nombre + apellido de la siguiente manera:
En este punto no se nos pedirá contraseña, pero la primera vez intentaremos realizar una operación que requiera autenticación, como empujar o tirar de un repositorio privado (veremos a lo largo de este artículo cuáles son estos comandos). for) Git nos lo pedirá junto con el nombre de usuario para acceder a la plataforma de alojamiento a la que nos estamos conectando, que en nuestro caso es GitHub.
Como se explica en Documentación de GitHub , hay varias formas de autenticarse: si lo desea, también puede simplemente crear un token de acceso personal Documentación de GitHub , que actúa como contraseña de acceso y debe repetirse cada vez que sea necesario autenticarse para realizar alguna operación.
En esta guía seguiremos uno de los procedimientos más sencillos y cómodos instalando la CLI de GitHub.
Configurar el acceso a GitHub usando la CLI de GitHub
GitHub CLI es una interfaz de línea de comandos que le permite interactuar con GitHub realizando muchas de las mismas operaciones que puede realizar en su sitio a través de una terminal.
Vamos a instalarlo en nuestra computadora.
Cómo instalar la CLI de GitHub en Windows
En Windows podemos descargar el archivo de instalación directamente desde el sitio oficial .
Cómo instalar la CLI de GitHub en Linux
Si usa otras distribuciones de Linux, busque la guía en el repositorio, para Debian y Ubuntu, copie y pegue el siguiente comando en la terminal:
Ahora ingresamos el siguiente comando y se nos preguntará dónde nos queremos autenticar. Seleccionamos GitHub.com y presionamos ENTER.
gh auth login
# output
? ¿En qué cuenta quieres iniciar sesión? [Use las flechas para moverse, escriba para filtrar]
> GitHub.com
GitHub Enterprise Server
Se nos preguntará qué protocolo de seguridad preferimos usar cuando usamos Git: para simplificar, elegimos HTTPS .
? ¿Cuál es su protocolo preferido para las operaciones de Git? [Use las flechas para moverse, escriba para filtrar]
> HTTPS
SSH
Se nos preguntará si queremos autenticarnos con las credenciales de GitHub. Respondemos "S" y se nos preguntará cómo queremos autenticarnos: seleccionamos con el navegador y se abrirá automáticamente, o se nos mostrará un enlace para ir. Además de introducir la contraseña de GitHub también tendremos que añadir un código desechable (código de un solo uso) que nos proporcionará la CLI.
? ¿Autenticar Git con tus credenciales de GitHub? (T/n)
> Y
? ¿Cómo le gustaría autenticar la CLI de GitHub? [Use las flechas para moverse, escriba para filtrar]
> Iniciar sesión con un navegador web
Pegar un token de autenticación
! Primero copie su código único: XXXX-XXXX
Presiona Enter para abrir github.com en tu navegador...
Insertamos el código desechable (código de un solo uso):
Autorizamos la CLI de GitHub:
Ingresamos nuestra contraseña de GitHub y finalmente obtenemos este mensaje
Comandos Git
Antes de hablar sobre cómo usar Git en la práctica, debemos familiarizarnos con sus comandos principales. ¡Usar Git no es difícil, pero hay toneladas de funciones para conocer y dominar! Intentemos hacernos una idea de todo lo que podemos hacer con Git viendo en detalle el funcionamiento de los siguientes comandos:
git init
git add
git commit
git log
git push
git pull
git fetch
git clone and forks
git branch and git checkout
git merge
git status
git revert
git reset
Después de ver una descripción general de los comandos más comunes, veremos ejemplos concretos de cómo usarlos. Es posible que deba revisar los diversos comandos varias veces para comprender cómo funcionan en detalle. Sin embargo, como se especifica al principio del artículo, muchos de estos serán más fáciles de memorizar después de experimentar. Así que recuerda usar esta sección como referencia.
El comando git init
El comando git init se usa para inicializar un nuevo repositorio Git vacío en el directorio actual. Cree un nuevo directorio .git (oculto) que contenga todos los archivos de configuración y los metadatos necesarios para administrar el repositorio.
git init
Una vez inicializado el repositorio, podemos agregar archivos usando el comando git add.
El comando git add
El comando git add se usa para agregar los cambios a la próxima confirmación. Como veremos en breve, las confirmaciones son una especie de "instantánea" del repositorio y describen los cambios que hemos realizado. Estos cambios pueden afectar a todo el proyecto, como cambios de código, creación o eliminación de nuevos archivos o carpetas, etc., y el comando no los guarda directamente en el repositorio local o remoto, sino que los prepara añadiéndolos a un "staging". área", es decir, una especie de "área temporal". Una vez que agregue sus cambios a esta área, puede confirmar.
Para agregar archivos específicos al área de ensayo, usamos el siguiente comando:
git add nome_file
Para agregar todos los archivos de proyecto (nuevos o modificados) al área de preparación:
git add .
se recomienda usar el comando git add de forma selectiva, agregando solo aquellos archivos que se han modificado o agregado y que deben incluirse en la próxima confirmación, ya que son parte del mismo conjunto de cambios del proyecto.
El archivo .gitignore
Para excluir archivos y carpetas contenidos en el proyecto de la acción de git add, debemos crear un nuevo archivo llamado .gitignore e insertar todo lo que no queremos incluir en el repositorio, como archivos JSON que contienen contraseñas, carpetas de entornos virtuales , archivos de caché, etc. Los archivos enumerados en .gitignore no se sincronizarán con el repositorio remoto.
En este este repositorio de GitHub puede encuentre una colección de plantillas .gitignore para insertar en sus proyectos en función del lenguaje de programación que utilice: por ejemplo, este es el de Python, por lo tanto configurado para excluir archivos y carpetas comunes a los proyectos creados con este lenguaje:
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
# C extensions
*.so
# Distribution / packaging
.Python
build/
develop-eggs/
dist/
downloads/
eggs/
.eggs/
lib/
lib64/
parts/
sdist/
var/
wheels/
share/python-wheels/
*.egg-info/
.installed.cfg
*.egg
MANIFEST
# PyInstaller
# Usually these files are written by a python script from a template
# before PyInstaller builds the exe, so as to inject date/other infos into it.
*.manifest
*.spec
# Installer logs
pip-log.txt
pip-delete-this-directory.txt
# Unit test / coverage reports
htmlcov/
.tox/
.nox/
.coverage
.coverage.*
.cache
nosetests.xml
coverage.xml
*.cover
*.py,cover
.hypothesis/
.pytest_cache/
cover/
# Translations
*.mo
*pot
# Django stuff:
*.log
local_settings.py
db.sqlite3
db.sqlite3-journal
# Flask stuff:
instance/
.webassets-cache
# Scrapy stuff:
.scrapy
# Sphinx documentation
docs/_build/
# PyBuilder
.pybuilder/
target/
# Jupyter Notebook
.ipynb_checkpoints
# IPython
profile_default/
ipython_config.py
# pyenv
# For a library or package, you might want to ignore these files since the code is
# intended to run in multiple environments; otherwise, check them in:
# .python-version
# pipenv
# According to pypa/pipenv#598, it is recommended to include Pipfile.lock in version control.
# However, in case of collaboration, if having platform-specific dependencies or dependencies
# having no cross-platform support, pipenv may install dependencies that don't work, or not
# install all needed dependencies.
#Pipfile.lock
# poetry
# Similar to Pipfile.lock, it is generally recommended to include poetry.lock in version control.
# This is especially recommended for binary packages to ensure reproducibility, and is more
# commonly ignored for libraries.
# https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control
#poetry.lock
# pdm
# Similar to Pipfile.lock, it is generally recommended to include pdm.lock in version control.
#pdm.lock
# pdm stores project-wide configurations in .pdm.toml, but it is recommended to not include it
# in version control.
# https://pdm.fming.dev/#use-with-ide
.pdm.toml
# PEP 582; used by e.g. github.com/David-OConnor/pyflow and github.com/pdm-project/pdm
__pypackages__/
# Celery stuff
celerybeat-schedule
celerybeat.pid
# SageMath parsed files
*.sage.py
# Environments
.env
.venv
env/
venv/
ENV/
env.bak/
venv.bak/
# Spyder project settings
.spyderproject
.spyproject
# Rope project settings
.ropeproject
# mkdocs documentation
/site
# mypy
.mypy_cache/
.dmypy.json
dmypy.json
# Pyre type checker
.pyre/
# pytype static type analyzer
.pytype/
# Cython debug symbols
cython_debug/
# PyCharm
# JetBrains specific template is maintained in a separate JetBrains.gitignore that can
# be found at https://github.com/github/gitignore/blob/main/Global/JetBrains.gitignore
# and can be added to the global gitignore or merged into this file. For a more nuclear
# option (not recommended) you can uncomment the following to ignore the entire idea folder.
#.idea/
Al crear un nuevo repositorio directamente desde GitHub, como veremos al final del artículo, tendrá la posibilidad de elegir un archivo .gitignore apropiado.
Cómo eliminar un archivo del área de ensayo
A veces, agrega un archivo con git add y luego se da cuenta de que no desea incluirlo en la confirmación. En ese caso, podemos usar el comando git reset para deshacer la adición del archivo especificado:
git reset nome_file
El comando git reset también tiene otros usos, pero en este caso hace exactamente lo contrario de lo que hace git add. Si usamos el comando sin ningún parámetro opcional, todos los archivos que se encuentran actualmente en el área de preparación (el área temporal) se eliminarán. Sin embargo, cualquier cambio realizado en el proyecto o en el contenido de los archivos no se deshará y, por lo tanto, se puede "volver a agregar" con git add.
El comando git commit
Una de las características más útiles e importantes de Git son las confirmaciones. Una confirmación representa un único cambio realizado en el contenido del proyecto. Por lo general, estos cambios serán textuales, como la actualización del código fuente de un archivo .py o .js, pero también pueden representar la adición o eliminación de otros tipos de archivos, como imágenes en un sitio web. Cuando crea una confirmación en Git, selecciona los archivos que desea incluir y agrega un mensaje que describe los cambios que ha realizado.
git commit -m "mensaje"
ejemplo:
Cuando se crea la confirmación, Git crea un hash único para identificarla a través del algoritmo SHA, que asocia una cadena de 40 caracteres con cada confirmación en el repositorio.
Cómo escribir el mensaje de confirmación
Elegir con cuidado el mensaje que describe el commit es fundamental para la gestión del repositorio, tanto para nosotros que lo escribimos, como para los que posiblemente estemos trabajando en nuestro propio proyecto y tengamos que leerlo. Un mensaje de confirmación preciso y claro facilita la comprensión de los cambios realizados y por qué se realizaron. ¡Esto podría resultar increíblemente útil no solo cuando colaboramos con otros, sino también al depurar nuestro propio código! Pero, ¿cómo se escribe un buen mensaje de compromiso?
Preferiblemente en inglés: es el idioma predominante en el mundo y es más fácil hacerte entender por todos, especialmente si colaboras en un proyecto con personas de diferentes partes del mundo.
Debe comenzar con una palabra clave explicativa que describa el tipo de cambio que está implementando. Algunas de las palabras clave más utilizadas son: Agregar, Fusionar, Arreglar, Quitar, Actualizar, Cambiar, Refactorizar, Ocultar, Probar, etc.
Se debe utilizar el presente de indicativo: por ejemplo escribimos “Add” y no “Added”.
Debe ser específico: debe describir exactamente qué cambios ha realizado y nunca debe ser genérico o vago como "Actualizaciones varias". Por ejemplo, podríamos escribir una confirmación como "AÑADIR el método get_URL a la clase de vista" o "Agregar el método get_URL a la clase de vista".
Debe ser conciso y directo, evitando información innecesaria o detalles irrelevantes.
Sin embargo, tenga en cuenta que cada proyecto o equipo de trabajo de código abierto podría tener pautas de referencia que siempre prevalecen.
El comando de registro de git
Para ver el historial de confirmaciones de un repositorio, podemos ir al sitio de alojamiento que lo aloja, como GitHub, o usar directamente el comando git log:
git log
El comando nos mostrará en la terminal una lista de las confirmaciones en el orden en que se realizaron, junto con metadatos relacionados como autor, fecha, mensaje de confirmación y hash:
El comando git push
El comando git push se usa para enviar confirmaciones locales a un repositorio remoto. Con este comando actualizamos los archivos contenidos en el repositorio con los cambios que hemos realizado localmente y nos aseguramos de que el resto de miembros del equipo con los que posiblemente estemos colaborando puedan acceder a ellos e integrarlos con su versión de código.
Si no usamos este comando, los cambios realizados se mantendrán solo en el repositorio local y no serán accesibles de forma remota.
git push
Al ejecutar el comando git push en un repositorio que no es propiedad del usuario, debe tener permisos de acceso: si lo ejecutamos sin tener permisos de escritura, el comando git push devolverá un error y no enviará los cambios. En este caso, puede ser necesario bifurcar el repositorio y enviar una solicitud de extracción para solicitar (¡o sugerir!) la integración de los cambios: veremos en breve lo que esto significa.
El comando git pull
El comando git pull realiza la operación opuesta a git push: se usa para obtener los cambios del repositorio remoto e integrarlos con el repositorio local para tener la última versión del proyecto.
git pull
Si no usamos el comando cuando trabajamos en un proyecto en colaboración con otros, el repositorio local puede quedar obsoleto en relación con el remoto y pueden ocurrir cambios conflictivos.
¿Qué es una solicitud de extracción?
Cuando queremos contribuir a un repositorio que no nos pertenece, podemos bifurcar el repositorio, hacer los cambios necesarios y luego enviar una solicitud de extracción al propietario del repositorio original. Este último puede examinar los cambios, discutir cualquier problema y decidir si acepta o no: si se acepta la solicitud de extracción, los cambios se integran en el repositorio original.
El comando de búsqueda de git
Hemos visto que el comando git pull sincroniza el repositorio remoto con el que tenemos localmente. Si solo queremos descargar y ver los cambios sin aplicarlos automáticamente, usamos el comando git fetch:
git fetch
Si aceptamos los cambios y queremos aplicarlos a la copia local simplemente podemos usar el comando git pull.
El comando git clone y bifurcaciones
El comando git clone le permite descargar el repositorio completo desde el repositorio remoto y crear una copia local en su computadora. Esta copia incluirá todos los archivos, el historial de confirmaciones y la información de configuración en cualquier punto del desarrollo del proyecto. Puedes usar el comando git clone tanto en tus propios repositorios como en los públicos de otros desarrolladores.
Al usar el comando, debe especificar la URL del repositorio remoto que desea clonar. Por ejemplo, creemos una copia local del repositorio "jerry" desde el remoto en GitHub:
git clone https://github.com/username/jerry.git
En GitHub podemos obtener el comando descrito anteriormente de forma automática, haciendo clic en el botón verde correspondiente.
Cuando clonas un repositorio, se crea un enlace entre el repositorio local y el remoto, identificado por el nombre origen (en italiano "origen"), que es el término utilizado para referirse al repositorio remoto desde el cual se clonó el repositorio local. Podrá navegar por el código y los archivos del proyecto, así como ejecutar el código, como si estuviera en la computadora del desarrollador.
Los tenedores
Si cree que un proyecto público desarrollado por otros desarrolladores es particularmente interesante y tiene la intención de realizar cambios personales y luego guardarlos, por ejemplo para asegurarse de que el código de un proyecto de código abierto se adapte a su caso de uso específico, usted puede crear una bifurcación (una "bifurcación") del proyecto. El fork es una copia independiente del repositorio y se combinará con tu perfil de GitHub, desde donde podrás acceder a él.
El usuario que bifurcó el repositorio ahora puede trabajar en su copia, crear nuevas ramas y realizar cambios en ellas sin tener que notificar a los creadores del proyecto original.
Si tiene la intención de compartir sus cambios con el proyecto original para que se fusionen en la rama principal del proyecto bifurcado (la rama principal), puede enviar una solicitud de incorporación de cambios a los creadores del proyecto original. Con este proceso es posible colaborar en equipos incluso para proyectos de desarrollo muy grandes:
Bifurca el proyecto en GitHub
Clone el repositorio de la bifurcación en su computadora
Cree una rama para realizar cambios en
Confirmar los cambios en la rama
Publique los cambios en la rama de su bifurcación a través de push
Abrir una solicitud de extracción
Nota: Es importante seguir siempre las recomendaciones y pautas específicas para cada proyecto antes de proponer cambios para agregar al repositorio original.
Los comandos git branch y git checkout
Al igual que las confirmaciones, las ramas son otro concepto fundamental de git. Una rama (en italiano "ramo") es una línea de desarrollo separada dentro de un repositorio y le permite realizar cambios sin afectar el código principal, que generalmente se considera el más estable y adecuado para su uso en producción.
Cuando se trabaja en un proyecto complejo, varios desarrolladores pueden desarrollar simultáneamente varias funciones o correcciones de errores. Para evitar interferir con el trabajo de otros o para probar de forma segura posibles actualizaciones, es posible crear una rama separada de la rama principal para cada nueva función o corrección de errores: de esta manera, todos los cambios realizados en esa rama están separados de los realizados. a los demás. main o master son los nombres predeterminados dados a la rama principal de los proyectos.
Por ejemplo, para crear una rama separada para implementar la función X, escribimos:
git branch feature-X
Después de usar el comando git branch como se muestra arriba, al intentar ejecutar el comando git status (que veremos en detalle más adelante) nos daremos cuenta de que todavía estamos en la rama principal main.
Para movernos a esta nueva rama podemos usar el comando git checkout:
git checkout feature-X
Al emitir el comando de estado de git, ahora veremos que está en la rama de función X, y cualquier compromiso ahora se comparará con esta línea de desarrollo separada.
De esta forma, los desarrolladores pueden trabajar de forma independiente en sus ramas de desarrollo sin interferir con el trabajo de los demás. Una vez que se completa el trabajo, la rama de desarrollo se puede fusionar con la rama principal a través del comando git merge.
El comando git merge
Para combinar los cambios de dos ramas en una, usamos el comando merge.
Para realizar una fusión, debemos decirle al comando qué rama queremos fusionar con la que estamos trabajando actualmente. Por ejemplo, si estamos en main, podemos fusionar la rama feature-X enviando el comando:
git merge feature-X
Por lo general, desarrolla los cambios en una rama aislada y cuando llega a un punto en el que se siente satisfecho con el código escrito, porque es funcional y estable, pasa a la rama principal y realiza la fusión.
Git intentará fusionar sus cambios automáticamente, esperando implícitamente un cierto nivel de disciplina y rigor en el proceso de desarrollo. Sin embargo, en caso de que surjan conflictos, porque tal vez dos ramas estén trabajando en los mismos archivos al mismo tiempo, Git solicita al usuario que los resuelva manualmente eligiendo qué cambio conservar y cuál descartar.
El comando de estado de git
Podemos ver el estado del repositorio Git usando el comando git status, que nos permite acceder a diversa información sobre nuestro repositorio, incluyendo:
La rama actual y la confirmación más reciente.
Archivos que se han modificado pero aún no se han agregado al área de ensayo.
Archivos que se agregaron al área de preparación, pero que aún no se confirmaron.
Archivos que se han eliminado del directorio de trabajo, pero que aún no se han eliminado del área de preparación.
El comando es esencial para realizar un seguimiento de los cambios realizados en los archivos del repositorio y para comprobar el estado actual de la rama. Por ejemplo, si no hemos cambiado ningún archivo, el estado de git solo nos dirá en qué rama estamos:
En rama principal
Su sucursal está actualizada con 'origen/principal'.
nada que cometer, árbol de trabajo limpio
Si por el contrario modificamos un archivo, nos dirá información sobre el archivo y sobre la modificación:
On branch main
Su sucursal está actualizada con 'origin/main'.
Cambios no organizados para la confirmación:
(use "git add ..." para actualizar lo que se confirmará)
(use "git restore ..." para descartar cambios en el directorio de trabajo)
modificado: README.md
no se agregaron cambios para confirmar (use "git add" y/o "git commit -a")
El comando git revert
Hemos dicho que una de las mayores comodidades de Git es poder deshacer los cambios realizados previamente en un repositorio: para ello, usamos el comando git revert. El comando no elimina la confirmación anterior, sino que crea una nueva que deshace los cambios realizados: el historial de confirmación permanece intacto y la confirmación original permanece en el repositorio.
Para usar el comando git revert, debemos especificar el hash de la confirmación que queremos deshacer. Por ejemplo, para cancelar el compromiso con el hash xyzt421, ejecutamos el siguiente comando:
git revert
Git abrirá un archivo de texto para insertar un mensaje de confirmación y, cuando se guarde, creará una nueva confirmación que deshace los cambios realizados en la confirmación especificada.
El comando git reset
Cuando hablamos sobre el comando git add, vimos que el comando git reset se usa para eliminar archivos del área de ensayo. Este comando también tiene otros usos: podemos usarlo para deshacer las últimas confirmaciones que ya hemos enviado, mover una rama a una confirmación anterior, restaurar un archivo y mucho más. Por ejemplo, para deshacer la última confirmación realizada en la rama actual y mantener los cambios realizados en los archivos, podemos usar git reset de la siguiente manera:
git reset HEAD~1
De esta manera podemos hacer correcciones al compromiso deshecho y luego hacer un nuevo compromiso con los cambios corregidos.
El archivo HEAD
En los comandos y en el registro hemos visto que se usa el término HEAD: es un archivo contenido en la carpeta del repositorio .git que representa una referencia a la rama en la que nos encontramos actualmente. Si estamos en la rama principal, esto Sea el contenido de HEAD:
ref: refs/cabezas/principal
Si cambiamos de sucursal, la referencia cambiará:
ref: refs/heads/main
Ejemplos de uso de Git
Ahora veamos una serie de usos comunes de Git y GitHub. Nos encontraremos haciendo estas operaciones muy a menudo si decidimos utilizar Git como sistema de control de versiones:
Crear un nuevo repositorio en GitHub
Hacer un compromiso
Descargar cambios desde un repositorio remoto
Crear una nueva sucursal
Fusionar una rama
Crear un nuevo repositorio en GitHub
Vaya al sitio de GitHub y haga clic en + en la barra de navegación en la parte superior derecha de la página y seleccione el elemento "Nuevo repositorio". Elegimos un nombre para nuestro repositorio (en este caso lo llamé dzoRepo) y si hacerlo público o privado.
Como ves, también tenemos la opción de generar automáticamente un archivo README.md y un archivo .gitignore compatibles con el tipo de proyecto que estemos desarrollando. También tienen la opción de elegir un tipo de licencia de código abierto.
Una vez configurados los parámetros que consideramos más oportunos pulsamos en el botón "Crear repositorio".
GitHub en este punto mostrará una pantalla con varios comandos. Simplemente podemos clonar el repositorio, configurarlo como host remoto para un repositorio que ya está en nuestro sistema y más.
cómo-usar-git-github-24
El flujo de trabajo de uso más común implica usar el comando git clone en la URL del repositorio recién creado en GitHub. Una vez que el proyecto se ha clonado en nuestra computadora, podemos comenzar a escribir código con una progresión de confirmaciones, que luego también se pueden cargar en GitHub a medida que realizamos nuevos cambios.
Sin embargo, si es nuevo en el uso de git, es probable que tenga archivos de borrador más o menos desarrollados que puede usar como punto de partida para su nuevo proyecto y que necesita agregar a su proyecto.
Supongamos que tenemos un script simple llamado factorial.py que contiene una función que encuentra el factorial de un número:
import math
def factorial(n):
if n == 0:
return 1
else:
return n * factorial(n-1)
n=10
print(factorial(n))
Como ya tenemos archivos que sabemos que seguramente necesitaremos, antes de ejecutar el comando git clone en nuestro repositorio, comenzando desde la misma pantalla con todos los comandos mostrados por GitHub que acabamos de ver, haga clic en "cargar un archivo existente" para acceder a una pantalla de carga de archivos con arrastrar y soltar.
Arrastre y suelte el archivo factorial.py para cargarlo. Luego haga clic en el botón verde "confirmar cambios".
Captura de pantalla de la carga de archivos de GitHub
Ahora solo tenemos que descargar el repositorio correctamente inicializado, abrir la carpeta recién descargada en un editor de texto y comenzar a desarrollar:
Hacer un compromiso
git clone https://github.com/dzosoft/dzoRepo.git
Modifiquemos la copia local de nuestro archivo factorial.py de alguna manera. Agregué una línea de código para solicitar un número como entrada del usuario.
n=int(input("Ingrese un número para calcular el factorial: "))
Ahora, si ejecutamos el comando git status desde dentro de la carpeta del repositorio, el resultado nos dirá que el archivo se modificó pero aún no se agregó al área de preparación:
On branch main
Su sucursal está actualizada con 'origin/main'.
Cambios no organizados para la confirmación:
(use "git add ..." para actualizar lo que se confirmará)
(use "git restore ..." para descartar cambios en el directorio de trabajo)
modificado: factorial.py
no se agregaron cambios para confirmar (use "git add" y/o "git commit -a")
Así que agreguemos nuestro archivo al área de preparación con el comando git add:
git agregar factorial.py
Ahora el comando de estado de git nos dirá que el archivo se agregó al área de preparación y está listo para confirmar:
En rama principal
Su sucursal está actualizada con 'origen/principal'.
Cambios a realizar:
(use "git restore --staged ..." para quitar la preparación)
modificado: factorial.py
Si estamos satisfechos con los cambios que hemos realizado, podemos confirmar. Usamos el comando git commit agregando el indicador "-m" y escribimos el mensaje de confirmación directamente desde la línea de comando. Recuerda que el mensaje de confirmación siempre debe describir los cambios realizados de forma breve pero efectiva.
git commit -m "Agregue la entrada del usuario para tres números usando la función de mapa"
Para actualizar el repositorio remoto con los cambios que hemos realizado, emitimos el comando git push. Volviendo a GitHub y explorando el repositorio, ahora notaremos que los cambios también se han guardado de forma remota.
Descargar cambios desde un repositorio remoto
Teniendo en cuenta lo que hemos dicho hasta ahora, especialmente en lo que respecta al desarrollo colaborativo, es probable que piense que el repositorio de GitHub podría estar más actualizado que el presente en nuestra computadora. Ahora veremos cómo descargar los cambios del repositorio remoto y aplicarlos al local, creando un nuevo archivo Markdown directamente desde GitHub como ejemplo.
Cada repositorio debe tener un archivo README.md dentro: su objetivo principal es describir el proyecto, sus características y proporcionar instrucciones para instalar el software. El archivo aparecerá automáticamente en la página de inicio del repositorio y cualquier persona con acceso podrá leerlo.
Creamos el archivo README.md directamente desde GitHub presionando el botón etiquetado como "Add File" dentro del repositorio, nos encontraremos frente a esta pantalla:
Escribimos el mensaje de confirmación y presionamos la tecla verde: ¡ahora en el repositorio remoto hay un archivo que no tenemos localmente! ¿Qué hacer para poder tenerlo localmente?
Como habrás adivinado en este punto, emitimos el comando git pull: el archivo se descargará y nos sincronizaremos con el repositorio remoto.
Editemos README.md nuevamente desde la interfaz de GitHub abriéndolo y presionando el lápiz:
Modificamos el archivo de cualquier forma y describimos nuestra modificación en el mensaje de confirmación.
Ahora que sabemos que queremos integrar los cambios realizados en GitHub, si ejecutamos el comando git pull como ya hemos visto en los ejemplos anteriores, nuestro repositorio local se sincronizará con el remoto.
Crear una nueva sucursal
Creemos una nueva rama para nuestro repositorio dzoRepo. Llamémoslo “implementación de chatgpt” porque la funcionalidad que queremos implementar en el futuro será usar el chatGPT:
git branch chatgpt-implementación
Todos los cambios que hemos realizado hasta ahora se han subido a la rama principal, es decir, a main. Vayamos a la rama que acabamos de crear así:
git checkout chatgpt-implementación
Alternativamente, podemos crear una nueva rama y cambiar automáticamente a ella con un solo comando agregando el indicador -b:
git checkout -b chatgpt-implementación
Para publicar la rama en el repositorio remoto emitimos el siguiente comando:
git push origen chatgpt-implementación
Ahora podemos trabajar en la rama sin que nuestros cambios afecten a la principal. Modifiquemos nuestro código, por ejemplo, insertando una declaración de importación. Si enviamos el commit al repositorio remoto, al abrirlo veremos esta pantalla:
Entonces, nuestro cambio también se guardó en la rama que creamos en el repositorio de forma remota. Ahora podemos fusionar e integrar el cambio en la rama principal directamente desde aquí presionando el botón verde "Comparar y solicitar extracción" o desde la terminal, veamos cómo.
Fusionar una rama
Hagamos otro cambio a nuestro código agregamos algunos comentarios. Escribimos un mensaje de confirmación apropiado e impulsamos nuestros cambios, en mi caso será "Eliminar anotaciones de tipo de los argumentos de la función".
Ahora intentemos fusionar nuestra rama con main. Ya que estamos en la rama que queremos fusionar, cambiemos a la rama principal y luego ejecutemos el comando de fusión.
git pago principal
Implementación de git merge chatgpt
Finalmente, enviamos el comando para sincronizar los commits en la rama local con la remota:
empujar git
¡Ahora los cambios realizados en la rama se integrarán en la rama principal!
Con este artículo solo hemos comenzado a explorar las características de Git: son realmente muchas y para obtener una descripción completa, puede consultar la documentación.
Con lo que hemos visto juntos deberías haberte hecho una idea de la funcionalidad de Git y GitHub, pero descubrirás muchas cosas a medida que las utilices para tus proyectos. Si lo desea, también puede encontrar una guía súper detallada en el sitio web oficial, ¡completa con videos en inglés!
ES 
English - EN 
Français - FR 
:
