Git (Español)

Esta traducción de Git fue revisada el 2018-01-08. Si existen cambios puede actualizarla o avisar al equipo de traducción.

Artículos relacionados

• Gitweb
• Cgit
• HTTP tunneling#Tunneling Git
• Subversion
• Concurrent Versions System

"He conocido personas que piensan que git es la interfaz de Github, están equivocados, git es la interfaz de AUR" — Linus T.

Git es un software de control de versiones diseñado y desarrollado por Linus Torvalds, el creador del kernel de Linux. Git es usado para mantener los paquetes en AUR, y en bastantes proyectos, incluidas las fuentes para el kernel de Linux.

Instalación

Instale el paquete git. Para la versión en desarrollo instale el paquete git-git^AUR. Verifique los requerimientos opcionales al usar git svn, git gui and gitk.

Programas Gráficos

Véase también Clientes gráficos de Git.

• Giggle — Cliente gráfico de git basado en GTK+.

https://wiki.gnome.org/Apps/giggle/ || giggle

• Git Cola — Elegante y poderosa interfaz de usuario escrita en Python.

https://git-cola.github.io/ || git-cola^AUR

• Git Extensions — Interfaz de usuario para git sin necesidad de usar la terminal.

https://gitextensions.github.io/ || gitextensions^AUR

• gitg — Interfaz de GNOME para ver repositorios git.

https://wiki.gnome.org/Apps/Gitg || gitg

• git-gui — Interfaz gráfica de usuario basada en Tcl/Tk.

https://git-scm.com/docs/git-gui || git + tk

Nota: Para activar corrección de lenguaje en git-gui, el paquete aspell es necesario, asi como el diccionario correspondiente con la variable de entorno LC_MESSAGES. Vea FS#28181 y el articulo aspell.

• gitk — Navegador de repositorios git basada en Tcl/Tk.

https://git-scm.com/docs/gitk || git + tk

• QGit — Interfaz gráfica de usuario para navegar revisiones, historia, parches y cambios en archivos.

https://github.com/tibirna/qgit || qgit

• RabbitVCS — Grupo de herramientas gráficas hechas para proporcionar acceso simple a su sistema de control de versiones.

http://rabbitvcs.org/ || rabbitvcs^AUR

• Tig — Interfaz para git basada en ncurses.

https://jonas.github.io/tig/ || tig

• ungit — Proporciona facilidad en git para el usuario sin sacrificar la versatilidad.

https://github.com/FredrikNoren/ungit || nodejs-ungit^AUR

• GitHub Desktop — Iterfaz gráfica de usuario basada en Electron, escrita por Github.

https://github.com/desktop/desktop || github-desktop^AUR

Configuración

Para usar Git es necesario usar un usuario y correo electrónico:

$ git config --global user.name  "Pablo Perez"
$ git config --global user.email "pabloperez@ejemplo.com"

Vea #Trucos y consejos para mas configuraciones.

Uso

Este tutorial muestra como usar Git para controlar y revisar de manera básica distribuida un proyecto.

Git es un sistema de control de versiones, lo cual quiere decir que la historia completa de los cambios hechos a un repositorio es guardada localmente, en una carpeta llamada ./.git en el directorio del proyecto. Los archivos del proyecto que son visibles al usuario constituyen el árbol de trabajo. Estos archivos pueden ser actualizados para coincidir con las revisiones guardadas en ./.git usando los comandos de git (v.g. git checkout), nuevas revisiones pueden ser creadas al modificar estos archivos y ejecutar el comando de git apropiado (e.g. git commit).

Vea gitglossary(7) para una definicion mas completa de los terminos usados en este tutorial.

El proceso de trabajo típico con Git es:

1. Cree un proyecto nuevo o clone un proyecto remoto.
2. Cree una rama para implementar cambios, y confirme (git commit) esos cambios.
3. Consolide sus cambios para una mejor organización y entendimiento.
4. Incorpore (git merge) sus cambios en la rama principal.
5. (Opcional) Suba (git push) los cambios a un servidor remoto.

Repositorio local

Preparación

Inicializar un nuevo repositorio. Esto creara e iniciará ./.git:

$ cd (su proyecto)/
$ git init

Para guardar cambios en archivos del repositorio, estos tiene que ser agregados al index o área de preparación, esta operación también es conocida como preparar. Cuando se confirman los cambios usando git commit, son los archivos contenidos en el index los que se confirman en la rama actual, y no el contenido del árbol de trabajo.

Nota: El index es de hecho un archivo binario .git/index, el cual puede ser consultado con git ls-files --stage.

Para agregar archivos al index del árbol de trabajo:

$ git add archivo1 archivo2

Esto guarda el estado actual de los archivos. Si los archivos son modificados, se puede ejecutar git add de nuevo para "agregar" la nueva versión al index.

Agregar todos los archivos:

$ git add .

Sugerencia: Para ignorar algunos archivos del comando git add ., cree un archivo llamado .gitignore:

.gitignore

# Archivo que posiblemente borrare
test-script

# Ignore todos los archivos .html, excepto 'importante.html'
*.html
!important.html

# Ignore todos los archivos recursiva mente en el directorio 'NoIncluir'
NoIncluir/**

Vea gitignore(5) para más detalles.

Remueva un archivo de la área de trabajo (--cached preserva el estado actual de los archivos):

$ git rm (--cached) archivo

Remueva todos los archivos:

$ git rm --cached -r .

O también:

$ git reset HEAD -- .

En este caso, HEAD es una "referencia simbólica" a la revisión actual.

Renombrar un archivo:

$ git mv archivo1 archivo2

Nota: git mv es un comando conveniente, es casi equivalente a mv archivo1 archivo2 seguido por git rm archivo1 y git add archivo2. La deteción de re-nombramiento durante la incorporación esta basada en la similitud del contenido, se ignora el método usado para el re-nombramiento del archivo. La razón de esto, que diferencia a Git de sistemas basados en parches como Darcs, puede ser vista aquí.

Listado de archivos:

$ git ls-files

Por defecto, este comando muestra los archivos en la área de trabajo, archivos --cached.

Confirmar cambios

Una vez el contenido a ser guardado esta preparado, confirme ejecutando:

$ git commit -m "Primera confirmación."

El parámetro -m (--message) es para un mensaje corto, si se omite el editor pre seleccionado abrirá para permitir un mensaje más extenso.

Sugerencia:

• Siempre confirme cambios pequenos con mensajes significativos.
• Para agregar todos los archivos modificados al index y confirmarlos en un solo comando, use el parametro -a (--all), "todo"):

$ git commit -am "Primera confirmación."

Modifique el mensaje de confirmación para la ultima confirmación. Esto también alterara la confirmación con los archivos que se preparado:

$ git commit --amend -m "Mensaje."

Algunos de los comandos en este articulo toman confirmaciones como argumentos. Una confirmación puede ser identificada por uno de los siguientes métodos:

• El resumen criptográfico de 40 dígitos SHA-1 (usualmente los primeros 7 dígitos son suficientes para identificar la confirmación de manera única)
• La etiqueta de la confirmación, ya sea la el nombre de la rama o la marca (tag)
• La etiqueta del HEAD siempre se refiere la rama en la cual se encuentre actualmente (generalmente la ultima modificación de la rama, a menos que se haya usado git checkout para revisar una versión anterior)
• Cualquier caso anterior más ~ para referirse a una confirmación anterior. Por ejemplo, HEAD~ se refiere a una confirmación antes de HEAD, y HEAD~5 se refiere a cinco confirmaciones antes de HEAD.

Ver cambios

Mostrar diferencias entre confirmaciones:

$ git diff HEAD HEAD~3

o diferencias entre área de preparación y el árbol de trabajo:

$ git diff

Obtenga un resumen general de los cambios:

$ git status

Ver historico de cambios (donde "-N" es el numero de confirmaciones anteriores):

$ git log -p (-N)

Ramas en un repositorio

Modificaciones y nuevas características son usualmente examinadas en ramas. Cuando los cambios son satisfactorios se pueden incorporar en la rama principal (master).

Crear una rama, cuyo nombre refleja su propósito:

$ git branch agregar-seccion-ayuda

Listado de ramas:

$ git branch

Cambiar de rama:

$ git checkout rama

Crear y cambian:

$ git checkout -b rama

Incorporar una rama a la rama principal:

$ git checkout master
$ git merge rama

Los cambios serán incorporados si no hay conflictos. En caso de haberlos, Git mostrara un mensaje de error, y anotara los archivos en el árbol de trabajo grabando los conflictos. Las anotaciones pueden ser vistas con git diff. Conflictos son resueltos modificando los archivos,removiendo las anotaciones y confirmando la versión final. Vea #Trabajando con fusiones en la parte de abajo.

Cuando se haya terminado el trabajo en una rama, bórrela con:

$ git branch -d branch

Colaboración

Adoptando una buena etiqueta

• Cuando se considere contribuir a un proyecto existente, lea y entienda su licencia, ya que esta puede limitar excesivamente la habilidad para modificar el código. Algunas licencias pueden generar disputas sobre la autoría del código.
• Piense sobre la comunidad del proyecto y que tan bien se puede encajar allí. Para tener un sentimiento del rumbo del proyecto, lea la documentación e incluso el histórico del repositorio.
• Cuando se solicite incluir (pull) una confirmación, o se suba un parche, mantenga el cambio pequeño, conciso y documentado; esto ayudara a los mantenedores a entender sus cambios y decidir si los incorporan, o para preguntar por una corrección.
• Si una contribución es rechazada, no se desanime, el proyecto es de ellos. Si es importante, discuta las razones para la contribución tan clara y pacientemente como sea posible: con este procedimiento una solución puede que eventualmente sea posible.

Clonar un repositorio

Para comenzar a contribuir a un proyecto, clone el repositorio de este:

$ git clone lugar directorio

lugar puede ser una ruta o dirección de Internet. Cuando la clonación haya terminado, el lugar sera guardado y solo se necesitara un git pull para actualizar el repositorio.

Solicitud de cambio

Después de hacer algunos cambios, un contribuidor puede preguntarle al autor original de incorporar dichos cambios. Esto se denomina una solicitud de cambio (pull request).

Para obtener (pull):

$ git pull lugar master

El comando pull combina los comandos recuperar (fetch) y fusionar (merge). Si hay conflictos (v.g. cuando el autor original hizo cambios la mismo tiempo), sera necesario solucionarlos manualmente.

Alternativamente, el autor original puede seleccionar los cambios que quiere incorporar. Usando la opción fetch (y la opción log con un símbolo FETCH_HEAD especial), el contenido de la solicitud puede ser visto antes de ser incorporado:

$ git fetch lugar master
$ git log -p HEAD..FETCH_HEAD
$ git merge lugar master

Usando remotos

Remotos son apodos para rastrear repositorios remotos. Una etiqueta es creada definiendo el lugar. Estas etiquetas son usadas para identificar repositorios de frecuente acceso.

Crear un remoto:

$ git remote add etiqueta lugar

Recupere (fetch) un remoto:

$ git fetch etiqueta

Mostrar diferencias entre la rama principal y la rama principal del remoto:

$ git log -p master..etiqueta/master

Ver remotos del repositorio actual:

$ git remote -v

Cuando se define un remoto que es el predecesor de una bifurcación (lideres del proyecto), se define como upstream (versión original).

Publicar en un repositorio

Después de tener acceso para modificar el repositorio, dado por los autores originales, publique (push) sus cambios con:

$ git push lugar rama

Cuando se ejecute git clone, se guarda el lugar original y se le da el nombre remoto de origin.

Asi, que lo que típicamente se ejecuta es:

$ git push origin master

Si se usa el parámetro -u (--set-upstream-to), el lugar va a ser guardado y la próxima vez simplemente git push es necesario.

Trabajando con fusiones

Vea Procedimiento para fusionar el el libro de Git para una explicación más extensa para solucionar conflictos en fusiones. Fusiones son generalmente reversibles. Si se desea cancelar una fusión, se puede usar el parámetro --abort (v.g. git merge --abort o git pull --abort).

Enviar un parche a una lista de correo

Si desea enviar parches directamente a una lista de correo, necesita instalar los siguientes paquetes: perl-authen-sasl, perl-net-smtp-ssl y perl-mime-tools.

Asegúrese de tener su usuario y correo electrónica configurado, vea#Configuración.

Modifique la configuración de su e-mail:

$ git config --global sendemail.smtpserver smtp.gmail.com
$ git config --global sendemail.smtpserverport 587
$ git config --global sendemail.smtpencryption tls
$ git config --global sendemail.smtpuser foobar@gmail.com

Ahora debe ser posible enviar el parche a la lista de correo:

$ git add nombre-archivo
$ git commit -s
$ git send-email --to=nombre-lista@servidorlista.org --confirm=always -M -1

Histórico y revisiones

Buscar en el histórico

git log mostrará el histórico con confirmaciones, resumen criptográfico, autor, fecha y el mensaje corto. El resumen-criptográfico es el "nombre del objeto" de una confirmación, típicamente 40 digitos SHA-1.

Para el histórico con el mensaje extenso (el "resumen-criptográfico" puede ser truncado, mientras que se mantenga único):

$ git show (resumen-criptográfico)

Buscar por un modelo en los archivos que están siendo rastreados:

$ git grep modelo

Buscar en archivos terminados con .c y .h:

$ git grep modelo -- '*.[ch]'

Revisiones para lanzamientos

Etiqueta (tag) de confirmaciones para revisiones:

$ git tag 2.14 resumen-criptográfico

Etiquetar se efectúa generalmente para lanzamientos/revisiones pero puede ser cualquier cadena de caracteres. Generalmente etiquetas anotadas son usadas, porque estas se agregan a la base de datos de Git.

Etiquete la confirmación actual con:

$ git tag -a 2.14 -m "Versión 2.14"

Listado de etiquetas:

$ git tag -l

Borrar una etiqueta:

$ git tag -d 2.08

Actualizar etiqueta remota:

$ git push --tags

Organizando confirmaciones

Antes de solicitar cambios en un repositorio, es deseable consolidar/reorganizar las confirmaciones. Esto se puede hacer con git rebase y el parámetro --interactive:

$ git rebase -i resumen-criptográfico

Este comando abrirá un editor de texto con un resumen de todas las confirmaciones en el rango especificado; en el caso del comando anterior, incluyendo la confirmación mas reciente (HEAD) y hasta, pero excluyendo la confirmación resumen-criptográfico. Es posible usar notación de numérica, use por ejemplo HEAD~3, el cual incluirá las ultimas tres confirmaciones:

pick d146cc7 Test punto de montaje.
pick 4f47712 Explicación parámetro -o en el readme.
pick 8a4d479 Re nombrado de la documentación.

Modificando la acción en la primera columna dictara como se hará la reorganización. Las opciones son:

• pick — Use esta confirmación como esta (por defecto).
• edit — Edite archivos y/o mensaje de confirmación.
• reword — Edite mensaje de confirmación.
• squash — Fusión/envuelva con la confirmación anterior.
• fixup — Fusión/envuelva con la confirmación anterior descartando su mensaje.

Las confirmaciones pueden ser re ordenadas o borradas del histórico (pero sea muy cuidadoso). Después de modificar un archivo, Git ejecutara la acción especificada; si se le pregunta resolver problemas, solucionelos y continue con git rebase --continue o cancele la reorganización con el comando git rebase --abort.

Nota: La opción Squash en las confirmaciones, solo es usado en confirmaciones locales, creara problemas en repositorios compartidos con mas usuarios.

Trucos y consejos

Usar git-config

Git lee su configuración de unos pocos archivos de configuración:

• Cada repositorio contiene un archivo .git/config para configuracion especifica.
• Cada usuario tiene un archivo $HOME/.gitconfig para configuraciones por defecto.
• /etc/gitconfig es usado para configuraciones por defecto a nivel del sistema.

Estos archivos pueden ser modificados directamente, pero la manera recomendada para hacerlo es con git config, como se muestra en el siguiente ejemplo:

Listado de las siguientes variables establecidas:

$ git config {--local,--global,--system} --list

Establezca el editor de texto por defecto a vim o nano:

$ git config --global core.editor "nano -w"

Establezca la acción de publicar por defecto:

$ git config --global push.default simple

Establezca una herramienta diferente para git difftool (meld por defecto):

$ git config --global diff.tool vimdiff

Vea git-config(1) y Configuración de Git para más información.

Acelerar verificación

Es deseable evitar tener que iniciar sesión interactiva mente en cada publicación al servidor Git.

• Si se esta usando verificación con llaves SSH, use el agente de SSH. Vea tambien SSH#Acelerando SSh y SSH#Mantener la sesión activa.
• Si se esta usando verificación con usuario y contrasena, cambie a llaves de SSH si el servidor es compatible con SSH. De otra manera intente con git-credential-cache o git-credential-store.

Valores por defecto del protocolo

Si se esta usando una conexión multiplexada, Git por SSH puede ser más rápido que por HTTPS. Algunos servidores (como AUR), solo admiten publicar con SSH. Por ejemplo, la siguiente configuración establecerá Git sobre SSH para cualquier repositorio alojado en AUR.

~/.gitconfig

[url "ssh://aur@aur.archlinux.org/"]
	insteadOf = https://aur.archlinux.org/
	insteadOf = http://aur.archlinux.org/
	insteadOf = git://aur.archlinux.org/

Servidor Git

Como configurar la conexión a diferentes repositorios dependiendo en el protocolo usado.

SSH

Para usar el protocolo SSH, primero genere una llave publica; para ello siga la guía en llaves SSH. Para montar un servidor SSH, siga la guie en SSH.

Con un servidor SSH funcional y llaves generadas, copie el contenido de ~/.ssh/id_rsa.pub a ~/.ssh/authorized_keys (asegúrese que sea una sola linea). Ahora puede acceder al repositorio Git ejecutando:

$ git clone usuario@ejemplo.com:mi_repositorio.git

Ahora SSH le hará una pregunta de si/no, si se tiene la configuración StrictHostKeyChecking (por d efecto). Teclee yes seguido de Intro. Ahora se debe tener acceso al repositorio. Gracias a que la configuración es con SSH también debe tener derecho para hacer confirmaciones.

Para modificar un repositorio existente para usar SSH, el lugar remoto debe ser re-definido:

$ git remote set-url origin git@localhost:mi_repositorio.git

Conexiones en un puerto diferente al 22 pueden ser configuradas en base a cada servidor, en /etc/ssh/ssh_config o ~/.ssh/config. Para configurar puertos para un repositorio (en este ejemplo 443):

.git/config

[remote "origin"]
    url = ssh://usuario@ejemplo.com:443/~mi_repositorio/repo.git

Es posible proteger incluso más la cuenta de SSH del usuario, aceptando solo comandos de descarga (pull) o de publicación (push) para ese usuario. Esto se hace reemplazando la shell de inicio de sesión por defecto con git-shell. Descripción en Git en el servidor.