Git (Español)

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.

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

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

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

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

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 "[e-mail]"

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 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 usando los comandos de (v.g. ), nuevas revisiones pueden ser creadas al modificar estos archivos y ejecutar el comando de apropiado (e.g. ).

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 () esos cambios.
3. Consolide sus cambios para una mejor organización y entendimiento.
4. Incorpore () sus cambios en la rama principal.
5. (Opcional) Suba (git push) los cambios a un servidor remoto.

Preparación

Inicializar un nuevo repositorio. Esto creara e iniciará :

$ 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 , son los archivos contenidos en el index los que se confirman en la rama actual, y no el contenido del árbol de trabajo.

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 de nuevo para "agregar" la nueva versión al index.

Agregar todos los archivos:

$ git add .

Remueva un archivo de la área de trabajo ( 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, es una "referencia simbólica" a la revisión actual.

Renombrar un archivo:

$ git mv archivo1 archivo2

Listado de archivos:

$ git ls-files

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

Confirmar cambios

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

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

El parámetro 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 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, se refiere a una confirmación antes de , y HEAD~5 se refiere a cinco confirmaciones antes de .

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

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

puede ser una ruta o dirección de Internet. Cuando la clonación haya terminado, el lugar sera guardado y solo se necesitara un  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 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 .

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

$ git push origin master

Si se usa el parámetro , 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 (v.g. git merge --abort o ).

Enviar un parche a una lista de correo

Si desea enviar parches directamente a una lista de correo, necesita instalar los siguientes paquetes: , y .

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 [e-mail]

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

$ git add nombre-archivo
$ git commit -s
$ git send-email --to=[e-mail] --confirm=always -M -1

Buscar en el histórico

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 :

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

$ 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 () y hasta, pero excluyendo la confirmación . 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:

• — Use esta confirmación como esta (por defecto).
• — Edite archivos y/o mensaje de confirmación.
• — Edite mensaje de confirmación.
• — Fusión/envuelva con la confirmación anterior.
• — 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 o cancele la reorganización con el comando .

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 para configuracion especifica.
• Cada usuario tiene un archivo $HOME/.gitconfig para configuraciones por defecto.
• es usado para configuraciones por defecto a nivel del sistema.

Estos archivos pueden ser modificados directamente, pero la manera recomendada para hacerlo es con , 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 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.

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 a (asegúrese que sea una sola linea). Ahora puede acceder al repositorio Git ejecutando:

$ git clone [e-mail]:mi_repositorio.git

Ahora SSH le hará una pregunta de si/no, si se tiene la configuración StrictHostKeyChecking (por d efecto). Teclee seguido de . 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 o . 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.