GitHub Desktop

Descargar

GitHub Desktop es una aplicación de escritorio: un programa con ventanas, botones y menús, hecho por GitHub, para trabajar con Git y con GitHub sin escribir comandos. Es gratuita y de código abierto.

Sirve para lo mismo que la terminal —guardar la historia del proyecto, subir los cambios, traer los de otros— pero con el mouse, y con una ventaja concreta: los cambios se ven. Antes de guardar algo se ve, línea por línea y en colores, exactamente qué se está por guardar.

Funciona en Windows 10 de 64 bits o posterior y en macOS 12.0 o posterior. No hay versión oficial para GNU/Linux: en Linux se usa la terminal o el panel de control de versiones del editor. La página de Git explica el camino de la terminal, que funciona en los tres sistemas.

Descargar GitHub Desktop

Qué es

Es una aplicación de escritorio que se instala como cualquier otro programa y que, al abrirla, muestra el estado del repositorio en el que se está trabajando: qué archivos cambiaron, cuáles ya se guardaron, qué rama está activa y qué falta subir. Todo lo que en la terminal es texto —git status, git diff, git log—, acá son paneles.

La ventana está organizada en tres partes, y conviene reconocerlas desde el principio:

• La barra de arriba (la barra del repositorio), que muestra el repositorio actual y la rama actual, y que tiene un botón que cambia según la situación: dice Publish repository si el proyecto todavía no está en GitHub, Fetch origin si hay que ver si el remoto tiene novedades, Pull origin si hay cambios para traer y Push origin —con un número al lado— si hay commits esperando para subir.
• La barra lateral izquierda, con dos pestañas: Changes, con los archivos que cambiaron y que todavía no se guardaron, y History, con los commits que ya están en la historia.
• El panel de la derecha, que muestra el cambio en detalle: las líneas que se agregaron y las que se sacaron, con los colores de siempre (verde lo que entra, rojo lo que sale).

Lo que la aplicación hace bien, según su propia documentación, son cuatro cosas: sirve tanto para quien empieza como para quien ya sabe; pone al alcance comandos poco frecuentes —elegir qué líneas entran en un commit, sumar un co-autor— sin tener que recordar la sintaxis; empuja a trabajar ordenado, porque para guardar algo obliga a escribir un resumen; y se integra con GitHub, incluso para iniciar sesión sin configurar nada aparte.

El uso que propone es este: usar GitHub Desktop para clonar el proyecto y crear una rama, editar los archivos en el editor de siempre —por ejemplo VS Code—, y volver a GitHub Desktop para guardar y subir los cambios. La aplicación no reemplaza al editor: lo acompaña.

La diferencia con Git

Esta es la parte que hay que entender bien, porque es la que suele quedar confusa: GitHub Desktop no reemplaza a Git. Es una interfaz que lo maneja.

Git es el programa que hace el trabajo: guarda la historia, calcula las diferencias entre versiones, mezcla ramas, habla con el servidor. GitHub Desktop es una cara visible puesta encima de ese programa: una ventana con botones que, cuando se aprieta un botón, le pide a Git que haga lo suyo. Cada vez que se aprieta Commit to main, por debajo se ejecuta lo mismo que escribiría un comando en la terminal. La diferencia es quién lo escribe: el dedo de una persona o un botón.

Lado a lado

Tres ideas para no confundirse

• GitHub Desktop trae su propio Git. Por eso funciona apenas se instala, sin que haya que instalar Git antes. Pero es un Git propio, manejado por dentro de la aplicación: no es el mismo comando git que se escribe en la terminal. Si además se quiere usar la terminal —o VS Code, o el servidor— hay que instalar Git aparte. Las dos cosas conviven sin problema, incluso sobre el mismo repositorio.
• GitHub no es GitHub Desktop. GitHub es el sitio web donde se guardan los repositorios. GitHub Desktop es el programa que se instala en la computadora. El nombre parecido es lo que confunde.
• La aplicación está pensada para GitHub, pero no lo exige. Se autentica sola con la cuenta y aprovecha todo lo de GitHub —pull requests, ver los chequeos de una rama—, y también puede trabajar con otros servidores de repositorios.

¿Entonces conviene aprender Git igual?

Sí, y por cuatro razones que aparecen tarde o temprano:

• Cuando algo sale mal, los mensajes son de Git. Un conflicto, un rebase enredado, un archivo que no se puede subir: los avisos y sus explicaciones están escritos en los términos de Git, no en los de la interfaz.
• La documentación, los tutoriales y las respuestas de los foros están escritas en comandos. Saber leerlos ahorra horas.
• En cualquier servidor o computadora con Linux no hay GitHub Desktop: la terminal es el único camino.
• Sirve para entender qué está pasando. Apretar un botón sin saber qué hace por debajo funciona hasta el día que algo falla.

No es una cosa o la otra: lo razonable es usar la aplicación para el trabajo de todos los días y saber los comandos para entenderla y para salir del paso cuando hace falta. Los comandos con su explicación están en Comandos básicos, de la página de Git.

Instalación en Windows

Requiere Windows 10 de 64 bits o posterior. En un sistema de 32 bits no funciona.

1. Descargar. En desktop.github.com, el botón de descarga para Windows. Baja un archivo instalador que termina en .exe.
2. Ejecutarlo con doble clic y esperar. La instalación es rápida y no hace preguntas: no hay que elegir carpeta ni componentes.
3. Al terminar, la aplicación se abre sola. No hace falta buscarla en el menú Inicio, aunque después queda ahí para las próximas veces.
4. Iniciar sesión. Es el paso que le permite conectarse con GitHub. En Windows se hace por File → Options → Accounts → Sign Into GitHub.com; en la pantalla de bienvenida de la primera vez, el mismo botón aparece directamente. Se abre el navegador, se autoriza la aplicación y la sesión queda guardada.

En una red administrada —un colegio, una empresa— existe además un paquete .msi pensado para instalarla de forma remota con políticas de grupo. Es un dato para el administrador, no para el uso normal.

Instalación en macOS

Requiere macOS 12.0 o posterior. La página de descarga ofrece dos versiones distintas: una para las Mac con procesador Apple Silicon (M1 y posteriores) y otra para las Mac con procesador Intel. Hay que bajar la que corresponda; si no se está seguro, el propio sistema lo dice en Acerca de esta Mac del menú Apple.

1. Descargar el archivo, que llega comprimido en un .zip.
2. Descomprimirlo con doble clic: aparece el ícono de GitHub Desktop.
3. Abrir la aplicación con doble clic. Conviene antes arrastrarla a la carpeta Aplicaciones, para que quede instalada y no suelta en Descargas.
4. Confirmar la primera apertura. Como la aplicación se bajó de internet, macOS puede pedir una confirmación la primera vez —¿seguro que querés abrirla?—. Es el control normal del sistema para todo lo que se descarga; se acepta y no vuelve a preguntar.
5. Iniciar sesión. En macOS el menú se llama distinto que en Windows: hay que ir al menú GitHub Desktop → Settings → Accounts → Sign Into GitHub.com. Se abre el navegador, se autoriza y listo.

Este es el único detalle donde los dos sistemas se comportan distinto en la aplicación: lo que en Windows es File → Options, en macOS es GitHub Desktop → Settings. El resto de la ventana es igual.

Primeros pasos

La primera vez que se abre, la aplicación muestra una pantalla —Let's get started!— con las cuatro formas de empezar. Cada una equivale a un comando de Git, y verlas juntas es la mejor manera de entender la relación entre las dos cosas:

Crear un repositorio nuevo

La ventana Create a New Repository tiene estos campos, y cada uno hace algo concreto:

• Name. El nombre del repositorio. Va a ser el nombre de la carpeta en la computadora y el nombre en GitHub.
• Description. Opcional. Una línea sobre para qué sirve el proyecto.
• Local path. Dónde se guarda en la computadora. Por omisión, la aplicación crea una carpeta GitHub adentro de Documentos y guarda ahí todo; se puede elegir cualquier otra ubicación. El repositorio queda como una subcarpeta dentro de esa ruta: si el nombre es Tutorial, se crea la carpeta Tutorial adentro de la ruta elegida.
• Initialize this repository with a README. Crea de entrada un archivo README.md con el primer commit. Conviene dejarlo marcado: es el archivo que GitHub muestra al entrar al repositorio, y sirve para explicar de qué se trata el proyecto.
• Git ignore. Permite elegir una plantilla de archivo .gitignore según el lenguaje o la herramienta. Si no se sabe qué elegir, se puede dejar sin tocar: el archivo se puede crear después, a mano.
• License. Agrega un archivo de licencia al proyecto. No es urgente decidirlo ahora.

Se aprieta Create repository y queda creado, con un primer commit firmado por la aplicación. Todavía existe solo en la computadora: para que esté en GitHub hay que publicarlo, y eso es el botón Publish repository de la barra de arriba —que pide confirmar el nombre, la descripción y, si se quiere, marcar Keep this code private para que no sea público—. Publicar es lo mismo que vincular el repositorio remoto y subir: git remote add origin más git push -u origin main.

Traer uno que ya existe

Clone a repository from the Internet… abre una ventana con dos pestañas: URL, donde se pega la dirección del repositorio —la que GitHub muestra en el botón verde Code— y GitHub.com, donde aparecen los repositorios de la cuenta con la que se inició sesión. Se elige dónde guardarlo en Local path y se confirma. Es el camino más rápido para conseguir el código de un trabajo práctico que ya está publicado.

Cómo se usa: el ciclo de todos los días

El trabajo diario con GitHub Desktop tiene siempre la misma forma. Se ve mejor con el ciclo completo:

1. Editar. Los archivos se modifican en el editor de siempre. La aplicación no edita nada: solo mira lo que pasa en la carpeta. Desde el menú Repository → Open in EDITOR se abre el editor configurado, ya parado en el proyecto.
2. Mirar la pestaña Changes. Ahí aparece la lista de archivos que cambiaron, cada uno con un ícono de color según lo que pasó: rojo si se borró, amarillo si se modificó, verde si es nuevo. Al lado de cada archivo hay un casillero: lo que esté marcado entra en el próximo commit y lo que no, queda para después. El casillero de arriba de todo marca o desmarca todos a la vez.
3. Revisar el cambio. Al hacer clic en un archivo, el panel de la derecha muestra qué líneas se agregaron y cuáles se sacaron. Es el momento de darse cuenta de que uno estaba por guardar algo que no quería. Se puede cambiar cómo se ve —Unified o Split, según se prefiera una lista o dos columnas— desde el engranaje del panel.
   Commit parcial. Si un archivo tiene dos cambios distintos y se quieren guardar por separado, se puede: en el panel del cambio se hace clic sobre las líneas que no deben entrar y el resaltado azul desaparece. Lo que queda en azul es lo que se va a guardar. En la terminal lo mismo se hace con git add -p.
4. Guardar (commit). Abajo de la lista están los campos Summary —una línea con lo que se hizo— y Description —opcional, para explicar más—. Después se aprieta el botón, que se llama Commit to main o Commit to el nombre de la rama en la que se esté trabajando. El nombre de la rama en el botón es a propósito: es el último aviso de dónde va a caer el commit.
5. Subir (push). El botón de la barra de arriba ahora dice Push origin, con un número que indica cuántos commits están esperando. Se aprieta y los cambios van a GitHub. Si el proyecto todavía no estaba publicado, ese mismo botón dice Publish repository.
6. Traer lo del remoto. Antes de empezar a trabajar, y cada vez que alguien más haya subido algo, van Fetch origin —que solo pregunta si hay novedades— y Pull origin, que se las trae. Es lo primero que hay que hacer al sentarse a trabajar en un proyecto compartido.
7. Mirar la historia. La pestaña History lista los commits de la rama actual. Al hacer clic en uno se ven los archivos que tocó y, archivo por archivo, el cambio exacto de ese commit. Es la respuesta a «¿cuándo se rompió esto?» y a «¿quién lo cambió?».

El botón y su comando

La mejor forma de ver que la aplicación y la terminal hacen lo mismo es ponerlos uno al lado del otro. Cualquiera de estas dos columnas deja el repositorio en el mismo estado:

Hasta dónde llega

La aplicación cubre mucho más de lo que parece: además de lo del día a día, permite reordenar commits arrastrándolos, juntar varios commits en uno (squash), aplicar un commit suelto de otra rama (cherry-pick), guardar cambios sin confirmarlos, fusionar y reordenar ramas, y crear o revisar pull requests. Para un trabajo práctico de la escuela alcanza y sobra.

Pero no es todo Git, y hay tres situaciones en las que la terminal sigue siendo el único camino:

• Cuando algo se enreda de verdad. Un conflicto con muchas ramas, una historia que hay que reescribir a mano, un repositorio que quedó en un estado raro. La interfaz hace lo que puede; la terminal hace todo.
• Cuando no hay entorno gráfico. En un servidor con Linux, en una Raspberry Pi o en una computadora compartida no hay dónde instalar la aplicación: ahí se trabaja con comandos, y no hay alternativa.
• Cuando hay que automatizar. Un script que haga un commit todos los días, una tarea repetitiva, algo que corra solo: todo eso se escribe en comandos.

Por eso lo mejor de los dos mundos es usarlos juntos: GitHub Desktop para el trabajo de todos los días, porque hace visible lo que está pasando y evita errores de tipeo, y los comandos de Git para entenderla y para salir del paso el día que la interfaz no alcance. Sobre el mismo repositorio, indistintamente.