Está en la página 1de 15

Control de versiones. Git y GitHub.

Contenidos:
1.- Introducción a GitHub.....................................................................................................................1
1.1.- Características de GitHub........................................................................................................2
1.2.- Sistema de Control de versiones..............................................................................................2
2.- Comenzando con GitHub. Crear una cuenta de GitHub.................................................................3
3.- Crear un nuevo repositorio..............................................................................................................3
4.- El entorno de desarrollo local. El gestor de versiones Git..............................................................4
4.1.- Definición y características de Git..........................................................................................4
4.2.- Buenas prácticas con Git.........................................................................................................4
4.3.- Instalación de Git.....................................................................................................................5
5.- Comandos del entorno Git..............................................................................................................5
5.1.- Configurando el entorno para el uso de Git.............................................................................6
5.2.- Definiendo la carpeta como repositorio de Git........................................................................6
5.3.- Añadiendo ficheros al proyecto...............................................................................................6
5.4.- Añadiendo ficheros al proyecto...............................................................................................7
5.5.- Observando cambios en ficheros del proyecto........................................................................8
5.6.- Filtrando elementos en los commit. El archivo .gitignore.......................................................8
5.7.- Ramas de un proyecto. Branchs..............................................................................................9
6.- Subir archivos a un repositorio alojado en GitHub.......................................................................10
6.1.- Configuración de repositorios remotos de GitHub................................................................11
6.2.- Subir actualizaciones al repositorio remoto..........................................................................12
6.3.- Descargar actualizaciones desde el repositorio remoto.........................................................13
7.- Colaboración a través de GitHub..................................................................................................14
7.1. Permitir a otros usuarios colborar en un proyecto..................................................................14
7.2.- Comenzando a colaborar en un proyecto. Clonar un repositorio..........................................14

1.- Introducción a GitHub.


GitHub es una plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de
control de versiones Git. Se utiliza principalmente para la creación de código fuente de programas,
aunque puede alojar distintos tipos de archivos.
GitHub es una compañía sin fines de lucro que ofrece un servicio de hosting de repositorios
almacenados en la nube. Esencialmente, hace que sea más fácil para individuos y equipos usar Git
como la versión de control y colaboración. El código de los proyectos alojados en GitHub se
almacena típicamente de forma pública, aunque utilizando una cuenta de pago, también permite
hospedar repositorios privados.
Cualquier persona puede inscribirse y ser hospedar un repositorio de código público completamente
gratuito, el cual hace que GitHub sea especialmente popular con proyectos de código libre. La
interfaz de GitHub es bastante fácil de usar para el desarrollador novato que quiera aprovechar las
ventajas del Git. Sin GitHub, usar un Git generalmente requiere de un poco más de conocimientos
de tecnología y uso de una línea de comando. GitHub es tan fácil de usar, que incluso algunas
personas usan GitHub para administrar otro tipo de proyectos como escribir libros, repositorios de
ejemplos y ejercicios, etc.

Carlos Moreno Martínez. Pag 1 de 15.


Control de versiones. Git y GitHub.
Como compañía, GitHub hace dinero vendiendo alojamiento para repositorios de código privado, al
igual que otros planes enfocados para negocios, que hace más fácil que las organizaciones
administren a los miembros de su equipo y su seguridad. Utilizamos GitHub de forma extensiva
aquí en Kinsta, para administrar y desarrollar proyectos internos.
El 4 de junio de 2.018, Microsoft compró GitHub por la cantidad de 7.500 millones de dólares.

1.1.- Características de GitHub.


GitHub proporciona a los usuarios una serie de servicios tales como:
• Wiki para cada proyecto.
• Página web para cada proyecto.
• Gráfico para ver cómo los desarrolladores trabajan en sus repositorios y bifurcaciones del
proyecto.
• Funcionalidades propias de una red social,
• Herramienta para trabajo colaborativo entre programadores.
• Gestor de proyectos de estilo Kanban.

1.2.- Sistema de Control de versiones.


Un Sistema de Control de Versiones (CVS - Control Version System) ayuda a los desarrolladores
llevar un registro y administrar cualquier cambio en el código del proyecto de software. A medida
que crece este proyecto, la versión de control se vuelve esencial.
Supongamos un proyecto de tal envergadura que deben trabajar un número alto de personas. Si un
desarrollador deseara trabajar en una parte en específico del código, no sería seguro o eficiente
permitir que pueda editar directamente sobre el código fuente final. Por ello, el CVS permite a los
desarrollador trabajar de forma segura a través de una bifurcación y una fusión.
Con la bifurcación, un desarrollador duplica parte del código fuente denominado repositorio. Este
desarrollador posteriormente podrá hacer cambios a esa parte del código, sin afectar al resto del
proyecto.
Una vez que el desarrollador logre que su parte del código funcione de forma apropiada, esta
persona podría fusionar este código al código fuente principal para hacerlo oficial. Todos estos
cambios luego son registrados y pueden ser revertidos si es necesario.
En el caso del software libre si un grupo de usuarios deseara seguir el proyecto por un camino
alternativo al oficial de una forma totalmente independiente y por su cuenta de forma relativamente
permanente. También podría hacer un fork (bifurcación del proyecto) con tan solo dar click en el
botón de “Fork”.
otra posibilidad es clonar un repositorio ajeno (genera una copia en tu cuenta), para eliminar algún
bug o modificar cosas de él. Una vez realizadas tus modificaciones puedes enviar un pull al dueño

Carlos Moreno Martínez. Pag 2 de 15.


Control de versiones. Git y GitHub.
del proyecto. Éste podrá analizar los cambios que has realizado fácilmente, y si considera
interesante tu contribución, adjuntarlo con el repositorio original.

2.- Comenzando con GitHub. Crear una cuenta de GitHub.


Empezaremos creando una cuenta gratuita en la plataforma. Para ello, desde un navegador de
Internet iremos a la url
https://github.com/join
y rellenamos el formulario adecuado.
El proceso de creación se realiza en tres pasos.
1. En el primero se solicita un nombre de usuario, el correo
electrónico y una contraseña.
2. En el segundo paso se solicita que tipo de cuenta se desea
crear. Nosotros escogeremos una cuenta gratuita. Como
hemos dicho antes una cuenta gratuita, permite entre
otras cosas, crear repositorios, pero no se pueden hacer
privados.
3. Al ingresar los datos se mandará un correo a la dirección
indicada que deberá ser confirmado.

3.- Crear un nuevo repositorio.


Una vez creada la cuenta de GitHub, procedemos a crear el
primer repositorio donde se almacenaran los recursos que se
desean compartir. Se puede disponer varios repositorios. Para
crear un repositorio se pulsa en la opción “Create a
repository”. Aparecerá un formulario como el de la figura.
Para crear un repositorio, se introducen los siguientes datos:
• Nombre del repositorio.
• Breve descripción del contenido.

Carlos Moreno Martínez. Pag 3 de 15.


Control de versiones. Git y GitHub.
• Si el repositorio es público o privado. Para poder general repositorios privados, es necesario
tener una cuenta premium ya que GitHub es gratuito para proyectos de software libre.
Como norma general, todos los repositorios tienen un archivo “readme” que aportan información
que los usuarios deben conocer así como una descripción mas detallada del contenido del
repositorio.
En posteriores repositorios, se usará la opción “New Repository” de la barra de herramientas.
Saliendo el formulario anterior.

4.- El entorno de desarrollo local. El gestor de versiones Git.

4.1.- Definición y características de Git.


Git es un software de control de versiones diseñado por Linus Torvalds, pensando en la eficiencia y
la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran
número de archivos de código fuente. Su propósito es llevar registro de los cambios en archivos de
computadora y coordinar el trabajo que varias personas realizan sobre archivos compartidos. Hay
algunos proyectos de mucha relevancia que ya usan Git, en particular, el grupo de programación del
núcleo Linux.
Git es un software libre distribuible bajo los términos la Licencia Pública General de GNU v2.0.
Entre las características más relevantes que podemos encuentrar en Git tenemos las siguientes:
• Fuerte apoyo al desarrollo no lineal. Es decir, que un proyecto pueda tener varias
“versiones” de si mismo en desarrollo de forma simultanea. De esta forma, las posibles
ramas pueden ser fusionadas al ser revisadas por varios programadores.
• Gestión distribuida. Git le da a cada programador una copia local del historial del
desarrollo entero, y los cambios se propagan entre los repositorios locales. Los cambios
se importan como ramas adicionales y pueden ser fusionados en la misma manera que se
hace con la rama local.
• Los almacenes de información pueden publicarse por diversos protocolos de
comunicación (http, ftp, ssh, protocolo nativo Git, etc).
• Los repositorios de otros gestores de control de versiones tales como Subversion y SVK
se pueden usar directamente con git-svn.
• Gestión eficiente de proyectos grandes, dada la rapidez de gestión de diferencias entre
archivos, entre otras mejoras de optimización de velocidad de ejecución.

4.2.- Buenas prácticas con Git.


Cada desarrollador o equipo de desarrollo puede hacer uso de Git de la forma que le parezca mas
conveniente. Sin embargo una buena práctica aceptada por los equipos de desarrollo es mantener
cuatro ramas: master, development, features, y hotfix.

Carlos Moreno Martínez. Pag 4 de 15.


Control de versiones. Git y GitHub.
• master. Es la rama principal. Contiene el repositorio que se encuentra publicado en
producción, por lo que debe estar siempre estable.
• development. Es la rama de integración, todas las nuevas funcionalidades se deben integrar
en esta rama. Después de que se corrijan los errores la rama master y development se
pueden fusionar.
• features. Nuevas funcionalidades que se añaden al proyecto. Una vez que la funcionalidad
esté desarrollada, se fusiona con la rama development, donde se integrará con las demás
funcionalidades.
• hotfix. Bugs que surgen en producción, por lo que se deben arreglar y publicar de forma
urgente. Es una rama derivada de master. Una vez corregido el error, se debe debe fusionar
con la rama master; Además, para que no quede desactualizada, se debe realizar la fusión
con development.

4.3.- Instalación de Git.


En primer lugar deberemos ir a la sitio WEB de la
aplicación (https://www.git-scm.com/) para la descarga
del software. Hay versiones disponibles para Microsft
Windows, GNU Linux, y Mac en sus versiones de 32 y
64 bits.
Ya en sitio WEB procederemos a descargar la versión
adecuada e instalarla en el equipo de desarrollo.

De esta forma se descargar el gestor de comandos de consola de Git. Git dispone adicionalmente de
versiones gráficas. Algunas son libres mientras que otras son software propietario y comercial.

5.- Comandos del entorno Git.


En un principio se pueden colocar en un repositorio
cualquier tipo de ficheros. Para realizar las pruebas
crearemos una carpeta llamada “ProyectoGit” e
inicialmente dos ficheros de texto (“primero.txt” y
“segundo.txt”), escribiendo en cada uno de los
ficheros añadiremos un pequeño texto de relleno.
En el caso de Microsoft Windows, podemos hacer click con el botón derecho del ratón y seleccionar
la opción “Git Bash Here” en el explorador de archivos desde la carpeta padre donde se aloja el

Carlos Moreno Martínez. Pag 5 de 15.


Control de versiones. Git y GitHub.
proyecto. En otros casos, incluyendo la consola Microsoft Windows, tendremos que situarnos en el
directorio de trabajo del proyecto.
En la consola de Git se aceptan los comando “pwd”,
“cd” y “ls” de Unix para comprobar la ruta actual y
listar el contenido del directorio.

5.1.- Configurando el entorno para el uso de Git.


Para empezar a usar Git, debemos configurar la
identificación de usuario. Para ello, se usa el
comando “git config”.
Como mínimo deberemos configurar nuestro nombre
y el correo electrónico para poder ser identificado en
el proyecto.
git config --global user.name "Your-Full-Name"
git config --global user.email "your-email-address"

Para comprobar la configuración del entorno podemos usar el comando

git config --list

5.2.- Definiendo la carpeta como repositorio de Git.


Lo primero que hay que hacer para trabajar con proyecto con Git es indicar que esa carpeta va a
albergar un proyecto Git. Para ello, se usa el comando desde la carpeta padre donde se va a
alojar el proyecto
git init [nombre-repositorio]
el cual crea un repositorio nuevo con el nombre indicado.
Dicho nombre será el nombre que tiene asignado el
proyecto. Al ejecutarse se crea una nueva carpeta con el
nombre del repositorio, que a su vez contiene otra
carpeta oculta llamada .git que contiene la base de datos
donde se registran los cambios en el repositorio.

5.3.- Añadiendo ficheros al proyecto.


Los ficheros de un proyecto pueden estar en tres estados
• working directory. Son ficheros que el usuario está trabajando en ellos y aun no hay
indicado que son susceptibles de añadir al repositorio.

Carlos Moreno Martínez. Pag 6 de 15.


Control de versiones. Git y GitHub.
• stagging area. Los ficheros han sido marcados para
ser incluidos en el proyecto y actualizados en el
sistema de control de versiones de Git.
• commit area. Los ficheros han incluidos en el
proyecto para que otros usuarios puedan tener
acceso a ellos.
Para comprobar el estado de los ficheros del proyecto usamos el comando
git status
Nos aparecen los siguientes datos:
• On branch master. Indica que estamos
trabajando con la rama principal (master).
• Una lista de ficheros que están en stage
(señalados en rojo).
Para añadir un fichero al proyecto usaremos el comando
git add <fichero>
En la figura se indica (color verde) que se añadido al
proyecto primero.txt mientras que segundo.txt
permanece aun espera.
Si deseamos incluir todos los ficheros que aun no
hayamos añadido, se usa el comando “git add .”.

Para eliminar un fichero del proyecto se usa el comando


git rm --cached <fichero>

5.4.- Añadiendo ficheros al proyecto.


En este momento, los ficheros están en fase de stagging. Para incluirlos en el proyecto hay que
hacer un “commit”. Para hacer esto usaremos el comando
git commit -m “mensaje”
En este momento los ficheros añadidos con el
comando “git add” son incluidos en el proyecto.
Se muestra un informe de las acciones
realizadas. Podemos ver, un registro de todos los
commit realizados mediante el comando

Carlos Moreno Martínez. Pag 7 de 15.


Control de versiones. Git y GitHub.
git log
de forma mas abreviada podemos ejecutar el comando
git log --oneline
Si se desea cambiar el mensaje del último commit
realizado se puede hacer con el comando
git commit --amend -m "mensaje"

5.5.- Observando cambios en ficheros del proyecto.


Para comprobar que cambios hay entre el fichero del entorno local de trabajo y el enviado al
repositorio se usa el comando
git diff <fichero>
Para comprobar como funciona modificaremos el fichero
primero.txt, añadiendole una linea de texto mas y
realizaremos un “git add” y un “git commit”.
A continuación, se modifica el fichero introduciendo una
linea entre ambas como se muestra en la segunda figura.
Antes de realizar el commit se desea comprobar que
modificaciones se han realizado con respecto al último
commit. Esta se información se obtiene al ejecutar el
comando
git diff primero.txt
Para interpretar los cambios se usa la siguiente nomenclatura:
• mas (+) y la linea en letras verdes. Se
añadido la linea especificada.
• menos (-) y la linea en letras rojas. Se
ha eliminado la linea.
• las dos ocurrencias una seguida de la
otra. La linea se ha modificado.

5.6.- Filtrando elementos en los commit. El archivo .gitignore.


Podemos tener en la carpeta del proyecto elementos que no deseamos que sean enviados al
repositorio como por ejemplo pruebas realizadas, notas personales, etc. Git permite filtrar que
elementos no son añadidos al repositorio en un commit general tal como se realiza con el comando
“git add .”.

Carlos Moreno Martínez. Pag 8 de 15.


Control de versiones. Git y GitHub.
Para ello, se crea dentro de la carpeta de nuestro repositorio un fichero especial llamado .gitignore.
Este es un fichero de texto que va a contener las carpetas y ficheros que no deben ser enviadas al
stage y, por tanto, no van a ser enviadas al repositorio mediante un commit. Estos archivos y
carpetas no aparecerán en la lista de actualizaciones y modificaciones.
Veamos un ejemplo, en nuestro proyecto se crea una
carpeta llamada “personal” y dentro de esta carpeta el
archivo “tercero.txt” con una linea de texto. Esta carpeta
es para uso del desarrollador y se desea que se envie nada
de lo que contiene al repositorio. Al hacer “git status”,
Git nos indica que esta carpeta no ha sido añadida al
stage.
Es importante notar que si una carpeta está vacia no
aparece como actualizable. Solo se actualizan los
fichero y las carpetas no vacias.
Para indicar que esta carpeta no debe ser enviada al
stage, por medio de un editor de texto se incluye el
nombre de la carpeta personal y se guarda con el
nombre .gitignore dentro del raiz del proyecto.
Se añade el fichero “.gitignore” y se hace un commit del
proyecto. A partir de este momento, la carpeta
“personal” y su contenido se ignorará a la hora de realizar la actualización.

5.7.- Ramas de un proyecto. Branchs.


Hasta ahora solo disponemos una única versión de nuestro proyecto (la rama master). Supongamos
ahora que necesitamos tener una versión alternativa del proyecto; por ejemplo, un cliente nos
solicita realizar una modificación especifica en un desarrollo anterior.
En dicha versión alternativa se modificaran los ficheros actuales y se pueden añadir nuevos
ficheros. Lo primero que debemos hacer es crear una nueva rama al proyecto. Esto se hace con el
comando
git branch <nombre-rama>
Al ejecutar el comando además de tener la rama “master”
tendremos la rama recién creada.
En nuestro ejemplo crearemos la rama “ramaAlternativa” con
el comando.
git branch ramaAlternativa
Para comprobar que ramas hay en el proyecto, usaremos otro comando que es

Carlos Moreno Martínez. Pag 9 de 15.


Control de versiones. Git y GitHub.
git branch
Este comando nos indica las ramas existentes, señalando con un asterisco (*) la rama que está en
uso en este momento. En la figura anterior se puede ver que la rama en uso es “master”.
Para cambiar de rama usaremos el comando
git checkout <rama-alternativa>
Con ello, la rama en uso es la indicada (en nuestro caso
ramaAlternativa).

git checkout ramaAlternativa


A partir de ahora podemos hacer los cambios que queramos en el proyecto. Por ejemplo, vamos a
añadir dos archivos a nuestro proyecto dentro de esta rama. Haciendo el correspondiente add y
commit los añadiremos la repositorio.

Una cosa importante es cada rama tiene su propia estructura de ficheros. Por ejemplo, si ahora
cambiamos de nuevo a la rama “master”, se puede ver en le explorador de archivos que se ve la
estructura de ficheros de esta rama en la cual no aparecen los ficheros “alternativo1.txt” y
“alternativo2.txt”. Al hacer un log en esta rama se puede ver que no aparece el commit realizado en
la rama “ramaAlternativa”.
git checkout master

6.- Subir archivos a un repositorio alojado en GitHub.

Carlos Moreno Martínez. Pag 10 de 15.


Control de versiones. Git y GitHub.
6.1.- Configuración de repositorios remotos de GitHub.
Una vez que hemos trabajado en local, vamos a ver como podemos subir nuestros archivos a un
repositorio alojado en el gestor de control de versiones GitHub.
Git permite la creación de una copia del repositorio en un servidor git en internet. La principal
ventaja de tener una copia remota del repositorio, a parte de servir como copia de seguridad, es que
otros usuarios pueden acceder a ella y hacer también cambios.
En primer lugar, se supone que ya se dispone de un repositorio creado a tal efecto para el proyecto.
Podemos usar el repositorio de otro usuario siempre y cuando dicho usuario nos haya dado
permiso para poder subir ficheros en el.
Para nuestro ejemplo se ha creado un repositorio que se llama igual que nuestro proyecto. Al
crearlo, se nos proporciona la url del proyecto que usaremos para referenciarlo.

Para indicar que usuarios pueden colaborar en el proyecto debemos indicarlo en la parte “Settings”
y “Collaborator” del repositorio. Aquí iremos indicando a través de su nombre de usuario GitHub o
su mail que usuarios pueden hacer aportaciones al proyecto.

Dado que es un repositorio público, cualquier persona puede tener acceso de lectura a los ficheros
del proyecto.
En primer lugar debemos indicar que el proyecto local está relacionado con el repositorio remoto
alojado en GitHub. Para ello, ejecutamos el comando
git remote add <nombre-repositorio-remoto> <url>
En nuestro caso será al repositorio remoto lo hemos llamado “origin”.

Carlos Moreno Martínez. Pag 11 de 15.


Control de versiones. Git y GitHub.
git remote add origin https://github.com/cmmprofesor/ProyectoGit.git
dado que podemos estar trabajando en varios proyectos simultaneamente, Git tiene la capacidad de
conocer varios repositorios remotos. Para conocer que repositorios remotos tenemos configurados
en nuestro entorno tenemos el coomando “git remote”. Este comando tiene dos formas:
git remote : Muestra los nombre de los repositorios remotos configurados.
git remote -v : Muestra los nombres y las url de los repositorios remotos.

6.2.- Subir actualizaciones al repositorio remoto.


Posteriormente, podremos subir al repositorio los fichero de una determinada rama con
git push -u <nombre-repositorio-remoto> <rama>
En nuestro caso, vamos a subir los de la rama “master”. Para ello, usaremos el comando
git push -u origin master
Se abrirá una ventana en la cual nos pediran que nos identifiquemos trás la cual se realizará la
conexión y actualización remota.

Si accedemos a la página del repositorio, podemos ver los cambios efectuados por nosotros.

Carlos Moreno Martínez. Pag 12 de 15.


Control de versiones. Git y GitHub.

6.3.- Descargar actualizaciones desde el repositorio remoto.


Para obtener los cambios realizados por otros usuarios, se usa el comando “pull”. La forma de
usarlo es análogo al comando anterior: se especifica el repositorio remoto y la rama donde se
depositan los cambios.
git pull -u <nombre-repositorio-remoto> <rama>
En nuestro caso, hemos generado desde el sitio WEB de GitHub un documento en formato
MarkDown llamado “README.md”. Para actualizar los cambios realizamos el comando
git pull -u origin master

Tras solicitar nuestro usuario y contraseña, se descargaran las diferencias y el fichero anteriormente
citado aparecerá en la carpeta del proyecto.

El método de trabajo recomienda realizar un pull de las actualizaciones del proyecto antes de
empezar la sesión de trabajo y posteriormente, una vez realizado cambios hacer un push en el
repositorio del proyecto.

Carlos Moreno Martínez. Pag 13 de 15.


Control de versiones. Git y GitHub.
7.- Colaboración a través de GitHub.

7.1. Permitir a otros usuarios colborar en un proyecto.


Hasta ahora hemos realizado nuestro ejemplos usando un repositorio propio. Sin embargo, no suele
ser la filosofía de los sistemas de control de versiones ya que estos se suelen usar para permitir la
comunicación de varias personas.
En el caso de GitHub, uno de los usuarios va a participar en el proyecto en calidad de coordinador
del proyecto. Este usuario va a ser el encargado de generar el proyecto en su cuenta de GitHub.
Posteriormente, debe indicar a GitHub que usuarios pueden paritcipar en el proyecto. Para ello, los
proyectos de GitHub tienen un apartado donde se puede indicar esta característica. Este apartado
está en la seeción “Collabotors” dentro de “Settings”.

En este formulario, el coordinador del proyecto irá indicando el usuario ó la dirección de correo
electrónico de las distintas personas que participaran en el proyecto. Es evidente que dichas
personas deben de tener una cuenta en GiHub para poder participar.
Una vez enviadas las peticiones, los
participantes deben aceptar la invitación de
acceso al repositorio.
Para ello, el colaborador debe acceder a la
sección de “Notifications”, mediante el
símbolo de la campana situado en la esquina
superior derecha. Aparecerá un mensaje que ha
sido invitado a participar en un proyecto y, al aceptar la invitación, se convertirá en participante en
dicho proyecto.

7.2.- Comenzando a colaborar en un proyecto. Clonar un repositorio.


Una vez que un usuario se ha unido a un proyecto, debe descargar una copia del repositorio para
comenzar a trabajar .

Carlos Moreno Martínez. Pag 14 de 15.


Control de versiones. Git y GitHub.
Una posibilidad es crear el proyecto en la carpeta local (init), configurar el repositorio remoto
(remote) y posteriormente realizar un volcado de los datos (push).
Hay otra posibilidad que se conoce como “clonar un repositorio”. Para clonar el repositorio se
debe ejecutar el comando
git clone <url> <directorio local>
Con el comando clone, se realiza una copia de toda la estructura del fichero a una carpeta local.
Para realizar un “clone” no es necesario crear antes el proceso de creación del proyecto en local.
Esto es útil para cuando simplemente se desea descargar el contenido y usarlo a nivel personal. Esta
práctica está muy difundida en proyectos de software libre en los que los autores depositan en
repositorio tanto los paquetes de instalación, como las fuentes y la documentación.
Es importante saber que si se desea participar en el proyecto, se debe haber creado el proyecto
en local como hemos explicado con anterioridad.

Carlos Moreno Martínez. Pag 15 de 15.

También podría gustarte