Archivo de la etiqueta: control de versiones

Control de Versiones con GIT

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.

Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del inglés Version Control System). Estos sistemas facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico).

Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM, Team Foundation Server.

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.

Los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor no está disponible, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos

Más información: https://es.wikipedia.org/wiki/Control_de_versiones 

Qué es es control de versiones y porqué debería ser importante: https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones 

Programas de control de versiones: https://es.wikipedia.org/wiki/Programas_para_control_de_versiones 

Porqué git es el sistema de control de versiones más popular: https://hipertextual.com/archivo/2014/05/git-sistema-control-versiones/ 

Que es git y github

Git es el sistema de control de versiones, que es un software permite tener un control de cambios sobre el código fuente de una aplicación.

Git (pronunciado “guit”) 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.

Git es uno de los sistemas de control de versiones más populares entre los desarrolladores. Y parte culpa de su popularidad la tiene GitHub, un excelente servicio de alojamiento de repositorios de software con este sistema, que lejos de quedarse en esta funcionalidad, ofrece hoy en día un conjunto de características muy útiles para el trabajo en equipo.

Más información: https://es.wikipedia.org/wiki/Git 

Si vamos a programar, es muy importante usar un sistema de control de versiones para el mantenimiento y organización de nuestro código.

Instalación de git y SourceTree

Git se usa mediante comandos, pero para facilitar su uso usaremos una herramienta gráfica llamada SourceTree y que podremos encontrar en https://www.sourcetreeapp.com/ 

Existe otra alternativa llamada gitkraken: https://www.gitkraken.com/ 

Para poder usar Sourcetree es necesario tener una cuenta de Atlassian, el desarrollador: https://www.atlassian.com/. Para ello ir a sign up for your account en https://id.atlassian.com/signup

Una vez tenemos la cuenta de Atlassian verificada (pedirá verificación de correo), descargar Sourcetree desde https://www.sourcetreeapp.com/ y ejecutar.

Logearse con la cuenta de Atlassian

No configuramos los remotos, es decir, github y hacemos click en “Skip Setup”

NOTA: durante la instalación de sourcetree en Windows, se instalará una versión de git propia. No instalar svn (subversion)

Cuando se pregunte cargar una SSH Key poner “No”.

Más información sobre la instalación: https://confluence.atlassian.com/get-started-with-sourcetree/install-sourcetree-847359094.html

Entender el interfaz de Sourcetree: https://confluence.atlassian.com/get-started-with-sourcetree/understand-the-interface-847359069.html 

Control de versiones y Sourcetree: https://confluence.atlassian.com/get-started-with-sourcetree/version-control-and-sourcetree-847359072.html

Para poder seguir con las prácticas crearse una cuenta en github y mandar un correo a aprendiendoarduino@gmail.com con el nombre de la cuenta para poder revisar y corregir el código generado en el curso.

Get started con sourcetree https://confluence.atlassian.com/get-started-with-sourcetree/get-started-with-sourcetree-847359026.html 

Entender el interfaz de Sourcetree: https://confluence.atlassian.com/get-started-with-sourcetree/understand-the-interface-847359069.html 

Trabajar Usando Git

Vamos a usar git con la herramienta gráfica Sourcetree en lugar de aprender los comandos, esto permite a quien se inicia en el control de versiones empezar a trabajar rápidamente y de forma más sencilla.

Flujo básico de git:

Comandos básicos de git: https://www.hostinger.es/tutoriales/comandos-de-git 

La página de inicio de Sourcetree:

Opciones:

  • Local: Todos los proyecto que tenemos actualmente en local.
  • Remote: Los proyectos que están actualmente en remoto, ordenados por repositorios
  • Clone: hace una copia en nuestro ordenador de un repositorio, no solo el contenido sino todas las versiones.
  • Add: Añade a Sourcetree un repositorio que tengamos en local
  • + Create: Nos da la opción de crear un repositorio local o remoto.
  • Un buscador de repositorios locales y remotos

Clonar un repositorio

El comando asociado es: git clone [url]

Práctica: Clonar el repositorio https://github.com/jecrespo/led-race en una carpeta del ordenador (p.e. el escritorio), correspondiente al proyecto https://www.hackster.io/gbarbarov/open-led-race-a0331a

Al pulsar “clone” tendremos una copia del repositorio y además el histórico de los cambios, probar a navegar entre los diferentes cambios hechos por el autor del repositorio.

Si el dueño del repositorio hace un cambio podemos sincronizar nuestro directorio y traer la actualizaciones.

Los elementos más importantes en el interfaz:

  • File Status: Como su nombre indica muestra el estado de los ficheros. Siempre que cambiemos algo en algún fichero, cuando pongamos el foco en la ventana del Sourcetree, aquí se verán reflejados los cambios en los ficheros.
  • Branches: Nos indica las distintas ramas de trabajo.
  • Remotes: Aquí se encuentran los distintos repositorios remotos(Origin por defecto), así como las ramas de trabajo que están en ellos.

En la barra superior aparecen las acciones principales que solemos hacer con git: Commit, Checkout, Reset, Stash, Remove, Add/Remove, Fetch, Pull, Push Branch, Merge y Tag

Crear un repositorio

Práctica: Crear un repositorio local llamado “blink” en la ruta que queramos, p.e. escritorio. Comprobar que hay un directorio solo con un directorio oculto llamado .git.

Este es nuestro entorno de trabajo donde vamos a colocar todo el código e ir modificando las diversas versiones.

Crear un repositorio local: https://confluence.atlassian.com/get-started-with-sourcetree/create-a-local-repository-847359103.html 

Añadir Archivos al Área de trabajo (Stash)

Una vez tenemos nuestro repositorio local (aún no estamos subiendolo a Github), guardar en el directorio el ejemplo de blink que viene en el IDE Arduino, simplemente haciendo “guardar como…” desde el IDE de Arduino, en el directorio donde hemos creado el repositorio.

Una vez hecho, nos vamos a File Status. Una vez en esta ventana, en la parte inferior aparecen los unstaged files, ficheros que han sido modificados, creados o destruidos, pero que no están en el repositorio local (STAGE). Para añadirlos, simplemente tenemos que pulsar en Add en el menú superior, o en el check encima de todos los ficheros para añadirlos de golpe.

Registrar Cambio en el Historial (Commit)

Ahora realizamos un commit, para ello pulsar en Commit. Estos ficheros se añadirán al un cambio que se registrará en el repositorio local, y nos saldrá una ventana en la parte inferior, cuyo contenido es:

  • Commit options: donde podemos decidir entre distintas opciones del commit, como la de deshacer un commit por defecto.
  • Caja de texto: en la que se introduce el comentario del commit.
  • Check para push: para hacer un push inmediatamente después del commit.

Añadimos un texto en la caja de texto y pulsamos commit.

Si nos vamos al apartado Branches del menú lateral, veremos que ha salido la rama principal por defecto master. en esta ventana encontraremos la información más importante a la hora de hacer un seguimiento de las versiones que vayamos subiendo al repositorio.

  • Graph: nos muestra de forma visual cómo se están desarrollando las distintas ramas (lo comprobaremos cuando hagamos una nueva branch)
  • Description: indica los repositorios que se encuentran en esta versión, así como la descripción que se puso al commit. En este caso, la rama master local, y la rama master del remoto(origin/master) cuando se suba a github.
  • Commit: muestra el id del commit realizado, para tener controlado las distintas versiones que va teniendo git del repositorio
  • Author: nos indica el autor del commit, así como su correo electrónico.
  • Date: indica la hora y la fecha a la que se hizo el commit.

Práctica: Borrar los comentarios del archivo blink.ino y hacer un commit (cambio en el historial).

Pasos:

  • Borrar los comentarios del blink del espacio de trabajo donde hemos hecho el repositorio y guardar fichero
  • Comprobar los Uncommitted changes en “file status”
  • Añadir el cambio a “staged files” pulsando “Stage All”
  • Hacer el commit poniendo un comentario.
  • Comprobar en “History” que hemos hecho un cambio.

Práctica: Crear un fichero de texto llamado README.md en el directiorio raiz del repositorio, describir lo que hace el sketch y hacer un commit. Comprobar cómo puedo navegar entre las versiones, simplemente haciendo doble click en el commit.

Seguir los mismo pasos que en el ejemplo anterior.

NOTA: la extensión md es de markdown, Markdown es un lenguaje de marcado que facilita la aplicación de formato a un texto empleando una serie de caracteres de una forma especial. En principio, fue pensado para elaborar textos cuyo destino iba a ser la web con más rapidez y sencillez que si estuviésemos empleando directamente HTML.

Más información sobre Markdown:

Crear una Rama

Cualquier sistema de control de versiones moderno tiene algún mecanismo para soportar el uso de ramas. Cuando hablamos de ramificaciones, significa que tú has tomado la rama principal de desarrollo (master) y a partir de ahí has continuado trabajando sin seguir la rama principal de desarrollo.

Con respecto a las ramas, una buena política de trabajo es crear ramas para desarrollar bloques de funcionalidad concretos, de manera que se pueda trabajar sobre ella con libertad, y el proceso de unificación sea sobre el conjunto de los cambios una vez finalizado. 

Práctica: a continuación crearemos una nueva rama llamada “dev”, modificaremos el fichero “README.md”. El objetivo es ver como nos muestra las diferentes ramas el grafo de la aplicación, así como ver como realizar estos dos comando básicos de git.

Para crear una nueva rama de trabajo, basta que pinchar con el botón derecho encima del commit donde quiero hacer la nueva rama.

Tras pulsar el botón “Create Branch”, observamos como en el menú de la izquierda, en Branches se nos ha creado nuestra nueva rama. También podemos observar como en la descripción aparece esta nueva rama en el commit actual, que es el que hemos elegido.

Pasos:

  • Comprobar que estamos en la rama dev
  • Modificar el archivo README.md añadiendo algo más de documentación
  • Hacer un commit

Observar que la modificación está hecha en la rama dev. Si hago doble click en la rama master, desaparece la modificación y vuelvo al estado de la rama master.

Práctica: Modificar el Archivo blink.ino en la rama master para sacar por pantalla el estado de led con Serial.println(“Encendido/Apagado”)  y hacer commit. Observar que la modificación está hecha en la rama master. Si hago doble click en la rama dev, desaparece la modificación.

Pasos:

  • Ponerse en la rama master haciendo doble click en la rama master. Comprobar que el fichero README.md está 
  • Modificar el archivo blink.ino
  • Hacer Commit
  • Ver el grafo.

Comprobar también que el sketch de arduino funciona.

Merge en git

Ahora podemos fusionar las dos modificaciones que hemos hecho, en la rama “master” y en la rama “dev”, a esto se le llama merge.

Práctica: realizaremos un merge de dev en la rama master. Para realizar un merge basta con pulsar el botón merge en el menú superior. En esta ventana observamos como tenemos que elegir una rama para que se una a nuestra rama actual (nosotros estamos actualmente en master), por lo que solo tenemos que seleccionar la rama dev en el grafo. Dejamos la opción por defecto de que realice un commit si no han surgido conflictos, y aceptamos. Al hacer un merge, automáticamente hace un commit.

En caso que haya conflictos en el merge habrá que solucionarlos.

El resultado es que tenemos todas las modificaciones/funcionalidades en el repositorio.

Ya tenemos nuestro primer repositorio en local, pero ahora vamos a trabajar con un repositorio distribuido donde poder tener las versiones en diversos ordenadores y poder trabajar diversas personas en el mismo código de forma remota. Para ello usaremos Github.

Más información en primeros pasos con sourcetree: https://www.adictosaltrabajo.com/2015/06/08/primeros-pasos-con-source-tree/ 

Más información de git:

Control de Versiones

Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación.

Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión dando lugar a los llamados sistemas de control de versiones o VCS (del inglés Version Control System). Estos sistemas facilitan la administración de las distintas versiones de cada producto desarrollado, así como las posibles especializaciones realizadas (por ejemplo, para algún cliente específico).

Ejemplos de este tipo de herramientas son entre otros: CVS, Subversion, SourceSafe, ClearCase, Darcs, Bazaar, Plastic SCM, Git, SCCS, Mercurial, Perforce, Fossil SCM, Team Foundation Server.

El control de versiones es un sistema que registra los cambios realizados sobre un archivo o conjunto de archivos a lo largo del tiempo, de modo que puedas recuperar versiones específicas más adelante.

Los sistemas de control de versiones distribuidos (Distributed Version Control Systems o DVCSs en inglés). En un DVCS (como Git, Mercurial, Bazaar o Darcs), los clientes no sólo descargan la última instantánea de los archivos: replican completamente el repositorio. Así, si un servidor muere, y estos sistemas estaban colaborando a través de él, cualquiera de los repositorios de los clientes puede copiarse en el servidor para restaurarlo. Cada vez que se descarga una instantánea, en realidad se hace una copia de seguridad completa de todos los datos

Más información: https://es.wikipedia.org/wiki/Control_de_versiones

Qué es es control de versiones y porqué debería ser importante: https://git-scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones

Programas de control de versiones: https://es.wikipedia.org/wiki/Programas_para_control_de_versiones

Porqué git es el sistema de control de versiones más popular: https://hipertextual.com/archivo/2014/05/git-sistema-control-versiones/

Que es git y github

Git (pronunciado “guit”) 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.

Git es uno de los sistemas de control de versiones más populares entre los desarrolladores. Y parte culpa de su popularidad la tiene GitHub, un excelente servicio de alojamiento de repositorios de software con este sistema, que lejos de quedarse en esta funcionalidad, ofrece hoy en día un conjunto de características muy útiles para el trabajo en equipo.

Más información: https://es.wikipedia.org/wiki/Git

Cuando buscas en internet cualquier cosa sobre programación, software libre o Arduino es muy probable que acabemos en la página de https://github.com/ donde podemos acceder al código fuente.

Al trabajar Arduino es importante que conozcamos que es github y conocer un poco qué es y cómo hacer ciertas operaciones sencillas con esta web. Para conseguir software y ver el código, no es necesario crearse una cuenta, sólo es necesario cuando vamos a subir nuestro propio código.

GitHub es una plataforma de desarrollo colaborativo para alojar proyectos utilizando el sistema de control de versiones Git. El código se almacena de forma pública, aunque también se puede hacer de forma privada, creando una cuenta de pago.

Github es el servicio elegido por proyectos de software libre como jQuery, reddit, Sparkle, curl, Ruby on Rails, node.js, ClickToFlash, Erlang/OTP, CakePHP, Redis, y otros muchos. Además, algunas de las grandes empresas de Internet, como Facebook, alojan ahí sus desarrollos públicos, tales como el SDK, librerías, ejemplos, etc. También Arduino https://github.com/arduino

GitHub aloja tu repositorio de código y te brinda herramientas muy útiles para el trabajo en equipo, dentro de un proyecto. Además de eso, puedes contribuir a mejorar el software de los demás. Para poder alcanzar esta meta, GitHub provee de funcionalidades para hacer un fork y solicitar pulls.

Realizar un fork es simplemente clonar un repositorio ajeno (genera una copia en tu cuenta), para eliminar algún bug, modificar cosas de él o hacer tu propia versión partiendo de un software libre. Una vez realizadas las modificaciones puedes enviar un pull request al dueño del proyecto. Éste podrá analizar los cambios que has realizado fácilmente, y si considera interesante tu contribución, adjuntarlo con el repositorio original.

Guía de 10 minutos para empezar con github: https://guides.github.com/activities/hello-world/

En github podemos encontrar el código fuente de software libre que usamos a diario como el servidor web apache: https://github.com/apache/httpd y por supuesto el del IDE de Arduino https://github.com/arduino/Arduino

Y también grandes compañías como Google o Microsoft publican parte de su código en github: https://github.com/google y https://github.com/Microsoft

Otro ejemplo para el que usaremos github con Arduino es para conseguir las librerías de Arduino que nos sirven para manejar algunos dispositivos o nos facilitan la programación. Los distribuidores de hardware como https://www.sparkfun.com/ tienen su repositorio https://github.com/sparkfun donde podemos descargar las librerías para manejar el hardware que les compramos.

Más información de github:

Instalación de SourceTree

Git se usa mediante comandos, pero para facilitar su uso usaremos una herramienta llamada SourceTree y que podremos encontrar en https://www.sourcetreeapp.com/

Para ello debemos descargar la aplicación y en el proceso de instalación cuando se solicite no olvidar instalar la versión propia de git. No instalar svn (subversion). Opcionalmente conectar ninguna cuenta de github, pero no es necesario..

Para instalar SourceTree es necesario tener una cuenta en Atlassian o crearla.

Tutorial de instalación de SourceTree: https://confluence.atlassian.com/get-started-with-sourcetree/install-sourcetree-847359094.html

Para poder seguir con las prácticas crearse una cuenta en github y mandar un correo a aprendiendoarduino@gmail.com con el nombre de la cuenta para añadirlo a la organización: https://github.com/curso-programacion-arduino

Get started con sourcetree https://confluence.atlassian.com/get-started-with-sourcetree/get-started-with-sourcetree-847359026.html

Entender el interfaz de Sourcetree: https://confluence.atlassian.com/get-started-with-sourcetree/understand-the-interface-847359069.html

Hello World github

Para empezar con github hagamos el hello world: https://guides.github.com/activities/hello-world/

Hagamos los siguientes pasos cada uno con su cuenta de github:

  • Paso 1: Crear un repositorio
  • Paso 2: Crear una branch/rama
  • Paso 3: Hacer cambios y hacer commit
  • Paso 4: Hacer un Pull Request
  • Paso 5: Hacer un Merge del Pull Request

Todo esto que hemos hecho en la web de github, son operaciones que se pueden hacer con git por comando desde el ordenador o con una herramienta gráfica con SourceTree

Clonar un Repositorio

Clonar un repositorio, significa hacer una copia exacta en nuestro ordenador de un repositorio que hay en un servidor. Un repositorio, depósito o archivo es un sitio centralizado donde se almacena y mantiene información digital, habitualmente bases de datos o archivos informáticos.

Para clonar el repositorio con SourceTree debemos seguir estos pasos:

  • Click en el botón “Clone/New”
  • Click en “Clone repository”
  • En source URL poner la url de nuestro repositorio que lo encontramos en:

  • En Destination Path poner la ruta donde clonarlo. Podemos usar la ruta configurada en las propiedades de Arduino que por defecto es C:\Users\nombre_usuario\Documentos\Arduino\Curso_Programacion
  • En Name poner el nombre del Repositorio.
  • Y procedemos a clonar el repositorio.

Tutoriales de como clonar un repositorio:

Crear un repositorio local: https://confluence.atlassian.com/get-started-with-sourcetree/create-a-local-repository-847359103.html

Ejercicio: hacer con SourceTree lo mismo que se ha hecho con el Hello World en gitgub

  • Paso 1: Clonar el repositorio hello world que hemos hecho en nuestra cuenta de github. Ver como tenemos todos los pasos hechos en la web en local.
  • Paso 2: Crear una branch/rama nueva llamada “dev” en SourceTree
  • Paso 3: Hacer un cambio en el fichero readme.md poniendo nuestro nombre, hacer commit en SourceTree y hacer push de esos cambios al servidor.
  • Paso 5: Hacer un Merge de la nueva rama.

Trabajar Usando git

Trabajar usando git: https://confluence.atlassian.com/get-started-with-sourcetree/work-using-git-847359053.html

Operaciones básicas git:

Un pull request es una petición que el propietario de un fork de un repositorio hace al propietario del repositorio original para que este último incorpore los commits que están en el fork. Pull request es el corazón de la colaboración donde podemos hacer una modificación y proponerla al dueño

NOTA: la opción fetch es similar a pull, pero no copia los datos en local, sino que solo consulta en qué estado se encuentra nuestra copia local respecto al servidor. Es recomendable hacerlo antes del pull para ver en qué punto nos encontramos.

Más información:

Ejercicio: clonar el repositorio de la librería timer en nuestro ordenador en la carpeta librerías.

Organizaciones en github

Además de las cuentas de usuario, GitHub tiene Organizaciones. Al igual que las cuentas de usuario, las cuentas de organización tienen un espacio donde se guardarán los proyectos, pero en otras cosas son diferentes. Estas cuentas representan un grupo de gente que comparte la propiedad de los proyectos, y además se pueden gestionar estos miembros en subgrupos. Normalmente, estas cuentas se usan en equipos de desarrollo de código abierto.

Para el curso vamos a usar la organización https://github.com/curso-programacion-arduino donde todos los alumnos deben ser miembros de ella.

Las organizaciones se asocian con individuos mediante los equipos, que son simplemente agrupaciones de cuentas de usuario y repositorios dentro de la organización, y qué accesos tienen esas personas sobre cada repositorio.

Más información: https://git-scm.com/book/es/v2/GitHub-Gesti%C3%B3n-de-una-organizaci%C3%B3n

Uso de GIT en el curso

Durante el curso vamos a usar el sistema de control de versiones git y la plataforma de github para publicar el código que realicemos en el curso, ver las soluciones a los ejercicios y colaborar entre todos para resolver las prácticas propuestas.

Requisitos para realizar las prácticas:

Todos los ejercicios se subirán a la organización de github: https://github.com/curso-programacion-arduino y cada ejercicio tendrá su repositorio correspondiente con el formato EjercicioXX. La url a clonar es: “https://github.com/curso-programacion-arduino/EjercicioXX.git

Para hacer cualquiera de los ejercicios, el primer paso es clonar el repositorio del ejercicio y guardarlo en la ruta C:\Users\ThinkTIC\Documentos\Arduino\EjercicioXX, así podrán localizarse rápidamente en el IDE de Arduino. Dentro de este directorio el alumno creará el sketch con su solución al problema con el nombre Ejercicio_XX_NombreAlumno

Una vez hecho el ejercicio hacer un commit (no olvidar pasar a stage los fichero) y se publicará en github en la organización https://github.com/curso-programacion-arduino

Pasos:

  • Clonar el repositorio en el ordenador
  • Hacer el ejercicio con el nombre  EjercicioXX-Nombre. Recordar que se debe subir el fichero EjercicioXX-Nombre.ino dentro de una carpeta llamada EjercicioXX-Nombre
  • Hacer commit indicando en el commit el nombre del alumno.

Luego todos los alumnos podrán ver las soluciones propuestas por cada uno y comprobaremos que para un mismo problema hay infinitas soluciones. También el profesor pondrá su solución (no tiene porque ser la mejor) y hacer correcciones a los códigos propuestos por los alumnos.

NOTA: los ejercicios del repositorio https://github.com/jecrespo/aprendiendoarduino-Curso_Programacion_Arduino son las soluciones a los ejercicios, pero lo que subamos a la organización de github: https://github.com/curso-programacion-arduino son las prácticas que hará cada alumno y su solución.

Práctica con git

Ejercicio: Usando SourceTree hacer las siguientes tareas

  • Dentro del directorio clonado crear un sketch de Arduino que parpadee los cuatro leds a la vez del montaje de prácticas y llamarlo EjercicioXX-Nombre (poniendo vuestro nombre). Recordar que se debe subir el fichero EjercicioXX-Nombre.ino dentro de una carpeta llamada EjercicioXX-Nombre. ¡Importante! aseguraros de que nadie pone el mismo nombre sino puede haber conflictos.
  • Hacer un commit y un push
  • Hacer un pull para sincronizar el repositorio con las soluciones de los compañeros. ¡Atención!, es posible que tengamos que hacer un pull para sincronizar el directorio antes de hacer el push (el commit siempre lo hace) porque se han subido nuevas actualizaciones al servidor antes de la nuestra. Para resolverlo hacer fetch, ver lo que hay en el servidor, luego pull para sincronizar y finalmente push para subir mis cambios.
  • Comprobar que tengo en mi ordenador el código del resto de compañeros.
  • Comprobar que puedo moverme entre los diferentes commits hechos.