Git – Comandos Básicos #1

Siguiendo con la serie de posts Git lo estas usando mal les voy a comentar los comando básicos y algunos conceptos que nos vas a ayudar a entender un poco más.

Lugares en GIT

Para comenzar con los comandos básicos tenemos que entender que en Git podemos distinguir 4 lugares.

lugaresGit

 

El primero es el directorio local de trabajo,  es donde se trabaja, se crean nuevas funcionalidades, se arreglan bugs, se crean archivos, etc.

Luego el area de cambios (Staging), en este lugar vamos a poner todas las cosas que queramos versionar con Git.

Una vez que estemos seguros de lo que queremos versionar, lo vamos a pasar al repositorio local.

El último lugar es el repositorio remoto, donde vamos a enviar los cambios que tengamos en nuestro repositorio local, para hacerlos públicos.

A medida que vayamos viendo los diferentes comandos vamos a ir refrescando estos lugares.

Comandos Básicos

Crear repositorio

Lo primero que vamos a hacer es crear un repositorio en Github. Un repositorio es el lugar donde vamos a guardar el código fuente de nuestra aplicación.

Desde la pagina de inicio podemos crear un repo haciendo click en “+ New Repository

Ponemos un nombre de repositorio y seleccionamos “Initialize this repository with a README

2015-02-09_20-57-59

Clone

En la página del repo nos va a indicar la dirección ssh.

2015-02-09_21-03-29

Una vez que la copiamos, vamos a la consola y ejecutamos

git clone [dirección ssh]

En mi caso es

git@github.com:ignaciojonas/test-git.git

Este comando nos va a crear una carpeta (Directorio de trabajo local) con le nombre del repo que tiene, el README.md y una capeta oculta que se llama .git

Status

Con este comando vamos a ver el estado actual de nuestro repositorio local. Es importante recalcar que en Git siempre vamos a ver el estado de nuestro repositorio en nuestra maquina, ya que Git guarda toda su información localmente y te permite seguir trabajando aunque estés desconectado de internet.

Dentro de la carpeta del repositorio ejecutamos

git status

Si no cambiamos nada nos debería mostrar algo como esto:

2015-02-09_21-13-24

  • En que branch estamos parados (Ya vamos a ver esto mas adelante)
  • Si nuestro branch esta sincronizado con el repositorio en Github (por defecto el repositorio de donde clonamos se llama origin)
  • Por ultimo que no tenemos ningún cambio, y que nuestro directorio esta limpio

Si ahora modificamos el archivo README.md y le agregamos por ejemplo

Este es un repositorio de prueba para comenzar a usar Git.

Una vez que grabamos el archivo y volvemos a ejecutar git status vamos a ver algo parecido a esto:

2015-02-09_21-19-05

Las primeras lineas son lo mismo que antes, pero vemos que ahora dice “Changes not staged for commit:” y nos da instrucciones para actualizar el archivo en el repo o rechazar los cambios. Por ultimo en rojo vemos el archivo que se modificó.

Add

Con el comando add vamos a indicarle a Git que queremos agregar algo al repositorio, ya sea algo nuevo o algo que modificamos.

Por ejemplo vamos a agregar el archivo README.md

git add README.md

Cuando tenemos muchos archivos y queremos agregar todos al area de stage podemos hacerlo con

git add .

Si tenemos archivos nuevos, tenemos que agregarlos por nombre (como lo hicimos con README.md) o bien agregando todo pero usando el siguiente comando.

git add -A

Ahora cuando ejecutamos git status vemos algo como esto:

gitadd

 

Vemos en la segunda linea, “Changes to be commited”, esto quiere decir que ya tenemos los achivos seleccionados para poder grabarlos en la historia.

Ahora nuestros archivos se encuentran en el segundo lugar de Git, el area de cambios (Staging). Para tener una imagen gráfica de esto es como poner las cosas arriba del mostrador, para que después alguien del otro lado lo guarde.

Commit

El comando commit nos va a permitir “grabar” en la historia los cambios que hicimos.

git commit -m "[mensaje representativo]"

Es muy importante que los mensajes de commit (Lo que esta entre comillas dobles) sean representativos. De nada sirve un mensaje muy genêrico, como por ejemplo “Cambios Varios”, siempre es mejor ser explícitos. Pensemos que lo que escribamos en la historia de git va a ser leído por todos los de mi equipo y cada uno le puede interesar ver donde se hizo un cambio especifico.

Por ejemplo en el ejemplo que estamos siguiendo en este post un buen mensaje sería

git commit -m "README.md - Agrego información de prueba"

Cuando ejecutamos este comando vamos a ver algo asi

gitcommit

Una vez ejecutado este comando, habremos agregado los archivos al repositorio local. Este commit queda grabado en la historia de Git en mi repositorio local hasta que lo subamos a un repositorio publico.

Ahora cuando ejecutamos git status, vamos a ver que nos da un mensaje que dice: Your branch is ahead ‘origin/master’ by 1 commit. Esto quiere decir que lo que esta en Github, esta “viejo”, ya que yo tengo un cambio en mi maquina que no esta en ese repositorio publico.

gitstatusaftercommit

En este punto nuestro archivos están en el tercel lugar de Git, el repositorio local, el cambio que hicimos a README.md esta grabado en la historia de Git.

En la próxima entrega de Git – Lo estas usando mal, vamos a ver como hacemos para que todos estos cambios que hicimos localmente, lo pueda ver otro miembro de nuestro equipo, como sincronizar nuestro repositorio local con el repositorio remoto y las primeras resoluciones de conflictos.

 

Configurar GIT

Siguiendo con la serie de post, hoy les voy a comentar como tengo configurado GIT en mi maquina.

Configuración basica

Identidad

Para empezar, tenemos que configurar el nombre de usuario y el mail. Para esto ejecutamos los siguientes comandos, reemplazando con nuestro nombre y nuestro email.

$ git config --global user.name "Ignacio Jonas"
$ git config --global user.email ignaciojonas@example.com

Editor de texto

Cuando queramos editar un mensaje de un commit o hacer un rebase o algunas otras cosas que vamos a ir viendo mas adelante, algo que vamos a necesitar es un editor de texto. El que más me gusta a mi es Vim, pero ustedes pueden usar el que quieran.

$ git config --global core.editor vim

Si no se sienten cómodos usando un editor de consola pueden incluso usar cualquier otro editor gráfico. Para configurar Atom por ejemplo:

git config --global core.editor "atom --wait"

El flag –wait hace que Git espere a que cerremos el editor para commitear.

AutoCRLF

Cuando estamos trabajando en diferentes plataformas (parte del equipo en Linux, otros en Mac OS y otros en Windows) es importante prestarle atención a cómo tenemos configurado Git con respecto a los fines de línea, ya que puede que tengamos algunos problemas.

Git nos ayuda a no tener estos problemas convirtiendo los fines de linea CRLF (Windows) en fines de linea LF (Unix).

Si usas Windows conviene tenerlo configurado en true, esto convierte los fines de linea LF en CRLF cuando hacemos checkout del código.

$ git config --global core.autocrlf true

Si estas trabajando en un sistema operativo Unix (Linux o MacOS), no es necesario que Git convierta los fines de linea, sin embargo, si por casualidad introducimos un fin de linea CRLF, conviene que Git se haga cargo por nosotros de convertirlo en LF. Para esto lo configuramos con el siguiente comando.

$ git config --global core.autocrlf input

Por último, si todo el equipo esta trabajando en Windows, haciendo un proyecto para funcionar solo en Windows.

$ git config --global core.autocrlf false

Como veo las configuraciones?

Para ver como tenemos configurado Git lo único que tenemos que hacer es ejecutar el siguiente comando

$ git config --list

Configurar la clave SSH

Para poder identificarnos contra un servidor que tenga una copia de el repositorio lo podemos hacer de diferentes maneras. La más común es conectarnos usando una clave SSH.

Para todos los ejemplos de esta serie de posts, vamos a usar GitHub. Si no tenés un usuario podes registrarte acá.

Crear una clave SSH

Si tenés una clave ssh creada, entonces podes ir a Configurar la clave SSH en Github.

Para generar una clave SSH basta ejecutar el siguiente comando.

$ ssh-keygen -t rsa -C "your_email@example.com"

Cuando ejecutamos, nos va a aparecer algo parecido a lo siguiente, apretamos enter. La clave SSH se va a guardar en una carpeta .ssh dentro de la carpeta de nuestro usuario.

Generating public/private rsa key pair.
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Apretar Enter]

Luego nos va a pedir que ingresemos un passphrase. Es recomendable que pongamos una buena frase, aunque no es obligatoria.

Una vez que hecho esto tenemos la clave SSH generada.

Configurar la clave SSH en GitHub

Para agregarla a Github, lo primero que hacemos en loguearnos con nuestro usuario.

Vamos a Settings->SSH Keys y hacemos click en Add SSH Key.

GitHubSSHKeys

Completamos un titulo (Para recordar donde tenemos configurada esa clave SSH) y en el campo Key ponemos el contenido de nuestro archivo ./ssh/id_rsa.pub.

Para copiar el contenido (al menos en Mac OS) podemos ejecutar

$ pbcopy < ~/.ssh/id_rsa.pub

Este comando nos copia el contenido de la clave publica en el portapapeles.

Por último hacemos click en Add Key.

sshKey

Con esto terminamos la configuración básica de Git. En los próximos posts les voy a contar como empezamos a usarlo.

Instalar GIT

Empezando con esta serie de posts, les voy a contar como instalar GIT.

Hace muy poco me mude a trabajar en Mac OS Yosemite y un colega del trabajo me mostró iTerm2, es una consola mejorada para Mac OS. La verdad que es mejor que Terminal (Default en Mac OS). Así que te recomiendo que la instales porque mejora muchísimo la experiencia.

Si estas pensando usar GIT en Linux, la consola por default esta más que bien.

Si vas a usar Windows, te recomiendo que te instales cygwin, que es un emulador de la consola de Linux para Windows. Con esto tenes todo el poder de la consola de Linux, pero en Windows.

Si no sos muy amigo de las consolas, existen interfaces gráficas para GIT y en algún post voy a publicar algunas, pero para entender bien el funcionamiento de GIT lo mejor es la consola (@mrleinad dixit).

Instalación en Mac OS

En Mac OS, GIT, viene instalado por default, pero es recomendable que te instales la ultima version usando brew y algunos plugins más.

Antes de empezar podemos ver que GIT es el que tenes instalado, abrí iTerm y ejecutas

which git

Si la ruta de GIT es /usr/local/git entonces vamos a desinstalarlo haciendo lo siguiente (Usar sudo en los comandos cuando sea requerido).

rm -rf /usr/local/git
rm /etc/paths.d/git
rm /etc/manpaths.d/git
Ahora vamos a instalar brew con el siguiente comando:
ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Una vez instalado brew vamos a seguir con la instalación de GIT

brew install git
brew link git
Si el último comando produce un error podemos arreglarlo haciendo
brew update
brew upgrade
brew doctor
Por último instalamos git-completion que nos sirve para que la consola autocomplete los comandos de GIT cuando apretamos TAB.
brew install git bash-completion

Instalar GIT en Windows

Para empezar hay que bajarte la ultima versión de cygwin.
Ejecutas el instalador de cygwin y seleccionas todas las opciones por default hasta el menu de seleccionar paquetes (Select Package)
En ese menu hay que elegir:
  • git-gui
  • gitk
  • git-completion
  • openssh
  • vim (si no esta seleccionado por defecto)

Update: Un aporte del grande  de @andresgariglio

Instalar GIT en Linux (Ubuntu)

Simplemente

sudo apt-get install git-core git-completion

Con esto tenemos todo el ambiente funcional para empezar a aprender GIT.

Git – Lo estas usando mal

Git-Logo-1788C

Muchos sabemos que GIT es un “muy potente” sistema de control de versiones. Y también muchos pasamos horas/días tratando de entender que es lo que “esta haciendo”. Cuando me pasa eso, @falvarisqueta siempre me dice a tono de chiste “Los estas usando mal”, o también, “el problema esta entre la silla y el teclado; y no en GIT”.

En esta serie de posts (GIT – Lo estas usando mal) voy a ir publicando lo que fui aprendiendo en este último tiempo que comencé a usarlo de una forma un poco más intensiva y profesional.

Algunos de los tópicos que tengo planeados:

  • Instalar GIT
  • Configurar GIT
  • Comandos Básicos
  • Rebasing
  • Como hacer un merge
  • Re-escribir la historia
  • Workflows de Trabajos – Feature Branch