Git. Empezar a trabajar con repositorios
Resumen de los principales comandos a utilizar para crear repositorios y empezar a trabajar con ellos.
Crear un repositorio local
Si queremos aplicar un control de versiones con git a un proyecto que tengamos en nuestro equipo debemos ubicarnos en la carpeta en la que se ubica dicho proyecto, mediante línea de comandos, y ejecutar el siguiente comando:
git init -b mainComo resultado de este comando encontraremos una carpeta oculta denominada .git en la carpeta del proyecto, que le servirá a git para llevar a cabo el control de versiones. De esta forma, hemos convertido una carpeta de nuestro equipo, a la que llamaremos Working Directory, en un repositorio que reside localmente en nuestro equipo y que no está conectado con ningún repositorio remoto ubicado en algún servidor externo, ya sea GitHub, GitLab, Bitbucket o el servidor de nuestra empresa. Un repositorio local nos puede servir para llevar un registro de los cambios realizados en un proyecto y poder recuperar una determinada versión anterior, ya sea porque los últimos cambios han provocado errores o porque queramos retomar el proyecto en algún punto determinado anterior. Además, podemos crear diferentes ramas en las que trabajar siguiendo líneas de trabajo diferentes.
El parámetro -b main se ha utilizado para nombrar como main a la rama principal del proyecto.
Para que los archivos existentes en un directorio de trabajo (Working Directory) empiecen a ser controlados por git debemos ejecutar:
git add <nombre_archivo>Este comando añade un archivo a un área controlada por git denominada Stage. Este área, a veces denominada también como index, podemos verla como una zona intermedia o área de preparación en la cual se realiza un seguimiento de los cambios que se van produciendo en los ficheros añadidos en ella. No estamos obligados a indicar los nombres de ficheros que queremos controlar de uno en uno. Podemos indicar el nombre de una carpeta y se añadirá todo el contenido de la misma. Además, si nos ubicamos en la raíz del directorio de trabajo y ejecutamos git add . se añadirán todos los ficheros del directorio de trabajo. Hay que tener en cuenta que si después de añadir un fichero a éste área de preparación realizamos algún cambio sobre el mismo debemos volver a ejecutar git add para tener controlada la última versión.
Si por algún motivo queremos dejar de controlar un fichero que ya ha sido añadido al stage podemos sacarlo mediante
git reset HEAD <nombre_archivo>Por otro lado, si tenemos ficheros y/o directorios que queremos que git nunca los tenga en cuenta lo más sencillo es crear un fichero denominado .gitignore e indicar el nombre de los mismos en él.
Cuando ya hayamos terminado de realizar nuestros cambios sobre los ficheros que seguimos podemos crear un punto de control con el siguiente comando:
git commit -m "Mensaje sobre los cambios realizados"mediante el cual confirmamos los cambios realizados creando una instantánea del estado actual del proyecto, es decir, creamos una versión del mismo. Esta versión se añade al History del proyecto de forma que tenemos un historial de todas las versiones que se van creando, lo cual nos permite recuperar el proyecto a cualquier punto de control confirmado. Podemos ver las confirmaciones realizadas mediante git log.
Es posible realizar la confirmación de los cambios realizados sin pasar por la fase de preparación, es decir, sin añadir previamente los archivos al área de stage, añadiendo la opción -a al comando commit.
Subir nuestro repositorio a un repositorio externo
Todo lo realizado hasta ahora se realiza a nivel local, en nuestra máquina. Si trabajamos en un proyecto en el que más gente participa lo normal es tener un repositorio de trabajo común en algún servidor que sea compartido por todos los miembros de proyecto. Cada trabajador realizará cambios localmente en su equipo y en algún momento mandará sus cambios al repositorio central para integrarlos con los cambios aportados por otros participantes del proyecto.
Otro escenario es el querer subir nuestro repositorio local a alguna cuenta que tengamos tipo GitHub, para tenerlo disponible en línea y/o compartir nuestro trabajo. En este caso, debemos crear un repositorio en el proveedor elegido con el mismo nombre que nuestro repositorio local y lo más conveniente es crearlo vacío, sin ningún documento. Debemos evitar incluir los típicos ficheros README o .gitignore que se suelen crear por defecto. Además, la rama principal de nuestro repositorio debe tener el mismo nombre que la rama principal del repositorio remoto. Por regla general, las plataformas de git existentes hoy día suelen denominar por defecto a la rama principal de un repositorio con el nombre main. Si nuestro repositorio local se inició usando el parámetro -b main no habrá problema. En caso de que nuestra rama principal tenga otro nombre (master era el nombre que solía usarse por defecto) deberemos renombrarla para que coincida con la rama remota mediante el comando:
git branch -M mainPara añadir un repositorio remoto a nuestro proyecto debemos ejecutar el siguiente comando:
git remote add origin <url_repositorio_remoto> el cual establece que podamos usar el nombre origin en lugar de la url del repositorio. Se puede utilizar cualquier nombre aunque es común nombrar como origin al repositorio remoto principal. Podemos añadir más repositorios remotos y consultar todos los que tenemos configurados mediante git remote -v, y con git remote show <nombre-repositorio> veremos informacion detallada de cada repositorio.
En este punto ya podemos enviar nuestros cambios al servidor:
git push -u origin main Enviamos al repositorio remoto nombrado como origin nuestra rama denominada main (podríamos utilizar otro remoto y/o rama).
Hay que tener en cuenta que, si el repositorio al que nos conectamos ya contiene ficheros incluidos previamente, el estado del repositorio remoto puede ser diferente al estado de nuestro repositorio local. Alguien puede haber mandado sus cambios al repositorio remoto y nosotros no tener esos cambios en el nuestro. Podemos decir que nuestro repositorio se encuentra “por detrás” del repositorio remoto. En este caso hay que descargar las confirmaciones previas y ver como llevamos a cabo su integración en nuestro repositorio.
Trabajar con un repositorio externo ya existente
La forma más rápida de obtener en nuestro equipo un repositorio remoto es realizando una copia del mismo mediante la ejecución del siguiente comando:
git clone <url_repositorio_remoto> Al clonar un repositorio con git clone, se crea automáticamente una conexión remota llamada origin que apunta al repositorio clonado. Tras realizar las modificaciones que necesitemos y cuando estemos preparados podemos integrar los nuevos cambios como hemos visto antes.
Otro forma consistiría en inicializar un repositorio en nuestro equipo sin agregar ningún documento. Después añadimos el repositorio remoto y finalmente nos descargamos su contenido con el comando pull.
git init -b main
git remote add origin <url_repositorio_remoto>
git pull origin mainRevisar la evolución de un proyecto
Para poder visualizar en que estado se encuentran los archivos de un proyecto en un momento dado, tanto localmente como respecto a los repositorios remotos utilizados, podemos ejecutar en cualquier momento el comando git status.
El histórico de confirmaciones realizadas puede consultarse mediante git log, que por defecto muestra un listado de las mismas en orden cronológico inverso. Este comando dispone de varias opciones para ajustar el criterio de búsqueda. Por ejemplo:
-nmuestra las últimas n confirmaciones (siendo n un número entero)--pretty=onelinemuestra cada confirmación en una sola línea--graphimprime un gráfico ASCII con el histórico de ramificaciones del proyecto-pmuestra las diferencias introducidas en cada confirmación--statmuestra estadísticas