Cargando

Ir a contenido


 


Administración de repositorios en Git

En este tutorial veremos cómo administrar nuestros repositorios de esta forma podremos empezar a sacar el verdadero provecho de Git para el control de cambio y versiones sobre nuestros proyectos.


Escrito por el feb 13 2015 01:01 git


Al momento en que inicializamos Git en nuestro proyecto estamos creando un repositorio, esto nos ayuda a poder mantener la traza de nuestros cambios, y nos ayuda a replicar nuestro proyecto en otra locación. Las grandes ventajas las vemos al momento de empezar a utilizar los repositorios como medios centralizados para controlar el trabajo de equipo, donde podremos tener una fuente y hacer que todos los cambios de los diferentes miembros del equipo vayan ahí.

Podremos ver cómo crear repositorios especializados para recibir los cambios y fungir como base de otros proyectos, de esta forma podremos replicar en una red local el comportamiento de servicios como GitHub o Bitbucket sin ningún inconveniente, demostrando así que estos no son necesarios si queremos implementar Git en nuestra organización.

Requisitos
Para poder llevar a cabo este tutorial debemos tener una noción de los comandos básicos de Git como lo son add, commit, push y clone, de forma que puedan ir siguiendo paso a paso los ejercicios. También es necesario que posean una instalación funcional de Git y permisos suficientes para ejecutarlo en el ordenador o computadora con el cual quieran seguir el tutorial, de esta manera se garantizan que todo funcionará correctamente.


Tipos de Repositorios


Según la función y la ubicación, tenemos dos tipos de repositorios, el repositorio actual y el repositorio remoto. Veamos a continuación de que va cada uno para entender su función dentro de la administración de nuestros proyectos.

Repositorio actual
Este es el repositorio sobre el cual trabajamos nuestro proyecto, se llama actual porque es el primero que modificaremos y generalmente está en nuestro ambiente de desarrollo, normalmente solo somos nosotros quienes lo modificamos y ejecutamos comandos contra él.

Repositorio remoto
Este es un repositorio que se encuentra separado de nuestro repositorio actual, puede estar en un equipo diferente o en el mismo equipo en el cual estamos administrando nuestro proyecto, su función consiste en ser un centro donde los diferentes miembros del equipo van a coincidir. El repositorio remoto también puede identificarse como el servicio que ofrecen sistemas como GitHub o Bitbucket donde se almacenan a través de Internet el código de nuestro proyecto, permitiendo así tener el control de las versiones y cambios de los mismos desde cualquier lugar en el podamos conectarnos.

Clonar un repositorio


Clonar es la acción de copiar un proyecto Git desde su ubicación a un directorio o carpeta que elijamos, nos permite obtener todo el proyecto incluyendo el historial de commits y cambios que ha sufrido, así como todos los archivos no incluidos en el .gitignore. El acto de clonar es la mejor forma de iniciar un proyecto cuando necesitamos trabajar sobre código ya existente, para hacerlo hay que utilizar la siguiente estructura:
git clone nombre_repositorio
Veamos un ejemplo de como podemos clonar un repositorio local, para poder llevar a cabo este ejemplo únicamente debemos tener un repositorio inicializado.

Asumamos que tenemos un proyecto llamado ejemplo1 y está en una carpeta llamada proyectos, lo que queremos es lograr obtener un clon del mismo pero en una nueva carpeta llamada clonados dentro del mismo sistema de archivos. Para lograr el objetivo debemos pararnos sobre la carpeta destino e indicar el comando git clone indicando la ruta del proyecto a clonar. En este ejemplo sería lo siguiente:
git clone ruta\proyectos\ejemplo1
Veamos como luce en nuestra consola de comandos:


Notamos como luego al listar los directorios aparece nuestra carpeta llamada ejemplo1, aquí está el proyecto clonado con todos sus commits e historial de cambios.

El origen


Al hacer un clon de nuestro repositorio inmediatamente se crea un enlace al proyecto del cual fue clonado, este es el origen y dentro de nuestro proyecto lo veremos con la palabra origin, si hacemos un cambio en el repositorio clonado y luego hacemos push al origen, el proyecto original obtendrá el cambio.

Esta es la forma en la cual podremos compartir nuestros cambios con el repositorio central, o también la forma en la cual podremos recibir las colaboraciones de otros desarrolladores en nuestro proyecto. Vamos a crear un nuevo archivo en nuestro proyecto recién clonado y luego a hacer un push al origin, luego revisaremos la carpeta original para que veamos como recibiremos el cambio. Veamos primero como luce el original de nuestro proyecto:

Tenemos un solo archivo llamado unArchivo.txt si ahora vemos el proyecto clonado notaremos que tiene dos archivos y veremos cómo hacer el push de los cambios. Si notamos el mensaje que nos arroja veremos que lo que realmente obtendremos es un error:

Esto sucede porque Git nos ayuda a mantener a raya las inconsistencias, aquí es donde aparece la figura del repositorio desnudo, es decir, un repositorio que solamente va a recibir información de otros repositorios, de esta forma se evita que cualquier persona con acceso a nuestro sistema de archivos nos haga push a nuestro proyecto, vamos entonces a replantear todo.

Primero debemos inicializar nuestro proyecto utilizando el comando bare para indicar que es un proyecto al cual podemos hacer push, y su nombre debe contener la extensión .git, vamos a re-hacer nuestro repositorio del cual clonaremos:

Ya que tenemos nuestro nuevo clon, ahora si podremos hacer un cambio y enviarlo a nuestro repositorio remoto a través del origin del clon, vamos a repetir el ejercicio de crear un archivo al hacer commit del mismo.

Ahora, si ha transcurrido el proceso de forma exitosa, nos faltaría revisar nuestro repositorio remoto del cual hicimos este clon para ver como ahora tiene el archivo nuevo del commit que hicimos push. Para ello vamos a hacer un nuevo clon de este y así podremos observar como tenemos todo lo que se ha subido al mismo.

Pudimos ver como fácilmente hemos hecho un repositorio central remoto del cual podemos crear nuevos proyectos y así mantener nuestros controles de cambios y versiones.

Crear nuestro propio origin


Hay ocasiones en las cuales nuestro repositorio nace primero y luego es que tenemos un repositorio remoto, por lo que si hacemos el ejercicio anterior probablemente nos dé un pequeño error. Para solventar este problema Git nos permite crear nuestros propios origin, es decir, podemos inicializar un repositorio bare sin ningún contenido y luego decirle a nuestro repositorio original que va a sincronizar contra este.

Puede parecer que la palabra origin no tiene más alternativas, sin embargo esta es solo un nombre, fácilmente podemos colocarle otros nombres que nos puedan dar una referencia más efectiva, para ello podemos utilizar el comando:
git remote add “nombre” “ruta”
Donde nombre será el que tendrá el remoto y ruta es la ubicación del repositorio con el cual sincronizaremos.

Hagamos un nuevo ejercicio, vamos a crear un repositorio bare totalmente vacío y luego añadiremos un nuevo remoto al último repositorio clonado con el que trabajamos en el ejercicio anterior, utilizaremos un nombre diferente de origin de forma que podamos constatar como conviven varios orígenes en un mismo repositorio. Veamos entonces el repositorio bare nuevo:


Vemos que no fue necesario colocar la terminación .git y que además no fue necesario tener un contenido previo. Ahora vamos a nuestro repositorio nuevoClonado con el cual trabajamos en el ejercicio anterior, y vamos a crear un nuevo origen llamado nuevo, veamos en la consola como luce este:

Vemos que sencillamente con hacer un push nuevo ya Git sabe a dónde debe dirigir el contenido del commit, vamos a clonar de este nuevo repositorio bare para constatar el contenido que tiene:

Con esto hemos conseguido nuestro objetivo, ahora podemos sincronizar un proyecto existente con un nuevo remoto sin ningún tipo de inconvenientes. Es muy importante que entendamos el concepto de teamwork y sincronización ya que el hecho de trabajar con Git no significa que no habrán conflictos entre los cambios del proyecto, si no que tenemos una herramienta que nos ayuda a minimizar los mismos.

Importante
Adicionalmente pudimos ver que no es necesario un servidor para tener un repositorio central de Git, es decir, podemos implementar Git en una red local sin necesidad de servicios como GitHub o Bitbucket por lo que el acceso a estos recursos no es estrictamente necesario para disfrutar del trabajo de versiones.

Con esto hemos finalizado este tutorial, como vemos la administración de repositorios de Git no es muy compleja, simplemente debemos conocer las bases y fundamentos para poder obtener estructuras que nos permitan llevar el control de nuestro trabajo.
¿Te ha gustado y ayudado este Tutorial?
Puedes premiar al autor pulsando este botón para darle un punto positivo
10
VOTA
5
100%
4
0%
3
0%
2
0%
1
0%

  Información

  •   Publicado feb 13 2015 01:01
  •   Actualizado feb 13 2015 09:12
  •   Visitas 999
  •   Nivel
    Profesional



Tutoriales Relacionados


1 Comentarios


Cesar Ortiz
feb 16 2015 22:25

Eres un experto de los buenos en temas Git entre muchos otros. Genial tutorial.

No esperes más y entra en Solvetic
Deja tus comentarios y aprovecha las ventajas de la cuenta de usuario ¡Únete!
Demuestra que eres experto!
  ESCRIBIR TUTORIAL
Suscribirse