Archivo de la categoría: git

Repositorios Públicos en Github

1 respuesta

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

GitHub es una página que ofrece un grupo de servicios que facilitan el uso de Git, como por ejemplo hosting de proyectos, facilidades de colaboración, reviews de código, perfiles personales, pull requests, issues, etc.

GitHub es la plataforma de «hosting» de los proyectos. Una comunidad llena de personas que desarrollan y comparten, usando GIT. 

Como se ha dicho, Github github.com es un servicio para alojamiento de repositorios de software gestionados por el sistema de control de versiones Git. Por tanto, Git es algo más general que nos sirve para controlar el estado de un desarrollo a lo largo del tiempo, mientras que Github es algo más particular: un sitio web que usa Git para ofrecer a la comunidad de desarrolladores repositorios de software. En definitiva, Github es un sitio web pensado para hacer posible el compartir el código de una manera más fácil y al mismo tiempo darle popularidad a la herramienta de control de versiones en sí, que es Git.

Cabe destacar que Github es un proyecto comercial, a diferencia de la herramienta Git que es un proyecto de código abierto. No es el único sitio en Internet que mantiene ese modelo de negocio, pues existen otros sitios populares como Bitbucket o Gitlab que tienen la misma fórmula. No obstante, aunque Github tenga inversores que inyectan capital y esté movido por la rentabilidad económica, en el fondo es una iniciativa que siempre ha perseguido (y conseguido) el objetivo de hacer más popular el software libre. En ese sentido, en Github es gratuito alojar proyectos Open Source, lo que ha posibilitado que el número de proyectos no pare de crecer, y en estos momentos haya varios millones de repositorios y usuarios trabajando con la herramienta.

Pero ojo, para no llevarnos a engaño, al ser Git un sistema de control de versiones distribuido, no necesito Github u otro sitio de alojamiento del código para usar Git. Simplemente con tener Git instalado en mi ordenador, tengo un sistema de control de versiones completo, perfectamente funcional, para hacer todas las operaciones que necesito para el control de versiones. Claro que usar Github nos permite muchas facilidades, sobre todo a la hora de compartir código fuente, incluso con personas de cualquier parte del mundo a las que ni conoces.

Se complementan git y github, pero son personajes independientes.

Más información: https://desarrolloweb.com/articulos/introduccion-git-github.html 

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 de proyectos, librerías, etc… Al trabajar con Arduino es importante que conozcamos que es github y cómo hacer ciertas operaciones sencillas. 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. Si vamos a programar, es importante crearse una cuenta en github, no solo para compartir el código sino para tener un repositorio en la nube de nuestro trabajo y no guardarlo en local en nuestro ordenador.

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.

Github tiene planes gratuitos y permite tener repositorios privados. El plan gratuito es perfecto para cualquier programador aficionado que trabaja por su cuenta o para proyectos open source donde los repositorios son abiertos.

Pricing y comparativa de planes en Github: https://github.com/pricing

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. 

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.

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.

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 

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 pull request.

Github además es una muy buena herramienta de documentación para los proyectos open source, por ejemplo: https://github.com/ElCableAmarillo/Practicas

Dado que git es un sistema de control de versiones distribuido, Github es un servidor remoto donde sincronizar nuestros repositorios locales y publicarlos para colaborar en equipo o como un repositorio centralizado de los desarrollos.

Workflow de git con un repositorio remoto:

Y lo más importante:

Más información de github:

Crear Cuenta en Github y Repositorio de Curso

Para poder empezar a trabajar con Github, quien no tenga una cuenta deberá crearla en https://github.com/join.

Instrucciones: https://help.github.com/en/articles/signing-up-for-a-new-github-account 

Es necesario una cuenta de correo y verificar el correo. Instrucciones: https://help.github.com/en/articles/verifying-your-email-address

Cada Alumno debe crear un repositorio en su cuenta llamado “Curso_Programacion_Arduino_2019” donde guardará todos lo ejemplos que haga y puedan ser revisados por el profesor.

Instrucciones para crear un nuevo repositorio: https://help.github.com/en/articles/create-a-repo. Pasos:

  • Pulsar en new Repository
  • El nombre del repo será “Curso_Programacion_Arduino_2019”
  • Añadir una descripción del repositorio
  • Configurar el repositorio como Público
  • Inicializar el repositorio con un README
  • Añadir la licencia GNU v3

Una vez hecho, mandar la url del repositorio al profesor a la dirección aprendiendoarduino@gmail.com para poder hacer revisión de código.

Mi repositorio del curso: https://github.com/jecrespo/aprendiendoarduino-Curso_Programacion_Arduino_2019

Configurar Github en Sourcetree

Una vez tenemos la cuenta de Github, debemos configurar Sourcetree para añadir nuestra cuenta de Github y poder utilizarlo desde Sourcetree.

Instrucciones: https://confluence.atlassian.com/get-started-with-sourcetree/connect-your-bitbucket-or-github-account-847359096.html

En el menú opciones, buscar Authentication y añadir una cuenta,

Usar esta configuración, poniendo el usuario y actualizando la contraseña:

NOTA DE SEGURIDAD: Nuestro usuario y contraseña se ha quedado almacenado en SourceTree, para borrar la contraseña ir a preferencias – Accounts. Si estamos en un ordenador público, recordar borralo el último día del curso.

NOTA: es posible que en algún caso que haya que dar permiso a la aplicación sourcetree desde github (Si se hace con oauth autorizar en https://github.com/settings/applications). También es posible que en algún caso (p.e. si se usa autenticación en dos pasos) haya usar token de https://github.com/settings/tokens o aceptar el acceso desde terceros

Trabajar Usando Github con Sourcetree

Veamos las acciones básicas de trabajo en Github usando Sourcetree, una vez que tenemos configurado nuestra cuenta de Github en Sourcetree.

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

Operaciones básicas git:

  • 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: 

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.

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

Tutoriales de como clonar un repositorio:

Más información sobre cómo clonar y actualizar un repositorio con sourcetree

Hello World Github

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

Vamos a hacer lo mismo que hemos hecho en local, pero en github directamente.

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

  • Paso 1: Crear un repositorio llamado hello-world
  • Paso 2: Crear una branch/rama
  • Paso 3: Hacer cambios y hacer commit creando un archivo README.md
  • Paso 4: Hacer un Pull Request en nuestro propio repositorio
  • 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

Práctica: hacer con SourceTree lo mismo que se ha hecho con el Hello World en Github para comprobar que podemos trabajar en los dos entornos.

  • Paso 1: Clonar el repositorio hello world que hemos hecho en nuestro directorio local. Ver como tenemos todos los pasos hechos en la web se ven 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 4: Hacer un Merge de la nueva rama en local y hacer Push y ver los cambio en Github

Subir un Repositorio a Github

Veamos ahora cómo subir el repositorio local blink que hemos creado a Github. Para ello crear un nuevo repositorio en la cuenta de Github llamado “blink”, que es el que sincronizaremos con nuestro repositorio local blink

Una vez tenemos el repositorio remoto, debemos configurar en local la dirección del repositorio remoto, para ello pulsar en settings de Sourcetree del repositorio local blink y en la pestaña Remotes pulsar Add. Rellenar los campos:

  • Remote name: poner el Default remote que es origin
  • URL/Path: poner la URL del repositorio que acabamos de crear, en mi caso https://github.com/jecrespo/blink
  • Remote Account: seleccionar nuestra cuenta de Github

Una vez hecho esto, hacer Push de todas las ramas

Comprobar en Github que se ha subido el nuevo repositorio con todos los cambios históricos hechos.

Fork en Github

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 simplemente 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.

Forks de un repositorio original:

Cada repositorio clonado es independiente. Esto significa que no importa si no se sincronizan, ellos pueden avanzar el proyecto a su antojo y necesidades.

Todos los clones derivados del repositorio original contienen el mismo registro de cambios, archivos e historial hasta el commit A. A partir de ahí, cada uno puede avanzar su propio proyecto con sus respectivos cambios independientemente y si quiero aportar mis cambios debo hacer un pull request.

Práctica: Hacer un fork en la cuenta de cada uno del repositorio https://github.com/jecrespo/blink 

NOTA: Si da error porque ya existe un repositorio “blink”, renombrarlo.

Pull Request en Github

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 proponer al dueño

Cuando se realiza un pull request, se está proponiendo tus cambios y solicitando que alguien revise e incorpore tu contribución. Las pull request muestran diferencias, del contenido de ambas ramas. Los cambios, sumas y restas se muestran en verde y rojo respectivamente.

Se  puede abrir pull request en su propio repositorio y fusionarlas uno mismo. Es una gran manera de aprender el flujo de GitHub antes de trabajar en proyectos más grandes. Ya lo hemos hecho en el ejemplo Hello-world.

Práctica: Hacer un cambio en el repositorio blink frokeado de https://github.com/jecrespo/blink y solicitar un pull request.

Pasos:

El propietario aceptará los cambios propuestos y los incorpora a su código. Comprobar.

NOTA: El profesor usará los pull requests para proponer mejoras a los ejercicios realizados por los alumnos.

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.

Un ejemplo de organización es: https://github.com/curso-programacion-arduino

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 Github/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:

  • Tener instalado SourceTree https://www.sourcetreeapp.com/, es una herramienta gratuita pero es necesario crear una cuenta para usarlo.
  • Tener una cuenta en github
  • Cada Alumno debe crear un repositorio en su cuenta llamado “Curso_Programacion_Arduino_2019” donde guardará todos lo ejemplos que haga y puedan ser revisados por el profesor.

Cada alumno tendrá su propio repositorio donde subirá todo lo que programe y le servirá en el futuro, yo haré pull request o cualquier problema me lo manden para corregirlo. Cada uno solventará un problema de programación de forma diferente y yo podré seguir su trabajo.

Práctica: Crear un repositorio llamado “Curso_Programacion_Arduino_2019” y mandar al profesor.

El alumno tendrá ahora 3 repositorios en su cuenta: Hell-World, Blink (fork de https://github.com/jecrespo/blink) y “Curso_Programacion_Arduino_2019”

Mi repositorio es el https://github.com/jecrespo/aprendiendoarduino-Curso_Programacion_Arduino_2019

Control de Versiones con GIT

1 respuesta

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: