Esta lección fue escrita teniendo presente una versión vieja de Github Desktop para OS X. Desde su publicación, Github ha lanzado una nueva versión de Github Desktop con cambios significativos en la interfaz. El tutorial solo cubre la la vieja versión para OS X, que ha pasado a llamarse “Github Desktop Classic” y que.
Con esta lección aprenderás el funcionamiento básico de los sistemas de control de versiones, entenderás por qué son útiles y te familiarizarás con GitHub Desktop, un control de versiones de documentos en formato de texto plano. Al terminar la lección, serás capaz de entender:
Actualmente, GitHub Desktop Classic está libre solamente para Mac. Si utilizas Linux probablemente estarás familiarizado con la línea de comandos y serás capaz de utilizar la versión de línea de comandos de Git.
Antes de ponerse a ello, es conveniente comprender qué es un control de versiones y por qué puede ser útil para tu investigación. En términos generales, un control de versiones consiste en tomar instantáneas de tus ficheros a lo largo del proceso de creación. La mayoría de personas, en verdad, trabajan con algún sistema de control de versiones para administrar sus archivos. De manera frecuente, el control tiene lugar guardando diferentes versiones de un mismo archivo. Por poner un ejemplo, no es extraño toparnos frente a un directorio que contiene los siguientes archivos:
Esta forma de nombrar los ficheros puede ser más o bien menos sistemática. Si añadimos datas, puede ser un poco más fácil continuar los cambios:
Aunque este método sea un poco más claro, sigue habiendo inconvenientes. En primer lugar, este método no registra o bien describe qué cambios se han producido entre uno y otro fichero guardado. Pueden ser pequeñas correcciones de erratas, o tratarse de la reescritura de pasajes enteros o aun de una modificación mayor, por servirnos de un ejemplo, de la estructura del documento. Además si deseas revertir alguno de estos cambios, tendrás que averiguar cuándo se hizo el cambio y deshacerlo.
Con un control de versiones se persigue solucionar esta clase de inconvenientes mediante la puesta en marcha de un registro sistemático de cambios en los archivos. A grandes rasgos, puede afirmarse que el control de versiones efectúa instantáneas de los ficheros a lo largo del tiempo. Estas instantáneas documentan el instante en que fueron tomadas pero también qué cambios tuvieron sitio entre cada una de ellas, lo cual deja recuperar una versión más antigua de tu archivo. Desde aquí se abre un sinfín de posibilidades merced al control de versiones.
A medida que en nuestras investigaciones usamos herramientas digitales y almacenamiento en formato digital, se vuelve relevante reflexionar sobre cómo optimar la gestión de nuestros datos. Más aún, el control de versiones puede ser indispensable si tenemos intención de colaborar con otros investigadores. Si bien el control de versiones fue diseñado en sus orígenes para tratar ficheros de código, creemos que la gestión de documentos también se beneficiaría. La lección que planteamos no cubre todas los beneficios del control de versiones pero al finalizarla podrás realizar las siguientes tareas:
En específico, el control de versiones es útil para facilitar la colaboración. En verdad, una de las razones que explican el origen del control de cambios es que permitera a múltiples personas trabajar al tiempo en un proyecto de notables dimensiones y utilizar Git para regentar las fuentes del núcleo Linux. Emplear un control de versiones favorece la colaboración debido a su flexibilidad. Por ejemplo, 2 personas pueden trabajar en un mismo documento al tiempo y ‘fusionar’ los cambios. Si hay un ‘conflicto’ entre las 2 versiones, el sistema de control permitiría al usuario ver el enfrentamiento y decidir cómo fusionar las 2 versiones dando sitio a una ‘tercera’ versión. De este modo, conservarías la ‘historia’ del documento, es decir, las versiones anteriores y, en consecuencia, podrías revertir el proceso eligiendo una versión más antigua.
No es preciso, no obstante, arrancar un control de versiones para todos tus documentos. En algunas ocasiones resulta muy útil; por servirnos de un ejemplo, para escribir artículos, libros o tesis doctorales.
La implementación del control de versiones que proponemos en esta lección está pensada para que los documentos sean públicos. Sin embargo, puedes usar un control de versión y mantener tus documentos ocultos de manera permanente o bien hasta el momento en que decidas publicarlos en línea.
Aunque a veces se emplean como sinónimos, Git y GitHub no son lo mismo. Git es un sistema específico diseñado para supervisar versiones en un ambiente Linux; fue desarrollado por Linus Torvalds con el propósito primordial de administrar código fuente. Por supuesto, existen otrospero su uso no está tan difundido. Git puede referirse tanto a una forma de supervisar versiones como al programa usado para llevar a cabo dicha labor.
En cambio, GitHub es una compañía que aloja repositorios Git (más detalles abajo) y que proporciona un programa específico para utilizar Git. Entre las modalidades de empleo, resalta el programa ‘GitHub Desktop’, sobre el que trata este tutorial. En nuestros días, si tenemos en cuenta el, es posible aseverar que GitHub es la plataforma más popular para alojar en abierto el código de proyectos digitales.
Pese a que GitHub está diseñado originalmente para publicar código fuente, ciertos proyectos, como
The Programming Historian en español, lo usan para supervisar las versiones y para gestionar el flujo de trabajo de sus publicaciones, libros de texto, etcétera Así que familiarizarte con GitHub no solo te permitirá controlar las versiones de tu documento sino contribuir a los proyectos que usan GitHub. En esta lección nuestro objetivo es ofrecer una introducción al funcionamiento básico de los objetivos marketing digital ciudad real del control de versiones de un fichero de texto plano. La lección no es pormenorizada mas proporciona un punto de inicio para que puedas seguir aprendiendo por tu cuenta.
Dropbox, Google Drive y otros servicios ofrecen alguna forma de supervisar las versiones en sus sistemas. A veces esto basta para tus necesidades. Sin embargo, hay algunas ventajas por las que vale la pena usar un control de versiones como Git:
Utilizar un control de versiones se ha consolidado en algunas disciplinas científicas, si bien su adopción está lejos de ser universal. En las humanidades y en las ciencias sociales, el uso de Git es mucho menos usual. Los proyectos que alistamos a continuación muestran algunas de las posibilidades del uso de Git en un ambiente académico:
Nuevos proyectos brotan de manera constante y muchas de las herramientas que utilizas en las humanidades digitales se alojan en GitHub; por esta razón, GitHub puede ser útil para usar con mayor facilidad alguna de estas herramientas.
GitHub Desktop, la aplicación de escritorio de GitHub, te permitirá comenzar a emplear un control de versiones sin problemas. GitHub Desktop es, en verdad, una Interfaz Gráfica de Usuario (GUI, por sus iniciales en inglés) diseñada para facilitar el uso de Git. Las interfaces gráficas de usuario dejan al usuario interaccionar con el programa a través de un dispositivo visual que reemplaza la línea de comandos. Aunque usar la línea de comandos ofrece muchas ventajas en un largo plazo, si usas GitHub Desktop reducirás la curva de aprendizaje; encontrarás más recursos sobre la línea de comando al final de la lección.
Uno de los aspectos más complejos del uso de GitHub es la terminología. El nombre de algunos de los comandos se comprende fácilmente por el hecho de que son evidentes, mas otros no tanto. En este tutorial intentaremos explicar concisamente los términos poco comunes. Si te pierdes, puedes preguntar elde GitHub. No obstante, pensamos que es mejor ir aprendiendo los términos sobre la marcha, a medida que se usa el programa, en vez de intentar comprender toda la terminología antes de comenzar.
Puesto que vamos a usar GitHub, necesitarás regístrate con una cuenta ensi no lo has hecho ya. Parae, GitHub ofrece repositorios privados de forma gratuita. Este tipo de repositorios no son precisos pero quizá esta opción te cautive si deseas mantener tu trabajo en privado.
Te aconsejamos que prosigas el procedimiento explicado en la. Tras descargar GitHub Desktop Classic y también instalarlo, ya podemos empezar a usar el programa con un fichero de texto plano.
Los sistemas de control de versiones como Git marchan mejor con archivos de texto plano. Este género de archivos contienen un marcado muy sencillo; por contra, los ficheros Word (u otros generados con procesadores similares) generan código que no es legible para los humanos. Además, cualquier fichero guardado como ‘.txt’ puede abrirse sin inconvenientes con Word, LibreOffice o bien Notepad. La portabilidad es la primordial ventaja del texto plano pues estos ficheros pueden abrirse y ejecutarse en la mayoría de ordenadores.
Pese a los beneficios evidentes de escribir nuestros documentos en texto plano, también debemos señalar ciertas limitaciones. Los archivos de texto plano en sí no dejan marcar algunas palabras en
cursivao bien con
negrita; tampoco es posible incluir encabezado o convocatorias. Para efectuar esto necesitaremos una sintaxis adicional: ‘markdown’.
Con Markdown vamos a poder, pues, dar formato a nuestro texto plano. Probablemente hayas utilizado HTML o bien LaTex anteriormente. Estos lenguajes de marcado también expresan información sobre el estilo y la estructura del documento. No obstante, el propósito de Markdown es minimizar el marcado, lo que quiere decir que es más fácil centrarse en el contenido, en la escritura, sin preocuparse en cómo marcar el texto -de ahí el nombre de ‘markdown’.
Esta lección no cubre la sintaxis Markdown por razones de espacio, mas es útil explorar su funcionamiento cuando te sientas cómodo con el control de versiones. Es conveniente señalar, por otra parte, que GitHub integra una versión propia de la sintaxis Markdown. Si añades la sintaxis Markdown a tus documentos, tu control de versiones gestionado con GitHub Desktop visualizará con corrección tu documento en la web. La mejor manera de aprender Markdown es con un tanto de práctica. Puedes comenzar con nuestraescrita por Sarah Simpkin, o bien con la lecciónescrita por Dennis Tenen y Grant Wythoff.
Para escribir un documento de texto plano precisamos un editor. Hay muchos editores libres, ciertos gratis, otros de pago. Algunos son fáciles de utilizar al paso que otros tienen una curva de aprendizaje y un potencial que sobrepasa las funciones de un editor de texto. A largo plazo, un editor avanzado como Vim o Emacs puede ahorrarte tiempo pero por el momento puedes comenzar con un editor más simple. Por ejemplo,es un buen editor desarrollado por GitHub que resalta la sintaxis Markdown y, además, se integra con la plataforma GitHub. Es gratis y su código es abierto; además, incluye unde instrucciones muy exhaustivo.
Si no deseas instalar un programa nuevo, puedes utilizar uno de los editores que incluidos en tu ordenador como TextEdit para Mac. Si decides seguir aprendiendo Markdown en el futuro, te invitamos a utilizar un editor de texto que destaque la sintaxis Markdown, entre otras funcionalidades.
Podemos iniciar creando un documento sencillísimo.
Añade este texto (o bien algo similar) en documento de texto plano nuevo. ¿Listo? A continuación, guarda el fichero con la extensión ‘.md’. Esta extensión es la más popular para los archivos markdown aunque en ocasiones es posible usar otras. A veces el editor de texto guarda los ficheros como Rich Text Format (RTF) por defecto, así que asegúrate de que el archivo se guarda en formato de texto plano un directorio nuevo. Si ocurre esto, puedes cambiarlo en la pestaña preferencias u opciones de tu editor. En cualquier caso, identifica tu fichero y tu directorio con un nombre semánticamente claro. Si bien la extensión usada sea’.md’, hay que asegurarse de que el archivo es de ‘texto plano’. Por norma general, la codificación del documento no será ningún problema una vez te habitúes a usar el editor de texto.
Para emplear de manera eficaz el control de versiones de Git, es importante organizar tu proyecto en directorios. Git rastrea el contenido de cada directorio creando un
repositorioa partir de cada uno de ellos. Un repositorio se compone de todos los archivos que están siendo
controladospor Git. Lo mejor es crear un directorio para cada proyecto en el que trabajas; por ejemplo, un repositorio para un artículo que estés escribiendo, otro para la composición de tu libro, uno más para el código en desarrollo, etc. Estos directorios son como las carpetitas normales y corrientes que tienes en tu ordenador; la única peculiaridad es que los ficheros han de ser añadidos de forma expresa al repositorio a fin de que sean controlados a través de Git.
Hay varias formas de
añadirun fichero para que GitHub Desktop lo controle. Por poner un ejemplo, podemos arrastrar un directorio con el archivo a GitHub Desktop. Si haces esto, el programa te preguntará si quieres crear un repositorio para este directorio. Otra manera consiste en hacer click sobre el icono ‘más’ para abrir el buscador y seleccionar la carpeta que queremos añadir.
Añade un repositorio
Una vez hemos añadido nuestra carpeta podremos verla en la lista de repositorios ubicada en la columna izquierda.
Añade un repositorio
Si hacemos clic sobre el repositorio que acabamos de añadir, vamos a poder ver los ficheros contenidos. En este menú, además, podremos elegir qué archivos queremos rastrear pues a veces trabajamos en proyectos con archivos que no lo requieren. Al lado, a la derecha, se visualizan los documentos.
Si seleccionamos mostrar las carpetitas ocultas en el directorio que acabamos de añadir a GitHub, vamos a poder ver que contiene una carpetita adicional llamada ‘.git’. En esta carpetita quedan registrados los cambios producidos en el control de versiones y también si los cambios son modificaciones realizadas en archivos ya existentes o bien si hemos creado archivos nuevos.
A continuación, volvamos a nuestros documentos y añadamos algo nuevo.
Guarda los cambios realizados y vuelve a GitHub Desktop. Verás que que en el texto aparecen la nueva línea que has añadido; esto quiere decir que GitHub es capaz de percibir los cambios realizados en el archivo pero aún no han sido registrados en una ‘instantánea’ en tu repositorio.
Para hacer esto debes
anotarlos cambios.
Al
anotar(‘commit’) un cambio, comunicas a Git que quieres registrar las modificaciones realizadas. Aunque
anotarpuede parecer afín a guardar un archivo, el objetivo es distinto. Con frecuencia guardamos diferentes versiones de un documento; ahora bien, guardar un documento, realmente, significa que puedes cerrar el archivo y volver a él más tarde y que su estado será exactamente el mismo, esto es, no se habrán producido perdidas.
Anotar, en cambio, implica tomar una instantánea de un archivo en un instante determinado y documentar información sobre los cambios realizados.
Primera anotación
Para anotar un cambio debes dar un resumen de los cambios y, de manera opcional, incluir un mensaje. Es esencial que pienses cuidadosamente cuándo debes anotar los cambios. El control de versiones solo es útil si anotas los cambios de manera eficaz. A veces tendemos a anotar los cambios solo cuando hemos terminado de trabajar sobre un documento. No obstante, esto no refleja los cambios importantes realizados a lo largo de todo el proceso.
Cuando anotes el cambio verás que aparece el mensaje ‘anotar al master’. Esto desea decir que te refieres a la rama ‘master’. En un repositorio Git es posible tener varias ramas. Estas ramas son, en esencia, lugares distintos en los que puedes trabajar. De forma frecuente se emplean para probar nuevas ideas o trabajar en un aspecto concreto. De entrada, no es preciso emplear crear ramas en GitHub mas quizás quieras aprender de cara al futuro, sobre todo si quieres cooperar con otras personas en un mismo proyecto.
Una forma de comprender las anotaciones es pensar en el ‘historial’ de tu documento. Cada anotación registra un desarrollo o cambio hecho en el documento alojada en el repositorio; el historial del documento, por lo tanto, puede ser recuperada consultando todas y cada una de las anotaciones grabadas. A fin de que el historial sea útil más tarde, para ti o bien para un colaborador, es esencial que los cambios queden registrados en momentos esenciales del proceso. Vale la pena que las anotaciones sean modulares y que tengas sentido por sí mismas. En otras palabras, las anotaciones y los mensajes deberían entenderse sin tener que ver los cambios precedes o posteriores.
Si pensamos cómo se usa el control de versiones con código también puede ser útil. En el momento en que una nueva función o en el momento en que un fallo ha sido reparado, es esencial que estos cambios se hagan de manera apartada. Si una anotación incluye cambios que afectan a diferentes aspectos del código, se hace más difícil aislar los inconvenientes que aparezcan más tarde. También se hace más difícil quitar un cambio particularmente que ha causado problemas si este ha sido anotado así como otros.
Aunque hay diferencias entre el control de versiones de código y de textos, las anotaciones deberían ser modulares. Por poner un ejemplo, siempre y en todo momento es útil anotar cambios que afectan a la estructura del documento por un lado y anotar mejoras en el estilo o bien la ortografía por otro lado. Así, si más tarde decides cambiar la estructura, podrás preservar las otras correcciones.
Es esencial que tus anotaciones y los mensajes asociados que las describen tengan sentido y sean específicos. Redactar buenas descripciones de las anotaciones requiere reflexión. A veces, los mensajes que para ti son claros en el instante de la anotación se vuelven difíciles de comprender en el futuro. Si vas a emplear el control de versiones con otras personas es esencial que tus cooperadores puedan entenderte. El control de versiones para gestionar cambios en documentos marcha mejor en el momento en que nos esmeramos un tanto en meditar cómo utilizamos el programa. En consecuencia, cuando se realiza un trabajo colaborativo es importante aclarar estas cuestiones y compartir una misma visión para usar el control de cambios de forma eficaz.
Una manera de enfrentarse a este inconveniente es procurar proseguir un ‘estilo de anotaciones’. Por poner un ejemplo, te invitamos a continuar la influyentecuando realices anotaciones. La sugerencia de Tim Pope, parcialmente, la interfaz de GitHub Desktop para anotar cambios y describirlos mas entender el formato te ayudará a poner en práctica su estrategia. El próximo mensaje es una adaptación de la propuesta de Tim Pope, que se centra en la anotación de texto (en lugar de código):
La interfaz de GitHub Desktop proporciona cierta ayuda para escribir mensajes de esta manera mas es esencial que seas siendo consciente del formato sugerido. No siempre será necesario redactar un resumen detallado mas sí es esencial que tu descripción sea clara y que los cambios efectuados, así como las anotaciones, sean modulares.
Para ejemplificar esto, a continuación, tienes una anotación descrita en el contexto de una obra escrita:
Los mensajes gráficos que acompañan la edición de una página de Wikipedia o bien una Wiki son un paralelo a las anotaciones y pueden servirte de modelo a fin de que escribas mensajes fáciles de entender. Cuando escribas estos mensajes debes explicar los cambios que has hecho y por qué los has hecho a fin de que otras personas puedan comprender tu razonamiento. Si tienes en cuenta un receptor externo (un cooperador y no solo tú), te será más fácil escribir anotaciones claras y con sentido.
Las ventajas de utilizar un control de versiones se basan en buena medida en su empleo efectivo. Es esencial meditar cuándo se hacen las anotaciones y cómo identificar de forma correcta esos cambios cuando se describen con mensajes. Si te esfuerzas en hacer tus anotaciones y mensajes ‘modulares’, te será más fácil ‘moverte’ a través del historial de tu repositorio. Un buen repositorio debería permitir entender los cambios realizados; no solo tú debería entenderlos sino también las personas con las que colabores.
Existen algunas diferencias entre la administración de un repositorio que contiene principalmente código y otro que contiene texto. En ambos casos, no obstante, una organización clara y lógica es indispensable. Si bien no uses un control de versiones o bien no pretendas hacer público tus datos, te recomendamos ser siempre y en toda circunstancia organizado con los materiales de tu investigación. Para una introducción a la gestión de los datos de investigación, puedes preguntar la lección.
Hasta ahora solo hemos registrado nuestros cambios de forma local. Aunque podríamos estar satisfechos con guardarlos en nuestro PC (es esencial preservar copias), seguramente deseamos subir los archivos a nuestro repositorio de GitHub para hacerlos públicos o, sencillamente, para tener una copia que no esté alojada en nuestro ordenador. El proceso con GitHub Desktop es muy sencillo y rápido. En GitHub Desktop ‘publicas’ repositorios; es decir, los
envías(‘push’) desde tu PC a la página web de GitHub. Durante este proceso también creas un repositorio
remoto.
Cómo publicar el repositorio
Una vez hayas ‘publicado’ tu repositorio, será visible en tu perfil de GitHub. Es posible crear un repositorio privado en GitHub pero solo si te registras comoo, o bien pagando una. Si no te has registrado como estudiante o investigador, solo podrás crear un repositorio privado cuando pagues por una suscripción. Por eso, a menos que quieras pagar, puedes ignorar la sección ‘Información sobre la compra’. En esta sección, será suficiente con publicar un repositorio abierto. Para acceder a tu repositorio en línea, en el menú puedes hacer clic sobre ‘Repository’ (‘Repositorio’) y luego escoger ‘View on GitHub’ (esto es, ‘Ver en GitHub’). Al hacer esto, se abrirá una ventana en tu navegador con tu repositorio en línea.
Vista del menú
A continuación, deberías ver tu documento en tu repositorio web.
La versión en línea de tu repositorio
Una vez que tu documento esté en línea, puedes continuar efectuando cambios en tu documento de forma local. Pero tendrás que
sincronizartus cambios locales para reflejarlos en el repositorio publicado en GitHub. Esta plataforma guarda los cambios en tu PC y remotamente (en sus servidores). De ahí que es importante mantener los dos lugares sincronizados. Con GitHub Desktop este proceso se facilita mientras que en la línea de comandos deberíamos ejecutar
sync(‘sincronizar’) y luego
pull(‘recibir’). Verás el botón ‘sync’ en el margen superior derecho de tu GitHub Desktop. auditoria rediseño web , te cercioras de que tu entorno local (tu computador) y tu entorno remoto (el servidor de GitHub) contienen la misma información. Si deseas trabajar en tu documento antes de publicarlo, también puedes seleccionar anotar los cambios sin sincronizar. Esto te permitirá poner en marcha el control de versiones en local en una fase temprana.
También es posible realizar cambios en tu repositorio a través de la interfaz web de GitHub. Para ello, haz clic sobre el nombre del fichero y accederás a una nueva página que muestra tu documento.
Vista de tu documento en línea
(Nota: puede parecer extraño que todo cuanto has escrito aparezca en una línea, cuando tu fichero local tenía dos líneas. Esto es debido a que en Markdown, los párrafos deben marcarse dejando una línea en blanco; así pues, 2 líneas sucesivas son interpretadas como un solo párrafo. Si hubiéramos empleado la extensión ‘.txt’, tendríamos un salto de línea aquí, pero con la extensión ‘.md’ estamos indicando a GitHub que visualice el documento según las normas de Markdown. Esta es otra razón por la que utilizar un editor apto para Markdown puede serte útil para visualizar el formato).
La interfaz web ofrece otras opciones. Por poner un ejemplo, puedes visualizar los cambios en el historial, puedes abrir el documento en GitHub Desktop, o bien puedes suprimirlo. Encontrarás más opciones junto a la opción ‘code’ (‘código’). Estas opciones no son esenciales ya, al comienzo, pero quizás la uses en el futuro. A continuación, intentaremos editar un documento en la interfaz web y acompasar los cambios con nuestro repositorio local.
Así, puesto que, haz clic sobre la opción ‘editar’ representada con un lápiz.
El botón ‘Editar’
Tras esto deberías poder editar el fichero y añadir más texto.
El modo edición
Una vez hayas realizado cambios en tu archivo, verás que puedes anotar los cambios en la parte inferior de la ventana.
Cómo anotar un cambio en línea
Una vez hayas anotado los cambios, serán almacenados en tu repositorio remoto. Para recibirlos en tu PC deberás sincronizarlos. Para esto, haz clic en el botón ‘sync’ de tu GitHub Desktop.
El botón de sincronización
¡Ya tenemos nuestros cambios realizados remotamente en nuestro ordenador!
El documento con los cambios remotos
Verás que el texto modificado aparece marcado en verde y en colorado. El color rojo señala que se ha producido una eliminación mientras que el verde señala que se ha añadido algo. Esta forma de visualizar los cambios puede ser útil antes de anotar puesto que te permitirá encontrarlos y cerciorarte de que los quieres registrar. En la parte izquierda verás el historial de los cambios efectuados. En este momento el historial es muy breve mas conforme trabajes crecerá en tamaño. Ver los cambios realizados de esta manera, en cada una de las fases de tu proyecto, te será de enorme utilidad.
Los ‘conflictos’ surgen cuando intentas fusionar o bien sincronizar 2 versiones de un documento con cambios que son incompatibles entre sí. Si tienes cuidado cuando anotas y acompasas los cambios realizados en tu ambiente local, en tu ordenador, entonces es bastante poco probable de que te halles con este tipo de problemas; de todas formas, resolverlos es una tarea sencilla.
A menudo, los conflictos surgen cuando efectúas un cambio en recóndito (en la web GitHub) y luego haces otro cambio local sin haber acompasado anteriormente. Si los cambios tienen sitio en diferentes unas partes del documento, no pasa nada, se pueden integrar o bien fusionar (‘merge’). Ahora bien, ciertos cambios pueden entrar en conflicto cuando tienen lugar en la misma línea del documento.
Por ejemplo, supongamos que añadimos algo en nuestro repositorio remoto (en la página web de GitHub).
Un cambio remoto en el documento
A continuación, anotas el cambio en la web y, acto seguido, hacemos otro cambio local.
Un cambio local en el documento
Si anotamos el cambio en local y acompasamos, vamos a recibir un mensaje de alerta señalando que se ha producido un enfrentamiento.
GitHub nos alerta de un conflicto de sincronización
No te preocupes, no es un problema gordo. Simplemente hay que gestionar el conflicto. GitHub Desktop te ofrece la posibilidad de abrir el archivo y acceder al sitio en donde se halla el inconveniente.
Las opciones que nos da GitHub para abrir el documento
Si elegimos abrir el archivo con un editor externo, el documento se visualizará el editor de texto que tengas por defecto para archivos escritos en Markdown. Si no tienes ninguno por defecto, puedes haz click en ‘show in finder’ (‘mostrar en el buscador’) para acceder a la carpeta que contiene el fichero. A partir de aquí puedes abrirlo con el editor que prefieras.
Si miras el archivo con atención, verás que Git ha marcado dónde se encuentra el enfrentamiento.
Marcas usadas para señalar los conflictos
Verás que el enfrentamiento está envuelto con las marcas
<<<<<<<y
>>>>>>>. Los dos bloques que están en enfrentamiento se distinguen merced a una línea como esta
=======line. Hay distintas formas de gestionar este tipo de conflicto. Por servirnos de un ejemplo, podrías quitar la versión que ya no quieres y deshacerte de las marcas; o podrías eliminar todo el bloque y descartar las dos versiones. Una vez hayas ‘resuelto’ el conflicto, debes anotar el cambio y acompasar como es costumbre. Cuando vayas a anotar el cambio, verás que el GitHub Desktop especifica que la anotación consiste en una fusión de un enfrentamiento. Así, en el futuro, podrás volver sobre ello y repasar cómo lo resolviste.
Esta forma de resolver conflictos puede parecer más compleja de lo que es, pero, indudablemente, es muy útil por el hecho de que te da mucho control. En una plataforma como Dropbox esto ocasionaría la duplicación de un fichero. A pesar de que esta solución sea mejor que perder los cambios, deberías ver qué fichero contiene la versión que quieres y decidir cómo solucionar el enfrentamiento. En todo caso, si tienes cuidado al acompasar los cambios evitarás muchos enfrentamientos. Si colaboras con otras personas, el riesgo de crear conflictos es mucho mayor; de ahí que, es esencial saber cómo resolverlos antes de comenzar a colaborar con GitHub.
Hasta el momento hemos puesto en marcha un control de versiones con un documento muy básico. Si aprendes más sobre Markdown y la escritura en texto plano, podrás usar el control de versiones de muchas maneras y te será muy útil para hacer tu investigación. Controlar las versiones de un documento Markdown te permitirá ahondar en esta sintaxis; para esto, te recomendamos consultar la lecciónescrita por Dennis Tenen y Grant Wythoff; esta lección te ayudará a entender cómo puedes usar el texto plano para escribir con Pandoc y Markdown. Pandoc es muy útil para convertir tus ficheros de texto plano escritos en Markdown a otros formatos como HTML, PDF o bien Word. Si combinas Markdown, Pandoc y el control de versiones, podrás incorporar un sistema muy potente y sustentable para escribir tus artículos y trabajos académicos.
Asimismo, el flujo de trabajo presentado en esta lección también puede transformarse en el fundamento para crear webs estáticas alojadas en GitHub. Una vez te sientas cómodo utilizando GitHub Desktop, puedes continuar con la lección escrita por Amanda Visconti,.
GitHub Desktop es una forma sencilla de aprender a supervisar versiones con GitHub. En función de tus necesidades, GitHub será suficiente. Ahora bien, si ya conoces el funcionamiento de la línea de comandos, emplear Git puede tener más ventajas. Los controles de versiones como Git ofrecen muchas más opciones; algunos tienen un uso específico al tiempo que otros se pueden usar de forma más generalizable. Como complemento a esta lección, te sugerimos una serie de recursos que pueden asistirte a progresar tu comprensión del control de versiones.
0 
Star