Es:EGit/Es:User Guide

Comenzar

Visión General

Si se es un novato con Git o generalmente con sistemas de control de versiones, entonces puede que se quiera leer primero Git para usuarios de Eclipse. Se pueden encontrar más detalles en el libro online Pro Git.

Si se viene del mundo de CVS, se pueden encontrar flujos de trabajo CVS comunes para GIT Flujos de trabajo Git(inglés).

Tutorial básico: Añadir un proyecto al control de versiones

Configuración

Identificarse uno mismo

Cuando quiera que se cambie la historia del repositorio (técnicamente, cada vez que sea creada una acometida), Git conserva un seguimiento del usuario que creó esa acometida. La identificación consiste en un nombre (típicamente el de una persona) y una dirección de correo electrónico. Esta información se almacena en el archivo ~/.gitconfig bajo claves específicas.

EGit le preguntará por esta información cuando cree su primera acometida. Por defecto, este diálogo se muestra solamente una vez hasta que usted cree un nuevo espacio de trabajo o pinche en el casillero "Mostrar diálogo de configuración inicial" en la página Preferencia de Git:

Puede de-seleccionar el casillero "No mostrar este diálogo otra vez" si quiere verlo luego.

En vez de usar este diálogo, siempre puede cambiar esta información usando la configuración de Git:

• Pinche Preferencias > Equipo > Configuración (Preferences > Team > Git > Configuration)
• Pinche Nueva entrada (New Entry) e introduzca la pareja clave valor user.email y user.name
  

Establecer el directorio Home Directory de Windows

Añada la variable de entorno HOME a sus variables de entorno.

1. En Windows 7, escriba ("entorno") "environment" en el menú de inicio.
2. Seleccione ("Editar variables de entorno para su cuenta") "Edit environment variables for your account".
3. Pinche en el botón ("Nuevo") "New".
4. Introduzca "HOME" en el campo de nombre.
5. Introduzca "%USERPROFILE%" o alguna otra ruta en el campo de valor.
6. Pinche OK, y OK otra vez. Justo acaba de añadir el directorio Home en Windows.
   

Note que si usa Cygwin, debería ya tener el HOME establecido. Por ejemplo, si instaló Cygwin en C:\cygwin y su nombre de usuario es Fred, entonces Cygwin ya debería tener establecido el HOME a C:\cygwin\home\Fred (o algo similar). Puede verificar esto introduciendo echo %HOME% en la línea de comandos de Windows, o echo $HOME en la shell de Cygwin.

EGit necesita esta ruta para buscar la configuración de usuario (.gitconfig). HOME debería apuntar a su directorio personal p. ej. C:\Users\Tom. ¡Asegúrese del tamaño de letra! P. ej. C:\users en vez de C:\Users puede causar problemas (!)

Si la variable HOME no está definida el directorio personal se calculará concatenando HOMEDRIVE y HOMEPATH.

Si ambas HOME y HOMEDRIVE no están definidas se usará HOMESHARE.

Si HOMEPATH no está definida, ¿qué sucede?

EGit muestra un aviso si HOME no se define explícitamente. Recuerde que si establece la variable de entorno HOME mientras que Eclipse esté ejecutándose, verá aún así el aviso siguiente. Tendrá que reiniciar Eclipse para que reconozca el valor de HOME.

Señalar la configuración global del Sistema

Si utiliza Git para Windows como compañero de EGit, asegúrese de que EGit conoce dónde se halla instalado tal que pueda encontrar las "configuraciones globales del sistema", p. ej. cómo se establece core.autocrlf. Vaya a las configuraciones y busque en (Equipo>Git>Configuración) Team>Git>Configuration y entonces a la pestaña (Configuraciones de Sistema) System Settings.

Si ha seleccionado una de las opciones para usar Git desde el símbolo de sistema cuando instaló Git para Windows, entonces el sitio de la configuración global de sistema está rellenado con la ruta y lo demás está bien. Si no, use el botón de explorar para localizar dónde se instaló el Git, p. ej. C:\Program Files(x86)\Git.

Este consejo también sirve para usuarios de otros embalajes Git, p. ej. Git bajo Cygwin o TortoiseGit.

Los usuarios No-Windows deberían en teoría comprobar esta configuración, pero las configuraciones globales del sistema normalmente no se utilizan en plataformas No-Windows.

Crear Repositorio

• Cree un nuevo proyecto Java HelloWorld. (En este caso, el proyecto se construyó fuera del espacio de trabajo o Workspace de Eclipse.)

• Seleccione el proyecto, pinche Archivo > Equipo > Compartir proyecto (File > Team > Share Project).
• Seleccione tipo de repositorio Git y pinche Siguiente (Next).

• Para configurar el repositorio Git seleccione el nuevo proyecto HelloWorld.

• Pinche (Crear Repositorio) Create Repository para inicializar un nuevo repositorio Git para el proyecto HelloWorld. Si su proyecto ya reside en el árbol de trabajo de un repositorio existente de Git el repositorio se elige automáticamente.

• Pinche (Finalizar) Finish para cerrar el asistente.
• El texto decorador "[master]" tras el proyecto muestra que este proyecto se sigue en un repositorio en la rama master y los decoradores de partícula interrogativa muestran que los archivos .classpath y .project y el .settings no están aún bajo ningún control de versiones.

Seguir Cambios

• Pinche Equipo > Añadir (Team > Add) en el nodo proyecto. (Este ítem de menú puede leerse como Añadir al Índice (Add to Index) en versiones recientes de Egit.)
• Los decoradores + muestran que los archivos del proyecto han sido añadidos al control de versiones.
• Marque la carpeta "bin" como "ignorada por Git", bien haciendo clic derecho en ella y seleccionando Equipo > Ignorar (Team > Ignore) o bien creando un archivo .gitignore en la carpeta de proyecto con el siguiente contenido:

/bin

• Esto excluye a la carpeta bin de la lista de archivos seguidos del Git.
• Añada .gitignore al control de versiones Equipo > Añadir (Team > Add):

• Puede que tenga que establecer sus filtros del Explorador de Paquetes para poder ver .gitignore mostrado allí. Para acceder a los filtros, seleccione la flecha abajo en el borde derecho de la pestaña Explorador de Paquetes (Package Explorer) para mostrar Vista de Menú (View Menu).

• Seleccione Filtros... (Filters...) de la Vista de Menú y se le presentará el diálogo Filtros de Elementos Java (Java Element Filters). Deseleccione la entrada primera para mostrar archivos que comiencen por . (punto) tal como .gitignore.

• Pinche Equipo > Acometer (Team > Commit) en el menú contextual del proyecto.
• Introduzca un mensaje de acometida explicando su cambio, la primera línea (seguida de una línea vacía) se convertirá en la breve anotación para esta acometida. Por defecto el autor y el acometedor se toman del archivo .gitconfig en su directorio personal.
• Puede pinchar Añadir Firmado-por (Add Signed-off-by) para añadir una etiqueta Firmado-por: (Signed-off-by:).
• Si está acometiendo el cambio de otro autor puede alterar el campo de autor para dar el nombre y la dirección del autor.
• Pinche Acometer (Commit) para acometer su primer cambio.

• Note que los decoradores de los archivos acometidos han cambiado como resultado de la acometida.

Inspeccionar Historia

• Pinche Equipo > Mostrar en Historia (Team > Show in History) del menú contextual del proyecto para inspeccionar la historia de un recurso:

• Cree una nueva clase Java Hello.java e impleméntela.
• Añádala a la versión de control y acometa el cambio.
• Mejore su implementación y acometa la clase mejorada.
• La historia del recurso ahora debería mostrar 2 acometidas para esta clase.

• Pinche en el botón conmutador (Modo Comparar) Compare Mode en la Vista de Historia.
• Doble clic src/Hello.java en la lista de recursos de la Vista de Historia para abrir su último cambio acometido en la Vista de Comparar.

¡Felicidades, justo acaba de dominar su primer proyecto usando Git !

Tutorial GitHub

Crear un Repositorio Local

• Siga Comenzar para crear un nuevo repositorio local (con su contenido en vez del proyecto de demostración).

Crear Repositorio en GitHub

• Cree un nuevo repositorio en GitHub:

En la siguiente pantalla puede ver las URLs que puede usar para acceder a su recién creado repositorio:

• pinche SSH para elegir el "protocolo SSH. Puede ser usado para acceder en lectura y escritura.
• Pinche HTTP para elegir el protocolo HTTP. Puede ser usado para acceder en lectura y escritura.
• pinche en (Git de Sólo Lectura) Git Read-Only para elegir el anónimo protocolo git para clonar. Es el protocolo más eficiente que soporta git. Puesto que el protocolo git no soporta autenticación se usa normalmente para proveer de eficiente acceso público de sólo lectura los repositorios.

Configuración de Eclipse SSH

• Abra las preferencias de Eclipse Preferences y asegure que su SSH2 home está correctamente configurado (normalmente esto es ~/.ssh) y contiene sus claves SSH2:

• si no tiene aún claves SSH puede generarlas en una segunda pestaña de este diálogo Gestión de claves (Key Management). Use una buena frase de seguridad para proteger su clave privada, para más detalle véase "Trabajando con frases de seguridad de claves".
• suba su clave pública SSH a su configuración de cuenta GitHub.

Empujar flujoarriba

• Pinche Equipo > Remoto > Empujar... (Team > Remote > Push...) y copie y pegue la URL de SSH de su nuevo repositorio de GitHub.
• Si usted está detrás de un cortafuegos que no permite tráfico SSH, use en cambio la URL HTTPS de GitHub y entregue su usuario y contraseña de GitHub en vez de usar la clave SSH pública subida. Para guardar las credenciales en el almacén seguro de Eclipse o secure store pinche (Guardar en Almacén Seguro) Store in Secure Store.
• Note: muchos proxies HTTP están configurados para bloquear URLs HTTP que contengan nombre de usuario, puesto que dar un nombre de usuario por URL de HTTP se considera un riesgo de seguridad. En ese caso elimine el usuario de la URL de HTTP y provéalo solo en el campo de usuario. Se enviará como cabecera de HTTP.

• Pinche Next y en la primera conexión acepte la clave de host de GitHub.

• Introduzca su frase de seguridad SSH y pinche OK.

• En el siguiente asistente pinche (Añadir todas las especificaciones de ramas) Add all branches spec para mapear sus nombres de rama local a los mismos nombres de rama en el repositorio destino (de forma uno-a-uno).

• Pinche Next. El diálogo de confirmación de empuje mostrará una vista preliminar de los cambios que se empujarán al repositorio destino.

• Pinche (Finalizar) Finish para confirmar que quiere empujar estos cambios.

• El siguiente diálogo informa del resultado de la operación de empuje (push).

• Apunte su explorador a su repositorio GitHub para ver que su nuevo contenido de repositorio ha llegado.

Tutorial de Git EclipseCon 2012

Encuentre todos los ejercicios y diapositivas aquí.

Siga el ejercicio #1 para prepararse para el tutorial Git.

Conceptos

Git se construye en unas simples pocas y muy poderosas ideas. Conocerlas ayuda a entender más fácilmente como funciona git.

Repositorio

El Repositorio o Base de datos de objetos almacena todos los objetos que constituyen la historia del proyecto. Todos los objetos en la base de datos se identifican por medio de un hash SHA-1 seguro de 20 bytes del contenido del objeto. Esto tiene varias ventajas:

• Comparar dos objetos se reduce a comparar dos hashes SHA-1.
• puesto que los nombres de objetos se computan a partir del contenido del objeto del mismo modo en cualquier repositorio git, el mismo objeto se almacenara bajo el mismo nombre en todos los repositorios que contengan este objeto.
• un objeto nunca cambia una vez creado (obvio ya que cambiar el contenido significa que un nuevo hash debe ser calculado y un nuevo nombre asignado).
• corrupciones de repositorio puede ser fácilmente detectable comprobando si el nombre de objeto SHA-1 aún es el hash seguro del contenido del objeto.

Git tiene cuatro tipos de objetos:

• Un Objeto Blob almacena el contenido del archivo.
• Un Objeto Árbol almacena la estructura de directorio y contiene Objetos Blob y otros Objetos Árbol conjuntamente a sus nombres de sistema de ficheros y modos.
• Un Objeto Acometida representa una captura de la estructura de directorio en el momento de la acometida y tiene un enlace a su Objeto Acometida predecesor el cual forma un grafo acíclico del repositorio de revisiones que forma la historia del repositorio.
• Un Objeto Etiqueta es un enlace de nombre simbólico a otro objeto de repositorio el cual contiene el nombre y tipo del objeto. Opcionalmente, también contiene información sobre quién creó la etiqueta y otra información de firma.

La base de datos de objetos se almacena en el directorio .git/objects. Los objetos son almacenados bien como objetos sueltos o en formato empaquetado en un solo archivo para un almacenamiento y transporte más eficientes.

Confianza

Git provee una cadena de confianza embebida por medio de hashes seguros SHA-1, lo cual permite verificar si los objetos obtenidos desde una fuente (potencialmente no fiable) son correctos y no han sido modificados desde que han sido creados.

Si obtiene la etiqueta firmada para p. ej. el despliegue de un proyecto que pueda usted verificar con p. ej. la clave pública de firma (del líder del proyecto) del etiquetador, git asegura que la cadena de confianza cubre lo siguiente:

• La etiqueta firmada identifica un objeto acometida.
• El objeto acometida representa exactamente una revisión de proyecto incluyendo su contenido e historia.
• El objeto acometida contiene el árbol de objetos Blob y otros objetos árbol que representan la estructura de directorios de la revisión del proyecto.
• Los objetos Blob contienen los contenidos del archivo para esta revisión del proyecto.

Todos los nombres de los objetos participantes pueden ser comprobados para ver su consistencia usando el algoritmo SHA-1 para asegurar la corrección de la revisión del proyecto y que la historia completa es fiable.

Índice

El Índice de Git es un fichero binario almacenado en el directorio .git/index que contiene una lista ordenada de nombres de archivo, modos de archivos, y metadatos de archivo usados para detectar eficientemente modificaciones de archivos. También contiene nombres SHA-1 de objetos de objetos blob.

Tiene las siguientes propiedades importantes:

• El índice contiene toda la información necesaria para generar un sólo objeto árbol únicamente definido. P. ej. una operación de acometida genera este árbol, lo almacena en el objeto base de datos y lo asocia con la acometida.
• El índice permite la comparación rápida del árbol que define con el directorio de trabajo actual. Esto se consigue almacenando metadatos adicionales sobre los archivos envueltos en el índice de datos.
• El índice puede almacenar información eficientemente sobre los conflictos de mezclado entre árboles envueltos en la mezcla tal que para cada nombre de ruta haya suficiente información acerca de los árboles envueltos como para permitir una mezcla a tres partes.

Ramas

Una rama en Git es una referencia nombrada a una acometida. Hay dos tipos de ramas, denominadas ramas "Local" y ""Seguimiento remoto" ("Remote Tracking") las cuales sirven para distintos propósitos.

Ramas Locales

Cada vez que se acomete un cambio a un Repositorio (local), se crea un nuevo objeto acometida. Sin otros medios, sería muy difícil mantener un seguimiento de los cambios en el Repositorio, en particular cuando otras acometidas se añaden al Repositorio, por ejemplo debido a una actualización del Repositorio remoto o cuando se verifica otra acometida.

Una rama local ayuda con esta tarea proveyendo un nombre (local) por el cual se puede encontrar la acometida actual. Cuando se acometen cambios al repositorio local, la rama se actualiza automáticamente para apuntar la acometida recién creada.

Además, es posible añadir la así llamada configuración de flujoarriba (upstream) a la rama local la cual puede ser de utilidad cuando se sincroniza con un repositorio remoto.

Ramas de Seguimiento Remoto

Las ramas de seguimiento remoto se crean cuando se clona y extrae de repositorios remotos. Una rama de seguimiento remoto en el repositorio local siempre corresponde a una rama (local) en el repositorio remoto. El nombre de dicha rama sigue ciertas convenciones.

La rama de seguimiento remoto apunta a la misma acometida que la rama correspondiente en el repositorio remoto (en el momento del clonado/extracción).

Las ramas de seguimiento remoto pueden ser utilizadas para la creación automatizada de la configuración de flujoarriba (upstream) para ramas locales.

Directorio de Trabajo

El directorio de trabajo es el directorio utilizado para modificar archivos para la siguiente acometida. Por defecto está localizada un nivel por encima del directorio .git . Hacer una nueva acometida implica típicamente los siguientes pasos:

• Verificar la rama en la que se basará la nueva acometida. Esto cambia el directorio de trabajo de modo que refleja el revisión HEAD de la rama.
• Hacer modificaciones en el directorio de trabajo.
• Decir a git acerca de estas modificaciones (añadir los archivos modificados). Esto transfiere los contenidos de archivo modificado al objeto de la base de datos y prepara el árbol para ser acometido en el índice.
• Acometer el árbol preparado del índice en la base de datos de objetos..
• El resultado es un nuevo objeto de acometida y la HEAD de la rama actual se mueve a la nueva acometida.

Grabar Cambios en el Repositorio

Comience desde una extracción fresca de una rama de un repositorio local. Usted quiere hacer algunos cambios y grabar capturas de esos cambios en el repositorio cada vez que llegue a un estado que quiera registrar.

Cada archivo en el directorio de trabajo puede bien ser seguido (tracked) o no-seguido (untracked):

• Los archivos seguidos son aquellos que estuvieron en la ultima captura o los archivos que han sido nuevamente preparados (staged) en el índice . Pueden ser no-modificados (unmodified), modificados (modified), o preparados (staged).
• Los archivos no-seguidos son todos los otros archivos (los que no estuvieron en la última instantánea y no hayan aún sido añadidos al índice).

Cuando se clona por primera vez un repositorio, todos los archivos en el directorio de trabajo estarán seguidos y no-modificados puesto que han sido recientemente extraídos y usted no ha comenzado todavía a editarlos.

Según vaya editando archivos, git reconocerá que han sido modificados con respecto a la última acometida. Usted prepare (stage) los archivos modificados en el índice y luego acometa los cambios organizados. El ciclo puede luego repetirse.

Este ciclo está ilustrado aquí:

Tareas

Crear Repositorios

Consideraciones para usar en Eclipse los Repositorios Git

La historia breve

Cuando se establecen Repositorios Git con EGit, hay dos recomendaciones para la creación de Repositorios productivos (en oposición a "desarrollo"):

• No cree el repositorio dentro del entorno de trabajo de Eclipse.
  • Tenga cuidado cuando clone o cree un Repositorio.
  • Asegúrese de utilizar correctamente el Asistente de Compartición Git.
• No cree un Repositorio con Eclipse como superusuario root.
  • Asegúrese de utilizar correctamente el Asistente de Compartición Git.

El primer fallo ocurre cuando usted especifica una carpeta del directorio de trabajo durante el clonado o la creación del Repositorio.

Ambos errores sucederán cuando utilice el asistente de Compartición Git desde un proyecto que haya creado manualmente en su espacio de trabajo sin tomar ninguna precaución (el asistente ha sido arreglado en la última versión).

Abajo encontrará alguna motivación para estas recomendaciones.

La historia larga

Espacio de trabajo de Eclipse y directorio de trabajo de Repository

Los Repositorios de Git se pueden crear de distintos modos, por ejemplo clonando desde un Repositorio existente, o usando el asistente de compartición EGit.

En cualquier caso (a menos que cree un Repositorio plano o bare, pero eso no se discute aquí), el nuevo repositorio es esencialmente una carpeta en el disco duro local la cual contiene el directorio de trabajo la carpeta de metadatos. La carpeta de metadatos es una subcarpeta llamada ".git" y normalmente referida como ".git-folder". Contiene el repositorio actual (p. ej. Las acometidas o Commits, las referencias o References, los logs y demás).

La carpeta de metadatos es totalmente transparente parar el cliente Git, mientras que el directorio de trabajo se usa para exponer el contenido del repositorio extraído como archivos para las herramientas y editores.

Típicamente, si estos archivos se van a utilizar en Eclipse, deben ser importados al espacio de trabajo de Eclipse de un modo u otro. Para hacerlo, el modo más fácil sería registrar los archivos .project desde los cuales el asistente "Import Existing Projects" puede crear los proyectos fácilmente. En consecuencia en la mayoría de casos, la estructura de un repositorio que contenga proyectos de Eclipse sería muy similar a algo como esto:

Consecuencias

Lo anterior tiene las siguientes implicaciones.

• Probablemente no sea buena idea hacer de un proyecto la carpeta raíz del repositorio.

La razón es que nunca será usted capaz de añadir otro proyecto a este repositorio, ya que el archivo .project ocupará la carpeta raíz; podría aún así añadir proyectos como subcarpetas, pero este tipo de anidación de proyecto se sabe que causa muchos problemas por todas partes. Para añadir otro proyecto, debería mover el proyecto a una subcarpeta en el repositorio y añadir el segundo proyecto como otra subcarpeta antes de que acometa usted este cambio.

• Es una buena idea mantener el repositorio fuera del espacio de trabajo de Eclipse.

Hay varias razones para esto:

el nuevo repositorio considerará la estructura completa de carpeta del espacio de trabajo de eclipse como contenido (potencial). Esto puede derivar en problemas de rendimiento, por ejemplo cuando se calculen los cambios antes de acometer (los cuales escudriñarán la carpeta completa de .metadata, por ejemplo); más frecuentemente que no, el espacio de trabajo contendrá carpetas muertas (p. ej. proyectos eliminados) los cuales semánticamente no son relevantes para EGit pero no pueden ser excluidos fácilmente.

La carpeta de metadatos (.git-) sera hija del espacio de trabajo. No está claro que esto pueda causar recorridos de carpeta no deseados por Eclipse.

puede destruir su repositorio mediante la destrucción del espacio de trabajo de Eclipse.

Crear un nuevo repositorio vacío Git

Puede crear un proyecto primero y compartirlo después. El asistente Share Project soporta la creación de repositorios Git (véase Añadir un proyecto al control de versión).

También puede crear un nuevo repositorio desde la vista (véase Crear un Repositorio).

Crear un repositorio Git para múltiples Proyectos

Puede crear múltiples proyectos bajo un directorio común para todos los proyectos de una vez:

• crear los proyectos de Eclipse (p. ej. a, b, c) bajo un directorio común (p. ej. /repos/examples/)
• seleccionar todos los proyectos (a, b, c), y en el menú de contexto pinchar Equipo > Compartir Proyecto > Git (Team > Share Project > Git)
• presionar Siguiente (Next)
• seleccionar todos los proyectos (a, b, c)
• el asistente mueve automáticamente la ubicación de repositorio local a la carpeta padre /repos/examples/ puesto que se han seleccionado múltiples proyectos.
• Pinchar Crear Repositorio (Create Repository) y Finalizar (Finish)

Iniciar desde repositorios Git existentes

Para trabajar con el contenido de un repositorio git en el espacio de trabajo de Eclipse, los archivos y las carpetas contenidas deben ser importadas como proyectos. En principio esta importación puede ser hecha usando asistentes genéricos como "Nuevo Proyecto" ("New Project") o "Importar..." ("Import..."), ya que el directorio de trabajo de un repositorio Git es justo un directorio normal del sistema de archivos local. No obstante, los proyectos recién creados todavía tendrán que ser compartidos manualmente con Git. El asistente de "Importar proyectos desde Git" ("Import Projects from Git") integra la importación y compartición de proyecto y también ofrece algo extra de conveniencia.

Iniciar el asistente de importación

Para iniciar el asistente pinche en Importar > GIt > Proyectos desde Git (Import > Git > Projects from Git).

Si comenzó con un espacio de trabajo limpio, la primera página mostrará una lista vacía:

Antes de que pueda continuar, necesita añadir uno o varios repositorios Git a la lista. Si ya tiene repositorios en la lista, este paso es opcional.

Clonar o añadir repositorios

Hay dos modos de añadir repositorios Git a la lista:

1. Clone un repositorio remoto
2. Añada un repositorio existente de su sistema de archivos local

Clonar un Repositorio

La primera opción se utiliza si usted comienza con un repositorio remoto. La operación de clonado copiará el repositorio a su sistema de archivos local. Para iniciar el asistente de Clonado pinche Clone.... El asistente de Clonado se describe más detalladamente en Clonar Repositorios Remotos. A la finalización correcta de la operación de clonado, el nuevo repositorio clonado aparece en la lista automáticamente.

Añadir un Repositorio

La segunda opción es útil si ya tiene un repositorio en su sistema de archivos local, por ejemplo porque usted lo haya clonado antes, lo haya creado desde cero o copiado desde algún otro lugar. Pinche añadir Add...; y seleccione un directorio en el sistema de archivos local. Presione (Buscar) Search para desencadenar un escaneo de repositorios Git contenidos en este directorio. Si se encuentran repositorios Git, se listarán y podrá seleccionar repositorios a añadir:

Tras una exitosa finalización, la lista de repositorio debería contener algunos repositorios:

Seleccionar un Repositorio de la Lista

Puede ahora seleccionar un repositorio y pinchar Next. En la siguiente página del asistente, decidirá como importar proyectos.

Importar proyectos

Esta página ofrece un grupo con botones tipo radio que le permite seleccionar un asistente y un árbol de directorios que opcionalmente le permitan seleccionar una carpeta en el directorio de trabajo.

Asistente para importar proyectos

Importe Proyectos existentes

Si se selecciona este botón tipo radio, el asistente escaneará el sistema de archivos local mirando archivos .project y mostrará los proyectos encontrados. Ésta es la solución más cómoda y debería ser utilizada si los archivos .project están chequeados en el Repositorio.

Limitar el Alcance de Importar Proyecto

En este caso, el árbol de directorio al fondo está activo. Puede limitar la búsqueda de archivos .project seleccionando una carpeta en este árbol, de otro modo se escaneará el directorio completo del repositorio. En la próxima página, se mostrará una lista de los proyectos encontrados (si los hubo). Ésta es muy similar al asistente genérico para Importar Proyectos Existentes) o Import Existing Projects, pero tiene algunas capacidades de filtrado adicionales:

Utilizar el Asistente de Nuevo Proyecto

Cuando se selecciona esta opción, se abrirá el asistente genérico de ("Nuevo Proyecto") "New Project". Tras la finalización del asistente de nuevo proyecto "New Project", el asistente de ("Importar proyectos desde Git") "Import Projects from Git" continuará y le asistirá con la compartición de proyectos que justo usted haya creado.

En este caso, el árbol de directorio al fondo estará inactivo, pues la selección no es relevante para el asistente de ("Nuevo proyecto") "New Project".

Importar como Proyecto General

Esta opción puede ser útil cuando no haya ni archivos .project disponibles ni un asistente adecuado de nuevo proyecto "New Project". Si se elige , el asistente generará un archivo .project y apuntará a la carpeta del proyecto del directorio de trabajo del Repositorio. El resultado es un "General Project".

Por defecto, el nuevo proyecto generado apuntará al directorio de trabajo en el Repositorio. Seleccionando alguna carpeta del árbol de directorio al fondo, puede tener el proyecto generado para esa carpeta.

Pinche Next para abrir un simple diálogo para introducir un nombre y un directorio para el nuevo proyecto.

Por defecto el nombre del proyecto sugerido coincide con el del directorio.

Trabajar con Repositorios Remotos

Clonar Repositorios Remotos

Al utilizar el Asistente de Clonado de Git usted puede clonar repositorios remotos usando diferentes protocolos de transporte.

El asistente puede ser iniciado desde el asistente "Import Projects from Git" utilizando
File > Import... > Git > Projects from Git > Next > Clone URI > Next

o desde la "Vista de Repositorios Git" (descrita en Gestionar Repositorios) utilizando el botón de barra de herramientas o menú de vista Clonar un Repositorio Git.

Selección de Repositorio

En la primera página del asistente introduzca la ubicación del repositorio remoto:

• URI - La URI completa del repositorio remoto o la ruta en el sistema de archivos. Este campo se sincroniza automáticamente con los otros campos.
  Note que puede utilizar el botón de archivo local Local file... para explorar un directorio local y que el campo URI ofrece asistencia de contenido ofreciendo valores previamente utilizados
• Host - El nombre del host remoto o vacío si se clona del sistema de archivos.
• (Ruta de Repositorio) Repository Path - Ruta al repositorio remoto o del sistema de archivos.
• (Protocolo) Protocol - Uno de los protocolos descritos abajo.
• (Puerto) Port - Número de puerto.
• (Usuario) User - El nombre de usuario para la autenticación.
• (Contraseña) Password - La contraseña para la autenticación.
• (Guardar en Almacén Seguro) Store in Secure Store - Almacenar en almacén seguro, dice si la contraseña se salvará en el almacén seguro de Eclipse.

Se soportan los siguientes protocolos:

• file - Acceso al repositorio en el sistema de archivos.
• ftp - Protocolo de Transferencia de Archivos
• git - El protocolo embebido más eficiente de git (default port 9418). Este protocolo no provee autenticación. Típicamente utilizado para acceso en lectura anónimo al repositorio.
• http - Hypertext Transfer Protocol puede ser tuneleado a través de cortafuegos.
• https - Hypertext Transfer Protocol Secure puede ser tuneleado a través de cortafuegos.
• sftp - Protocolo de transferencia de archivos SSH
• ssh - Protocolo de Git sobre secure shell (SSH). Típicamente utilizado para autenticar el acceso en escritura al repositorio.

Note: que si usted está detrás de un cortafuegos puede necesitar configurar su configuración de proxy Preferencias > General > Conexiones de Red (Preferences > General > Network Connections). Muchos proxies HTTP se configuran para bloquear URLs que contengan un nombre de usuario (y/o contraseña) como p. ej. http://fred:topsecret@egit.eclipse.org/egit.git de aquí que se recomiende utilizar los campos usuario (user), contraseña (password) al fondo de la página del asistente, Las credenciales se transmitirán como cabeceras HTTP.

Selección de Rama

En la siguiente página seleccione cuáles ramas deberán clonarse del repositorio remoto:

Si no está seguro de cuáles ramas necesita, simplemente dele a ("Seleccionar todas") "Select All".

Puede filtrar las ramas por su nombre escribiéndolo utilizando el control de texto sobre la lista. Note, en cambio, que las ramas que han sido verificadas siempre se mostrarán en la lista, p. ej. no serán filtradas.

Destino Local

En la próxima página defina donde quiere almacenar el repositorio en el sistema de archivos local y defina algunas configuraciones iniciales.

• (Directorio) Directory - El directorio el cual contendrá el repositorio Git. Será creado por el asistente si aún no existe.
• (Rama inicial) Initial branch - Elija aquí cuál rama local será creada e inicialmente verificada.
• (Nombre remoto) Remote name - Defina un nombre para el repositorio remoto. Por defecto es "origin".

La ruta raíz por defecto para almacenar repositorios Git puede ser configurada en la preferencia (Equipo > Git > Carpeta de Repositorio por defecto) Team > Git > Default Repository Folder

Puede presionar (Finalizar) Finish en esta página o presionar (Siguiente) Next si está usted trabajando con Revisión de código Gerrit y quiere configurar su repositorio acordemente.

Clonar desde ubicaciones específicas

El asistente de Clonado de EGit puede ser extendido por otros plugin para que busque repositorios en backends específicos que hospeden repositorios git. Actualmente tal extensión está disponible para Github y pronto lo estará para Gerrit. Para ambas necesitarás instalar los respectivos conectores Mylyn. La extensión del conector Gerrit de Mylyn entonces también configura el repositorio remoto para el trabajo con Gerrit. Esto puede ser también hecho o cambiado luego desde la vista de repositorios Git, véase Configuración de Gerrit.

Cuando haya instalado tal extensión, el asistente de clonado abre con una página de selección donde usted puede elegir entre diferentes fuentes del repositorio a clonar:

Empujar a otros Repositorios

Empujar flujoarriba

Si está usted trabajando con una rama local la cual tiene una así llamada "Configuración Flujoarriba", el modo más conveniente para empujar radica en su configuración flujoarriba.

Típicamente las ramas locales están creadas basadas en una rama de seguimiento remoto. Puesto que la rama de seguimiento remoto está asociada con el remoto y el remoto contiene la información requerida para acceder al correspondiente repositorio remoto, es posible crear automáticamente esta configuración flujoarriba mientras se crea la rama local (véase Ramificar para más información).

Al empujar flujoarriba desde la rama local, el push no requiere más parámetros y por tanto puede sin mostrar otro diálogo ser ejecutado basado en la configuración flujoarriba.

Para empujar flujoarriba, pinche con botón derecho en un proyecto y seleccione Equipo > Empujar flujoarriba (Team > Push to upstream) o pinche con botón derecho en un Repositorio en la vista de repositorios y pinche en Empujar flujoarriba (Push to upstream). También hay una acción disponible en el Grupo de órdenes Git.

Empujar será ejecutado inmediatamente tras seleccionar la acción. Una vez finalizado, se mostrará un diálogo de confirmación mostrando información sobre los datos empujados y/o mensajes de error:

Configurar empuje flujoarriba

El empuje flujoarriba puede ser configurado utilizando el botón "Configurar..." ("Configure...") en el diálogo de confirmación (véase arriba) o pinchando con el botón derecho un proyecto y seleccionando Equipo > Remoto > Configurar empujar flujoarriba... (Team > Remote > Configure push to upstream...).

Un diálogo de configuración se mostrará para la configuración de URIs de empuje y mapeados de ramas correspondientes (RefSpecs):

El diálogo está dividido en tres secciones principales. En la parte superior, se muestra información sobre la rama actualmente verificada y la remota que está siguiendo. Normalmente se crean ramas locales basadas en una rama de seguimiento remoto la cual autoconfigura que las ramas locales sigan esta rama de seguimiento remoto.

En este ejemplo específico, hay un mensaje de aviso de que hay varias ramas que utilizan la rama remota llamada "origin". Esto significa que los cambios en la configuración de empuje afectarán a todas estas ramas, no justo a la rama mostrada en el campo Rama. Mueva su ratón sobre el aviso para mostrar estas ramas en un consejo tooltip.

el Grupo URI contiene dos controles , un campo URI y una lista de URIs de empuje. Si la lista está vacía, la URI en el campo URI será utilizada para el empuje Push, si al menos hay una entrada en la lista de URIs de empuje, se utilizarán en cambio las URIs en la lista. Cabe señalar que si la lista de URIs de empuje está vacía y se cambia la URI en este diálogo, la nueva URI también será utilizada para el arrastre o Pull, así pues hay que tener cuidado cuando se haga eso.

El grupo RefMapping permite la especificación de una o varias RefSpecs (véase Refspecs) para el empuje o Push.

("Añadir") "Add" abrirá un pequeño asistente que ayuda en la creación de las RefSpecs. Puede usted también pegar un RefSpec desde el portapapeles a la lista.

Pinchar en el control ("Avanzado") "Advanced" mostrará/esconderá un botón de edición ("Editar (Avanzado...)") "Edit (Advanced...)" que permite más ediciones complejas de RefSpec similar al Asistente de Empuje de abajo.

Los botones en la barra de botones bajera le permiten a usted salvar sus cambios y hacer el empuje inmediatamente, salvar los cambios sin extraerlos, ejecución en seco (empujar sin guardar la configuración), revertir sus cambios y cancelar.

Empuje Directo

Alternativamente, puede utilizar Soporte de Empuje Directo en una Especificación de empuje de un Remoto.

Asistente de Empuje

El modo más poderoso (pero también el más complejo) es utilizar el asistente de empuje
Equipo > Remoto > Empujar... (Team > Remote > Push...)

URI de empuje

• Si ya ha configurado la Especificación de Empuje en la vista de Repositorios usted puede también seleccionarla aquí utilizando la lista desplegable bajo Repositorios remotos configurados (Configured remote repositories). El botón Finalizar (Finish) se activará si la Especificación de Empuje para este remoto está configurada apropiadamente (p. ej. tiene al menos una URI y una ref spec.)
• De otro modo pinche URI Personalizada (Custom URI) e introduzca la URI del repositorio flujoarriba al que quiere empujar las cosas.

Empujar Especificaciones de Ref

Véase también Refspecs para más explicaciones.

Pinche (Siguiente) Next
Si ésta es la primera vez que conecta usted a este repositorio vía ssh tendrá que aceptar la clave de host del repositorio remoto

Si su clave de ssh está protegida por una frase de seguridad (lo cual es recomendable) tiene que introducirla aquí

Pinche (Añadir espec. de todas las ramas) Add all branches spec

Éste es un modo conveniente de declarar que quiere mapear los nombres de sus ramas locales a los mismos nombres de las ramas en el repositorio flujoarriba al que quiere empujar sus cambios.

Pinche (Añadir especs de todos las etiquetas) Add all tags spec para mapear etiquetas locales 1:1 a las etiquetas en el repositorio al que quiere empujar cosas.

Si quiere mapear ramas locales a aquellas en el repositorio flujoarriba de un modo diferente usted puede definir unas especificaciones de mapeo más detalladas de éste modo

• introduzca la ref de fuente y destino o seleccione las ramas ya existentes de la lista desplegable
• pinche ('Añadir Espec) Add Spec

Ésto transferirá el mapeo recién creado a la lista (Especificaciones para el empuje) Specifications for push

(Otras espec comunes de empuje) Other common push specs:

• Usted puede p. ej. mapear refs/heads/* a refs/heads/joe/* si quiere nombrar las ramas a las que empuja de acuerdo con su apodo joe. Esto es útil si múltiples usuarios quieren publicar sus ramas locales en ramas personales en un repositorio público conjuntamente usado.
• Otro mapeo habitual es mapear la ref. fuente HEAD a la de destino refs/heads/master. Esto significa que usted quiere mapear su actual HEAD (la cual puede actualmente apuntar p. ej. a cualquier rama de tópico) a la rama maestra de flujoarriba.

Eliminar Especificaciones de Ref

Para eliminar una ref. en un repositorio de destino seleccione la ref. a ser borrada desde la lista desplegable (Ref. remota a borrar) Remote ref to delete y pinche (Añadir Espec.) Add Spec. Esto creará la entrada correspondiente en la lista de (Especificaciones para empujar) Specifications for push . Alternativamente puede escribir la especificación para que las ref sean eliminadas, se puede utilizar comodines. Empujar Eliminar Especificaciones de Ref eliminara las Ref coincidentes en el repositorio de destino.

Especificaciones de Ref de Empuje Conflictivas

Si añade múltiples Especificaciones de Ref de Empuje conflictivas quedarán marcadas en rojo, solucione esto eliminando o editando las especificaciones conflictivas. También es posible editar las especificaciones in-situ en la lista Specifications for push

Confirmación de Empuje

Pinche Next

Esto abrirá el diálogo de Confirmación de Empuje mostrando una vista preliminar de que cambios se empujarán al repositorio destino. Si ésto no cumple sus expectativas pinche (Atras) Back y corrija acordemente sus especificaciones de empuje.

• Para actualizaciones de ref se mostrará el rango de acometidas a ser empujadas en el formato <SHA1-from>..<SHA1-to> p. ej. d97f5a2e..adfdbfd2 significa todas las acometidas entre d97f5a2e y adfdbfd2 serán empujadas.
• Para refs que aún no existen en el repositorio de destino se muestra nueva rama[new branch] o nueva etiqueta [new tag].
• Para las refs que serán borradas se muestra [deleted].

• Seleccione el casillero de (Empujar sólo si las refs remotas no cambian entretanto) Push only if remote refs don't change in the mean time si quiere asegurarse de que lo que ve en esta vista previa es también lo que obtiene cuando empuje los cambios.
• Seleccione el casillero (Mostrar el diálogo de informe final cuando difiera de este informe de confirmación) Show final report dialog only when it differs from this confirmation report si sólo quiere obtener un informe tras ejecutar el empuje si el resultado difiere de esta vista preliminar.

Informe de Resultado de Empuje

Pinche (Finalizar) Finish

Dependiendo de las opciones que haya elegido se mostrará un diálogo de informe de resultado. Mostrará la lista de acometidas que se empujaron al remoto.

Se mostrará en la caja al fondo del mensaje la confirmación de empuje del servidor . En caso de errores encontrará el mensaje de error del servidor remoto aquí. Para ver el mensaje dada una lista, simplemente selecciónelo de la misma.

Pinche Ok para cerrar el diálogo.

Extraer desde otros Repositorios

Extraer desde flujoarriba

Si está usted trabajando con una rama local la cual tiene una así llamada "Configuración Flujoarriba", el modo más conveniente para extraer radica en su configuración flujoarriba.

Una rama local típicamente se crea basándose en una rama de seguimiento remoto. Puesto que la rama de seguimiento remoto está asociada con el remoto y el remoto contiene la información requerida para acceder al repositorio remoto, es posible crear automáticamente ésta configuración flujoarriba mientras se crea la rama local (véase Ramificar para más información).

Cuando se extrae de flujoarriba, esta configuración persistida puede ser utilizada para extraer automáticamente sin la necesidad de proveer más parámetros en un diálogo.

Para extraer de flujoarriba, pinche Equipo >Extraer de flujoarriba (Team > Fetch from upstream) en un proyecto o pinche Extraer de flujoarriba (Fetch from upstream) en un Repositorio en la Vista de repositorios. También hay una acción disponible en el Grupo de órdenes Git.

Extraer será ejecutado inmediatamente tras seleccionar la acción. Una vez finalizado, se mostrará un diálogo de confirmación mostrando información sobre los datos extraídos y/o mensajes de error:

Configurar extracción desde flujoarriba

La extracción desde flujoarriba puede ser configurada utilizando el botón "Configure..." en el diálogo de confirmación (véase arriba) o pinchando Equipo > Remoto > Configurar extracción desde flujoarriba... (Team > Remote > Configure fetch from upstream...) en un proyecto.

Se mostrará un diálogo de configuración para configurar la URI de extracción y mapeos de rama (RefSpecs):

El diálogo está dividido en tres secciones principales. En la parte superior, se muestra información sobre la rama actualmente verificada y la remota que está siguiendo.

El campo URI puede ser utilizado para añadir/cambiar la URI de extracción.

El grupo RefMapping permite la especificación de una o varias RefSpecs (véase Refspecs) para la extracción.

El botón "Add" abrirá un pequeño asistente que ayuda en la creación de las RefSpecs. Puede usted también pegar un RefSpec desde el portapapeles a la lista.

Pinchar en el control "Advanced" mostrará/esconderá un botón de edición "Edit (Advanced...)" que permite más ediciones complejas de RefSpec similar al Asistente de extracción.

Los botones en la barra de botones bajera le permiten a usted salvar sus cambios y hacer la extracción inmediatamente, salvar los cambios sin extraerlos, ejecución en seco (extraer sin guardar la configuración), revertir sus cambios y cancelar.

Extracción Directa

Otro modo para extraer es utilizar Soporte de Extracción Directa en una Especificación de Extracción de un Remoto.

Asistente de Extracción

El modo más potente (pero también el más complejo) es utilizar el Asistente de Extracción
Team > Fetch...

• Si ya ha configurado la Especificación de Extracción en la vista de Repositorios usted puede también seleccionarla aquí utilizando la lista desplegable bajo (Repositorios remotos configurados) Configured remote repositories. El botón (Finalizar) Finish se activará si la Especificación de Extracción para este remoto está configurada apropiadamente (p. ej. tiene al menos una URI y una ref spec.)

• De otro modo pinche (URI Personalizada) Custom URI e introduzca la URI del repositorio flujoarriba del que quiere extraer las cosas.

Extraer Especificaciones de Ref

Véase también Refspecs para más explicaciones.

Pinche Next
Pinche Add all branches spec

Éste es un modo conveniente de declarar que usted quiere mapear los nombres de ramas en el repositorio flujoarriba del que quiere extraer cambios 1:1 a los mismos nombres de ramas locales.

• Pinche en el campo de edición (Ref de Destino) Destination Ref y reemplace el segmento de ruta choose_remote_name con un nombre simbólico para el repositorio flujoarriba desde el que usted vaya a extraer.
• El nombre remoto por defecto para el repositorio desde el cual su repositorio ha sido clonado es origin. La maestra de este remoto se mapea por defecto desde refs/heads/master a refs/remotes/origin/master.
• Si usted p. ej. quiere adicionalmente seguir ramas del repositorio de Joe en su repositorio local usted mapearía la rama en su repositorio refs/heads/* a las siguientes ramas de seguimiento refs/remotes/joe/*.
• Deseleccione (Forzar actualización) Force Update si quiere permitir sólo actualizaciones de (avance rápido) fast-forward, seleccione esta opción si quiere también permitir cambios (sin avance rápido) non-fast-forward.
• Pinche (Forzar Actualización de todas las refs) Force Update all Refs para establecer la opción de forzar actualización en todas las specs
• Pinche (Eliminar todas las especificaciones) Remove all specs para eliminar todas las especificaciones de la lista (Especificaciones para traer) Specifications for fetch

• Pinche añadir todas las spec de etiquetas (Añadir todas las especificaciones de etiquetas) Add all tags spec para mapear etiquetas en el repositorio del que quieres extraer 1:1 a las etiquetas locales.

Si quiere mapear ramas o etiquetas en el repositorio flujoarriba a las ramas locales de un modo diferente usted puede definir unas especificaciones de mapeo más detalladas de este modo

• introduzca la ref fuente (ref en repositorio fuente) y destino (rama de seguimiento o etiqueta en repositorio local) o seleccione las ramas ya existentes desde las listas desplegables
• Pinche (Añadir Espec.) Add Spec

Esto transferirá el mapeo recién creado a la lista especificaciones para la extracción (Especificaciones para extraer) Specifications for fetch

Informe de resultado de Extracción

Pinche (Finalizar) Finish

Se muestra un diálogo de resultado de extracción.

• Para las actualizaciones de ref se mostrará la lista de acometidas que han sido extraídas.
• Para refs los cuales no existieran antes en el repositorio local se muestra rama nueva [new branch] o nueva etiqueta [new tag].
• Para refs las cuales hayan sido eliminadas se muestra [deleted].

Arrastrar Nuevos Cambios desde la Rama Flujoarriba

• Pinche botón derecho en un proyecto del Explorador de Paquete y seleccione Equipo > Arrastrar (Team > Pull) o pinche botón derecho en un repositorio en la vista de Repositorios Git y seleccione Arrastrar (Pull) para arrastrar nuevos cambios desde la rama flujoarriba que su rama local está siguiendo. Esto también funciona si los recursos se seleccionan desde más de un repositorio.
• Cuando quiera que usted cree una rama local basada en una rama de seguimiento remoto EGit puede configurar una relación de seguimiento tal que los arrastres subsiguientes extraerán y luego mezclarán o refundarán (dependiendo de la configuración de esta relación de seguimiento) los cambios desde la rama seguida flujoarriba; véase Ramificar para más detalles.

Egit no soporta aún selección Ad-hoc de la rama flujoarriba de la que arrastrar.

Las alternativas disponibles incluyen:

• ejecutar Arrastre git (git pull) desde fuera de eclipse (pero cuidado en Windows)
• si no hizo usted ningún cambio local o quiere descartar sus cambios locales, utilice Equipo > Resetear... (Team > Reset...)

Trabajar con Gerrit

Si está usted trabajando con Gerrit (http://code.google.com/p/gerrit/), EGit le permite empujar y arrastrar cambios convenientemente a y desde los servidores Gerrit.

Activar Gerrit para un repositorio

La operación Gerrit no aparecerá en ningún menú a menos que configure su repositorio primero. Para hacer eso abra la vista de repositorios de Git explore hasta el Remote que representa el servidor de repositorio Git que quiere utilizar.

Empujar un cambio a un servidor de revisión de código Gerrit

Pinche botón derecho en un proyecto y seleccione Equipo > Remoto > Empujar a Gerrit... (Team > Remote > Push to Gerrit...) o haga clic con botón derecho en un nodo de Repositorio en la Vista de Repositorios y seleccione Empujar a Gerrit... (Push to Gerrit...)

Aparecerá un diálogo que le permita seleccionar o introducir una URI y nombre de rama:

• En el combo de URI, seleccione o introduzca la URI que apunte a su instancia de Gerrit; el combo será prerellenado con todas las URI's definidas en cualquier remoto de su Repositorio actual; además puede escribir cualquier URI en este campo
• En el campo de rama de Gerrit, introduzca el nombre de la rama para seleccionar la cola de revisión a la que se empujaran sus cambios

El diálogo también ofrece un asistente de contenido para la rama Gerrit. Simplemente presione "Ctrl+Espacio" para activar esto (consulte el consejo que aparece al sobrevolar la pequeña bombilla decorativa cerca del campo de rama de Gerrit). Se mostrarán las ramas remotas de seguimiento para el repositorio actual. Note que este asistente de contenido está filtrado, así que para ver todas las proposiciones, necesitará asegurarse de tener el campo de la Rama Gerrit vacío antes de pedir el asistente de contenido.

Al pinchar (Finalizar) Finish, la acometida actualmente verificada será empujada a la rama Gerrit especificada. También, los valores de URI y rama Gerrit se recordarán y sugerirán de nuevo cuando se abra luego el diálogo otra vez.

Esto permite más flexibilidad cuando se trabaja con diferentes ramas Gerrit en paralelo (p. ej. cambiando frecuentemente entre desarrollo y arreglo en caliente).

Extraer un cambio del Servidor de Revisión de Código Gerrit

Pinche botón derecho en un proyecto y seleccione Equipo > Remoto > Extraer desde Gerrit... (Team > Remote > Fetch from Gerrit...) o haga clic con botón derecho en un nodo de Repositorio en la vista de Repositorios y seleccione Extraer desde Gerrit (Fetch from Gerrit...)

Aparecerá un diálogo que le permita a usted seleccionar o introducir una URI y un cambio así como algunas opciones adicionales:

• En el combo de URI, seleccione o introduzca la URI que apunta a su instancia Gerrit; el combo será prerellenado con todas las URIs definidas en cualquier remoto de su Repositorio actual; además puede escribir cualquier URI dentro de este campo
• En el campo Cambio, debe introducir el nombre completo del cambio; puede usted tomar este valor desde la Interfaz de usuario Web de Gerrit, utilice el asistente de contenido abajo descrito, o construya el nombre utilizando el siguiente patrón:
  "refs/changes/" + (últimos dos dígitos del numero de cambio) + / + (numero de cambio) + / + (numero de revisión)
• En las acciones a ejecutar tras la extracción o "Actions to perform after fetch" puede decidir que hacer tras haber extraído el cambio; puede bien crear y verificar una rama apuntando al cambio, crear y verificar una etiqueta apuntando al cambio, o simplemente verificar el cambio (por lo tanto haciendo una HEAD desenlazada); la ultima opción no hace nada tras extraer, pero usted será capaz de encontrar la acometida perteneciente al cambio en FETCH_HEAD (vaya a vista de Repositorios encuentre FETCH_HEAD bajo el nodo de referencias de su repositorio, véase Inspeccionando Referencias ).
  El nombre para la rama o la etiqueta es sugerido por el diálogo pero puede ser sobrescrito si es necesario.
  Puesto que el borrado de etiquetas no está actualmente soportado en EGit, nosotros le sugerimos que utilice ramas locales en vez de etiquetas por el momento. Ya que la vista de Repositorios permite agrupar ramas jerárquicamente utilizando "/" como separador jerárquico, los nombres sugeridos pueden resultar muy útiles cuando se trata con numerosos cambios.

En vez de los tediosos copia-pega o introducciones manuales del cambio de ID, el diálogo ofrece también un asistente de contenido para el cambio. Simplemente presione "Ctrl+Espacio" para activar esto (consulte el consejo que aparece al sobrevolar la pequeña bombilla decorativa cerca del campo de Cambio). El servidor Gerrit será contactado y todos los cambios disponibles serán extraídos y mostrados en un diálogo asistente de contenido:

La lista será filtrada con su entrada del campo de cambio. Tras seleccionar el cambio en el asistente de contenido, el campo de Cambio, será rellenado con la información correcta.

Puede también copiar el comando de descargar desde la interfaz de usuario Web de Gerrit al portapapeles antes de abrir el asistente Fetch from Gerrit.... Esto poblará automáticamente el diálogo con los valores necesarios para extraer este cambio.

Inspeccionar el estado del Repositorio

Decoración de Rótulos

Decoración de rótulos muestra información específica de Git en recursos bajo el control de versiones Git. Aparecen en todas las vistas que muestran objetos de modelo, como Explorador de Paquetes, Explorador de Proyectos, Explorador, Vista de Jerarquía.

Las decoraciones de rótulo de Git pueden ser encendidas globalmente en el menú de preferencias (Window > Preferences) bajo General > Appearance > Label Decorations.

Se pueden hacer más ajustes detallados en Preferencias bajo Team > Git > Label Decorations.

Hay dos tipos diferentes de decoraciones de rótulos: decoración de texto y decoración de icono.

Decoración de Texto

Las decoraciones de texto aparecen en la izquierda o derecha del rótulo de texto. Pueden ser configuradas en el diálogo de Preferencias bajo Team > Git > Label Decorations en la pestaña de Text Decorations. Por ejemplo, el valor por defecto para un recurso sucio es un > en la parte izquierda de su nombre.

Éstos son los valores por defecto:

Para archivos y carpetas existen las variables nombre ("name"), sucio ("dirty") y preparado ("staged"). "Sucio" y "preparado" son marcadores o flags; si están a cierto, se muestra el texto tras los dos puntos.

Para proyectos hay variables adicionales repositorio ("repository") y rama ("branch"). La variable </tt>repositorio</tt> muestra el nombre del repositorio.

La variable "rama" muestra el nombre de la rama actualmente verificada. Si no hay rama verificada, la decoración muestra el nombre abreviado de la acometida (los primeros siete caracteres seguidos de puntos suspensivos). Si las etiquetas o las ramas remotas están apuntando a esta acometida, se aplica un heurístico de "mejor estimación" para mostrar también ésta información: las etiquetas tienen preferencia sobre las ramas remotas, si varias etiquetas son válidas, se muestra la más nueva; si hay varias ramas remotas o etiquetas que no tienen fecha de modificación, se aplica orden alfabético y se muestra la última. Ejemplo: la acometida verificada e49f576... se refiere a la etiqueta v.0.7.1 del repositorio egit:

Decoraciones de Icono

Las decoraciones de icono aparecen en la esquina inferior derecha del icono mostrado por delante del rótulo. Pueden ser configuradas en el diálogo de Preferencias bajo (Equipo > Git Decoración de Rótulos) Team > Git > Label Decorations en la pestaña de (Decoración de iconos) Icon Decorations.

Éstos son las decoraciones por defecto:

• (Carpeta sucia) dirty (folder) - Al menos uno de los archivos bajo esta carpeta está sucio; esto significa que hay cambios en el árbol de trabajo que no se hayan ni en el índice ni en el repositorio.
• (Seguido) tracked - El recurso es conocido por el repositorio Git y por lo tanto bajo el sistema de control de versiones.
• (Sin seguimiento) untracked - El recurso no es conocido por el repositorio Git y no estará controlada por el sistema de versiones hasta que se añada explícitamente.
• (Ignorado) ignored - El recurso es ignorado por el proveedor de equipo Git. Los ajustes de preferencias bajo Equipo > Recursos Ignorados (Team > Ignored Resources), se tienen en cuenta los marcadores o flags "derivados" y los ajustes de archivos .gitignore.
• sucio (dirty) - El recurso tiene cambios en el árbol de trabajo que ni están en el índice ni en el repositorio.
• preparado (staged) - El recurso tiene cambios que han sido añadidos al índice. Note que añadir cambios al índice es actualmente posible sólo en el diálogo de acometida vía menú de contexto de un recurso.
• parcialmente preparado (partially-staged) - El recurso tiene cambios los cuales están añadidos al índice y cambios adicionales en el árbol de trabajo que ni han alcanzado el índice ni han sido acometidos al repositorio. Véase preparación parcial desde la vista de Preparación Git para saber cómo hacer eso.
• añadido (added) - El recurso aún no ha alcanzado ninguna acometida en el repositorio pero ha sido recién añadido al repositorio para que sea seguido en un futuro.
• eliminado (removed) - El recurso está preparado para su eliminación del repositorio Git.
• conflicto (conflict) - Existe un conflicto de mezclado para ese archivo.
• asumir-válido (assume-valid) - El recurso tiene el marcador asumir como no cambiado o "assume unchanged" flag. Esto significa que el Git para de comprobar el árbol de trabajo buscando modificaciones, así que necesitas desmarcar manualmente el bit para contarle a Git cuándo cambia el árbol de trabajo. Véase también Asumir acción no cambiada.

Diálogo de Acometidas

En el diálogo de acometidas se muestra un sumario de los estados de todos los archivos seguidos. Haciendo doble clic en un archivo los cambios a ser acometidos se mostrarán en el diálogo de comparación. Ya que EGit actualmente siempre acomete el contenido del árbol de trabajo (correspondiente a git commit -a en la línea de comandos) el diálogo de comparación comparará el árbol de trabajo con la última acometida.

Comparar Contenido

en el trabajo diario normalmente usted querrá ver los cambios entre su última acometida, el índice, y el actual árbol de trabajo. Para ello, seleccione un Recurso(proyecto, carpeta, o archivo) en el explorador o navegador de proyecto y pinche una acción con el botón derecho bajo (Comparar Con) Compare With.

Para analizar los contenidos de una acometida específica debería usar la Vista de Historia la cual soporta esta tarea mucho mejor, véase tarea Inspeccionar Acometidas.

Editor de Comparación y Vista de Sincronización

Si utilizas cualquiera de las acciones del submenú Comparar con (Compare With) en un único archivo, se mostrará un editor de comparación, de otro modo (desde EGit 3.1) se abrirá la Vista de Sincronización que le permitirá explorar los cambios; dando doble clic en un archivo cambiado en esta vista, se abrirá un editor de comparación para este archivo. En la barra de herramientas en la Vista de Sincronización puede seleccionar el Modelo de Sincronización que quiera usar para presentar los cambios que esté inspeccionando.

Comparar el árbol de trabajo con la última acometida

La diferencia entre un recurso en el directorio de trabajo actual y en la última acometida en la rama actual puede ser vista desde el menú de contexto Comparar Con > revisión de HEAD (Compare With > HEAD revision). Esta característica está también disponible en el Diálogo de Acometida. Pinchando doblemente en una entrada del Diálogo de Acometida abre un Diálogo de Comparación .

Comparar Árboles de Trabajo con Índice

Las diferencias entre el árbol de trabajo y el índice (basadas en el recurso seleccionado actualmente) pueden verse desde el menú de contexto Comparar con > Indice Git (Compare With > Git Index).

Comparar Árbol de Trabajo con una Rama, una Etiqueta o una Referencia

• Seleccione un recurso
• pinche botón derecho en Comparar con > Rama, Etiqueta o Referencia... (Compare With > Branch, Tag, or Reference...)
• seleccione una rama, etiqueta o referencia

Comparar Árbol de Trabajo con Cualquier Acometida

Desde el explorador de proyecto:

• Seleccione un recurso
• pinche botón derecho en Comparar con > Acometida... (Compare With > Commit...)
• seleccione una acometida desde el grafo de acometidas

Desde la vista de historia (sólo archivos):

• Selecciona un archivo en el explorador de paquetes
• pinche botón derecho en Equipo > Mostrar en Historia (Team > Show in History) o Comparar con > Historia... (Compare With > History...)
• en el grafo de acometidas seleccione una
• desde el menú de contexto seleccione Comparar con árbol de trabajo (Compare with working tree)
• esto abrirá un diálogo de comparación mostrando los cambios entre la acometida seleccionada y el árbol de trabajo actual

Comparar Dos Acometidas

• Seleccione un recurso en el explorador de Paquetes
• pinche Equipo > Mostrar en Historia (Team > Show in History) o Comparar con > Historia... (Compare With > History...) (este último sólo para archivos)
• en el grafo de acometidas seleccione dos de ellas
• pinche botón derecho en Compara entre sí (Compare with each other)
• esto abrirá un diálogo de comparación mostrando los cambios entre las dos acometidas seleccionadas
• puede también abrir una vista de Comparación de Árbol Git pulsando botón derecho en Comparar entre sí en Árbol (Compare with each other in Tree)

Comparar Índice con HEAD o Cualquier Otra Acometida

Puede comparar el Índice con HEAD utilizando la vista de preparación o Staging View. Haga doble clic en un archivo mostrado en el panel de ("Cambios Preparados") "Staged Changes" para comparar la versión del índice contra la versión de HEAD. La Comparación entre índice y otra acometida aún no está implementada.

Comparar con ramas (Sincronizar)

La diferencia entre el árbol de trabajo (incluyendo cambios no acometidos) y una rama o etiqueta puede verse (desde EGit 3.1) seleccionando el o los proyectos que quiera comparar y pinchando en Comparar con > Rama, Etiqueta o Referencia... (Compare With > Branch, Tag or Reference). El resultado se filtra por recursos que haya seleccionado antes de comenzar la comparación.

Puede también comparar con una rama pinchando en el menú dinámico Equipo > Sincronizar (Team > Synchronize) en un proyecto y seleccionando la Ref. contra la que usted quiere sincronizar su árbol de trabajo. Si el repositorio Git contiene múltiples proyectos de Eclipse es suficiente con seleccionar uno, la Vista de Sincronización (Synchronization View) incluirá todos los otros proyectos.

Si quiere sincronizarse con una Ref no listada en el menú dinámico pinche Equipo > Sincronizar > Otro... (Team > Synchronize > Other...). Entonces en el asistente de Sincronización pinche en la columna de destino del repositorio que quiere sincronizar y seleccione la Ref contra la que quiere comparar.

Cuando pinche "Incluir cambios locales no acometidos en la comparación" ("Include local uncommitted changes in comparison") también se mostrarán en la comparación los cambios locales no preparados y los preparados.

También es posible comparar múltiples repositorios al tiempo. En este caso en el Asistente de Sincronización seleccione por cada repositorio la Ref contra la que quiere comparar.

Quickdiff

En vez de utilizar este editor de comparar puedes activar el soporte de quick diff y ver los cambio en el editor de texto.
Esta característica puede ser activada vía página de preferencias General > Editores > Editores de texto > Quick Diff (General > Editors > Text Editors > Quick Diff):

La anotación de la diferencia se mostrará a mano izquierda en el editor:

Si mueve su ratón sobre la anotación verá el contenido de la versión contra la que usted compara:

Por defecto, la comparación es contra la HEAD. Puede determinar la versión contra la que compara, la así denominada (línea base de quickdiff) quickdiff baseline, desde el menú de contexto de una acometida en la vista de historia Mostrar en > Historia (Show in > History). Hay tres entradas de menú:

• Quick Diff -> Resetea la línea base al primer padre de la HEAD (Quick Diff -> Reset baseline to first parent of HEAD) - Compara contra la primera acometida antes de la HEAD.
• Quick Diff -> Resetea la línea base contra la HEAD (Quick Diff -> Reset baseline to HEAD) - Compara contra la HEAD.
• Quick Diff -> Establece como línea base (Quick Diff -> Set as baseline) - Compara contra la acometida seleccionada.

Inspeccionar Acometidas

Para inspeccionar una acometida dada

• desde el menú de contexto en el explorador de paquetes seleccione Equipo > Mostrar en Historial (Team > Show in History)
• seleccione la acometida que quiere inspeccionar

Ver las diferencias Diff para una acometida

La vista de historia muestra la diferencia en el panel inferior izquierdo. Seleccionar un archivo en el panel inferior izquierdo muestra las diferencias para este archivo.

Mostrar los contenidos de una Acometida

El comportamiento de un doble clic en un archivo en el panel inferior izquierdo depende del estado del botón conmutador modo de comparación. Si está encendido, se abrirá un editor de comparar el cual compara el contenido del archivo en la acometida actual con el contenido en la acometida padre; si está apagado, se abrirá un editor mostrando el contenido del archivo en la acometida actual.

Acometer Cambios

Las modificaciones a un proyecto bajo control de versiones git se persisten en la historia de git mediante acometidas. Modifique su proyecto empezando desde el estado de verificado del repositorio git hasta que haya usted alcanzado un estado que le satisfaga y acometa todos estos cambios en el repositorio como una acometida única. Cada acometida representa una instantánea bien definida de todos los archivos almacenados en el repositorio.

Modificar el contenido

Para modificar un proyecto que ya ha sido compartido con Git modifique o elimine archivos bien en Eclipse o directamente en el sistema de archivos. No hay necesidad de contarle de antemano a Git estas operaciones. Los nuevos archivos que deban ser controlados por versiones tienen que ser puestos explícitamente bajo el control de versiones Git:

• pinche Equipo > Añadir (Team >; Add) en el menú de contexto del archivo

Alternativamente usted puede visualizar archivos no seguidos en el diálogo de acometida y marcar la casilla de Mostrar archivos no seguidos (Show untracked Files) para seleccionarlas para que se incluyan en la acometida.

Los rótulos decoradores, p. ej. en la vista de Explorador de Paquetes, muestran:

• archivos no seguidos que aún no están bajo el control de versiones git (marcados con "?")
• archivos que han sido añadidos (marcados con "+")
• archivos modificados (marcados con ">" delante de su nombre)

Para más detalles véase Decoraciones de Rótulos.

Aquí hay un ejemplo en el Explorador de Paquetes para:

• un archivo acometido
• un archivo modificado en el árbol de trabajo pero aún no preparado para la siguiente acometida
• un archivo modificado cuyas modificaciones han sido preparadas para la siguiente acometida
• un archivo que ha sido recientemente preparado para una primera inclusión con la siguiente acometida
• un archivo que no está en el control de versiones Git

Acometer

Acometer con la Vista de Preparación o Staging View

El método preferido para crear acometidas con EGit es la Vista de Preparación o Staging View puesto que siempre muestra el estado actual de Git para el repositorio seleccionado y permite preparar (añadir al índice de git) y despreparar (eliminar del índice de git) archivos modificados. Haga doble clic en un archivo en el panel (Cambios no preparados) Unstaged Changes para compararlo contra el índice de git, doble clic en el panel de (Cambios preparados) Staged Changes para comparar su versión del índice contra la HEAD. En la vista de preparación puede editar el mensaje de acometida incrementalmente puesto que es una vista y no un editor modal.

Acometer utilizando el Diálogo de Acometida

Para acometer un cambio pinche Equipo > Acometer... (Team > Commit...) en el menú de contexto de un recurso del proyecto.

Git sigue todos los cambios efectuados al repositorio entero capturando las modificaciones de todos los archivos controlados por versión en ese repositorio sin importar si estos archivos residen en el mismo proyecto Eclipse o no.

Una vez que haya desencadenado la acometida aparecerá el Diálogo de Acometida (Commit Dialog)

Seleccione los cambios que quiere acometer, introduzca el mensaje de acometida y para crear la acometida pulse Ctrl+Enter (Command+Enter en Mac OS X) en el campo de texto del mensaje de acometida, o pinche Acometer.

Mensaje de Acometida

En la Vista de Preparación o en el Diálogo de acometida especifique el mensaje de acometida que describe el cambio.

Es una buena práctica comenzar el mensaje con una primera frase resumiendo el cambio seguida de una en blando y luego el cuerpo del mensaje. Para asegurar que también las herramientas de línea de comandos puedan dar formato a estos mensajes correctamente las frases no deberían ser formateadas demasiado anchas (Esto se indica por una línea vertical gris).

El texto del mensaje de acometida se comprueba por si hubiera faltas por el corrector ortográfico de Eclipse. El corrector ortográfico puede ser configurado vía Eclipse Preferenciaas > General > Editores > Editores de texto > ortografía (Preferences > General > Editors > Text Editors > Spelling). Presione Ctrl+1 para abrir arreglos rápidos o quick fixes que puedan ayudarte con la corrección ortográfica.

El editor de mensajes de acometida soporta asistente de contenido para los nombres de archivos mostrados en la sección Archivos o Files del diálogo de acometida, el cual se puede activar presionando Ctrl+Space.

(Etiquetas a pie de página) Footer Tags
En el último párrafo del mensaje de acometida (p. ej. tras la última línea en blanco), pueden ponerse etiquetas a pie de página opcionales:

Bug: 3176
Change-Id: I267b97ecccb5251cec54cec90207e075ab50503e
Reported-by: Joe Developer <joe@dev.org>
Signed-off-by: William Shakespeare <will.from@the.past>

La semántica de estas etiquetas son específicas del proyecto o de la herramienta

• Si hay una entrada en un sistema de seguimiento de errores para el cambio a acometer es una buena idea añadirla aquí como una etiqueta de bug
• Gerrit Code Review utiliza el pie Change-Id: para correlacionar diferentes conjuntos de parcheo o patchsets de un cambio que evoluciona durante el proceso de revisión hacia el parche finalmente aceptado. Para generar un Gerrit Change-Id pinche Compute Change-Id for Gerrit Code Review; el ID se generará durante la acometida, hasta entonces se mostrará un Change-Id nulo como contenedor. Con el parámetro de configuración gerrit.createchangeid de EGit establecido a cierto siempre se preseleccionará en el diálogo de acometida la correspondiente casilla. Este parámetro puede ser establecido a nivel de repositorio o a nivel de usuario. Véase Configuración de Repositorio para más información.
• El pie firmado por: o Signed-off-by: se utiliza en muchos proyectos para crear un informe de seguimiento formal de declaraciones de que el autor firmante contribuyó a los cambios bajo la licencia del proyecto y las reglas de PI propiedad intelectual. De este modo la procedencia de la PI del código base de un proyecto puede ser capturado a nivel técnico. Véase p. ej. el Developer Certificate Of Origin utilizado por el proyecto de núcleo de Linux. Si la preferencia de EGit (Insertar firmado-por) Insert Signed-off-by en (Equipo > Git > Diálogo de Acometida) Team > Git > Commit Dialog está puesta la correspondiente casilla en el Diálogo de Acometida siempre se preselecciona.

(Seleccionar cambios para acometer) Selecting changes to commit

• Cuando pinche en (Acometer) Commit en la (Vista de Preparación) Staging View sólo los cambios preparados serán acometidos. La línea de comandos nativos de git funciona del mismo modo. Todos los cambios no preparados permanecerán inalterados y quedarán en su directorio de trabajo. Esta característica se utiliza normalmente para separar modificaciones hechas a un conjunto de archivos en diferentes acometidas.
• Cuando pinche (Acometer) Commit en el (Diálogo de Acometida) Commit Dialog, puede utilizar la casilla frente a cada archivo para decidir si quiere incluir sus cambios en la nueva acometida. Si vacía la casilla frente a un archivo, los cambios de este archivo no se incluirán en la acometida. El fichero local de su espacio de trabajo de eclipse todavía contendrá las modificaciones dándole a usted la oportunidad de acometer estos cambios con otra acometida subsiguiente.

Un ejemplo: Imagine que desde su última acometida ha arreglado un error en A.java y ha añadido un nuevo método a B.java. Estas dos modificaciones son lógicamente independientes una de otra por lo que usted puede querer acometerlas en dos acometidas independientes. En este caso usted inicie la acometida, deseleccione B.java desde el conjunto de archivos acometidos y especifique un mensaje de acometida que describa sólo el arreglo del fallo en A.java. Tras una primera acometida exitosa usted justo llame de nuevo a acometer y en el siguiente diálogo le presentará los cambios restantes en B.java. Ahora especifique un mensaje de acometida describiendo la incorporación del método y finalice la segunda acometida.

En el Dialogo de Acometida los nuevos archivos que añada al proyecto que no hayan sido explícitamente añadidos al control de versiones (véase modificar el contenido o "Modifying the content") serán listados en el diálogo de acometida si selecciona la casilla ("Mostrar archivos no seguidos") "Show untracked Files". Si selecciona la casilla frente a estos archivos en la lista serán añadidos al repositorio y acometidos una vez que presione el botón de acometer. Los archivos que se excluyan por in archivo .gitignore no se mostrarán aquí. Si no tiene ningún otro cambio en su repositorio que tales archivos sin seguimiento se seleccionará por defecto la casilla mostrar archivos sin seguimiento o Show untracked Files.

Enmendar Acometidas

Si se percata de que ha olvidado algo al acometer un cambio puede arreglar esto: abra otra vez el diálogo de acometida y especifique que la acometida actual "enmendará" la acometida previa en la rama actual. La nueva acometida reemplazará la anterior. Esta característica se utiliza a menudo para corregir acometidas incorrectas antes de que sean publicadas a otros repositorios.

Note: no corrija acometidas si ya han sido publicadas en un repositorio compartido puesto que esto puede molestar a otros si ya han basado sus cambios en el cambio publicado.

Ejemplo de enmienda:
Imagina que ha acometido un cambio de un archivo con un error tipográfico

Tras acometer el cambio se percata del fallo. Para corregir este fallo y la acometida correspondiente justo arregla el fallo en el archivo de código fuente

entonces abra otra vez la vista de Preparación (Staging View) o el Diálogo de Acometida (Commit Dialog) y seleccione la opción enmendar acometida anterior o Amend previous commit en la barra de herramientas.

El mensaje de acometida de su acometida anterior (la que quiere reemplazar) rellena el campo Mensaje de Acometida ("Commit Message"). Esto le da la oportunidad no sólo de corregir errores en el contenido de los archivos con control de versiones sino que también de corregir fallos en el mensaje de acometida que describe su cambio.

Como una alternativa a enmendar podría acometer la versión corregida en un a acometida subsiguiente. Pero la primera acometida que contiene el fallo no es útil para nadie y para no liar el historial del proyecto con acometidas innecesarias usted debería enmendar la acometida.

Tenga en cuenta que enmendar acometidas que ya han sido publicadas en otros repositorios puede causar problemas. Una vez que haya empujado una acometida a un repositorio remoto o que si repositorio local haya sido clonado por alguien más , debería ser muy cauteloso con enmendar acometidas. En este caso publicar una segunda acometida que corrija la primera es probablemente una mejor solución. De otro modo infórmeles a aquellos que usted ha enmendado una acometida publicada para que puedan reaccionar en consecuencia.

Revertir Cambios

Revertir cambios en el árbol de trabajo

Reemplazar con Archivo en el Índice de Git

Los cambios que no han sido aún acometidos y aún no han sido preparados pueden ser revertidos para un conjunto de archivos seleccionados. Seleccione el o los archivos en el Explorador de Paquetes o en una vista análoga y pinche Reemplazar con > Archivo en el Índice Git (Replace With > File in Git Index).

Reemplazar con HEAD

Pinche Reemplazar con > HEAD (Replace With > HEAD) para reemplazar los archivos seleccionados con su versión de HEAD. Puede utilizar Resetear a (Reset to) con la opción hard para forzar el reseteo completo del árbol de trabajo de su repositorio de vuelta al estado de la acometida HEAD (véase abajo "Resetear su HEAD actual") Esta operación revertirá todos los cambios en el árbol de trabajo y el índice.

Reemplazar con Rama, Etiqueta o Referencia

Pinche Reemplazar con > Rama, Etiqueta o Referencia (Replace With > Branch, Tag or Reference) para reemplazar los archivos seleccionados con su versión correspondiente a la rama, etiqueta o referencia.

Reemplazar con acometida

Pinche Reemplazar con > Acometida (Replace With > Commit) para reemplazar los archivos seleccionados con su versión correspondiente a la acometida seleccionada.

Reemplazar por la revisión anterior

Los cambios que ya han sido preparados o incluso acometidos pueden ser "revertidos" reemplazándolos con una versión que provenga desde una acometida previa. Seleccione un recurso único en el Explorador de Paquete o una vista análoga y pinche Reemplazar Con > Revisión Previa (Replace With > Previous Revision). El repositorio determinará la última acometida que modificó el recurso seleccionado y ofrecerá reemplazar el recurso del espacio de trabajo con los contenidos es esta acometida.

Esto principalmente se pretende para "eliminar" archivos sueltos de una acometida (al acometer los recursos revertidos del espacio de trabajo, serán efectivamente eliminados de la acometida actual). Incluso aunque esto funciona con carpetas y proyectos, los resultados de reemplazar una carpeta o proyecto con una "revisión previa" pueden ser inesperados.

Revertir utilizando quickdiff

La característica quickdiff puede ser utilizada para revertir cambios individuales en un archivo. Puede revertir por línea, bloque (véase rango de líneas cambiadas) o selección. Seleccione todo el texto y entonces Revertir selección (Revert selection) para revertir un archivo completo.

Revertir cambios introducidos por una acometida específica

Los cambios que se introducen por una acometida dada pueden ser revertidos por una nueva acometida automáticamente creada encima de la acometida actualmente verificada (checked out). La acometida que va a ser revertida no tiene que ser verificada para eso.

Seleccione la acometida en la Vista de Historia o History View, abra el menú de contexto y seleccione Revertir Acometida (Revert Commit). Esto revierte los cambios que introduce la acometida seleccionada creando una nueva acometida sobre la acometida actualmente verificada.

Resetear su HEAD actual

Git ofrece la posibilidad de resetear la HEAD de la rama actual a cualquier otra acometida. Ello opcionalmente resetea el índice y el árbol de trabajo para coincidir con esa acometida. Note que esta acción afecta a todos los archivos y carpetas en el repositorio entero.

Usted tiene la opción de hacer un reseteo duro, uno mixto y uno blando.

• Blando (soft) - la HEAD ahora apunta a una acometida nueva, el índice y el árbol de trabajo permanencen inalterados
• Mixto) (mixed) - la HEAD ahora apunta a una nueva acometida, se actualiza el índice, el árbol de trabajo permanece inalterado
• Duro (hard) - la HEAD apunta a una nueva acometida, se actualizan el índice y el árbol de trabajo

Resetear a una rama o etiqueta específica

Seleccione Equipo -> Resetear... (Team -> Reset...) en un proyecto. Esto abre un diálogo donde puede seleccionar una rama o una etiqueta.

Resetear a una acometida específica

Seleccione una acometida en la vista de Historia y abra el menú de contexto. Aquí encontrará las entradas Hard reset, Mixed reset y Soft reset.

Revertir todos los cambios locales y preparados

Esto puede ser hecho utilizando un reseteo duro. Si usted resetea a la HEAD actual (normalmente la última acometida de su rama) con la opción dura usted reseteará la rama actualmente verificada a esta acometida y sobrescribirá el árbol de trabajo y el índice con el contenido de HEAD. Puede hacerlo de tres modos:

• Seleccione Equipo > Resetear... (Team > Reset...) en un proyecto. En el diálogo selección HEAD o su rama actual y cambie el botón selector a duro.
• Pinche botón derecho y seleccione Resetear... en cualquier rama o etiqueta en la Vista de Repositorios. Esto abre un diálogo que le permite a usted decidir acerca del tipo de reseteo. Escoja aquí duro.
• Abra el menú de contexto en la acometida HEAD en la vista de Historia y seleccione Reseteo Duro (Hard Reset).

Ramificar

Notas generales sobre las ramas

Acometer cambios a un repositorio local no es práctico sin utilizar una rama local (véase la sección conceptos arriba). Aún más, utilizando varias ramas diferentes, es posible trabajar en diferentes cambios en paralelo alternando entre esas ramas.

Por ello, antes de empezar a cambiar el repositorio local, el primer paso es típicamente crear una rama local. Las ramas locales se "basan en" bien una acometida o una rama de seguimiento remoto.

La segunda opción se recomienda cuando se trabaja con repositorios remotos, puesto que simplifica la tarea de sincronizar los cambios locales con los remotos añadiendo la denominada ("configuración flujoarriba") "upstream configuration" a la nueva rama local.

Véase Diálogo de creación de Rama para más detalles.

Configuración flujoarriba o Upstream

Cada rama local que se basa en una rama de seguimiento local puede tener alguna configuración adicional indicando el repositorio remoto, la rama remota y la denominada estrategia de empuje. Véase Diálogo de creación de Rama para más detalles.

Típicamente, esta configuración se crea automáticamente al crear la rama local basada en una rama de seguimiento remoto. Sin embargo, se puede mostrar y editar en la configuración de repositorio o pinchando (Mostrar en > Propiedades) Show In > Properties en una rama en una rama en la Vista de Repositorios.

Verificar una Rama existente

Desde el menú de equipo en un nodo de proyecto:

• Seleccione Team > Switch To... y seleccione un nombre de rama de la lista

Si hay demasiadas ramas la lista no mostrará todas. En este caso

• Seleccione Team > Switch To... > Other...
• En el diálogo, seleccione una Rama, una Etiqueta o una Referencia
• Pinche Ok

Desde la Vista de Repositorios Git

• pinche (Verificar) Checkout en un nodo de rama
• o doble clic en un nodo de rama

Desde la Vista de Historia

• Pinche (Verificar) Checkout en una acometida que tenga un rótulo de rama
• Si más de una rama apunta a la acometida un diálogo le permitirá decidir que rama verificar.

Crear una Nueva Rama Local

Esto siempre se hace con el Diálogo de Creación de Ramas. La rama recién creada puede ser opcionalmente verificada seleccionando una casilla de diálogo.

Desde el menú de equipo

• Seleccione (Equipo > Cambiar a... > Nueva Rama...) Team > Switch To... > New Branch....
• En el diálogo, seleccione una rama, una etiqueta o una referencia.
• Pinche (Crear Rama...) Create Branch....
• El diálogo de Creación de Ramas se abrirá.

Desde la vista de Repositorios

• Seleccione (Crear Rama...) Create Branch... en el nodo ("Ramas") "Branches" o en cualquier otro nodo rama "Branch", etiqueta "Tag" o referencias "References".
• El diálogo de Creación de Ramas se abrirá.

Desde la Vista de Historia

• Seleccione crear rama Create Branch...
• El diálogo de Creación de Ramas se abrirá

Renombrar una Rama Existente

Desde el menú de Equipo en un nodo de Proyecto

• Seleccione (Equipo > Avanzado > Renombrar Rama...) Team > Advanced > Rename Branch...
• en el diálogo de selección de rama, seleccione la rama a renombrar
• Introduzca el nuevo nombre de rama y pinche OK

Desde la Vista de Repositorios

• Abra la vista de repositorios Git
• Seleccione Renombrar Rama...) Rename Branch... o presione F2 o en la rama que quiera renombrar
• Introduzca el nuevo nombre de rama y pinche OK

Desde la Vista de Historia

• Seleccione (Renombrar Rama...) Rename Branch... en una acometida con un rótulo de rama
• Introduzca el nuevo nombre de rama y pinche Ok

Eliminar una Rama

Todas las acciones abajo muestran el mismo comportamiento con respecto a lo siguiente:

• La rama actualmente verificada no puede ser eliminada
• Si la eliminación de la rama puede resultar en una pérdida de datos, se muestra un aviso que debe ser confirmado
  • EGit asume una potencial pérdida de datos si la rama apunta a una acometida que no es alcanzable desde la acometida actualmente verificada

Desde el Menú Equipo en un nodo de Proyecto

• Seleccione Team > Advanced > Delete Branch...
• Seleccione la rama a eliminar desde el diálogo mostrado y presione Ok

Desde la Vista de Repositorios

• Abra la Vista de repositorios Git
• Seleccione Delete Branch en la rama que quiera eliminar

Desde la Vista de Historia

• Seleccione (Eliminar rama) Delete Branch en una acometida con un rótulo de rama
• Si múltiples ramas apuntan a la acometida, un diálogo de selección será mostrado en el cual usted puede seleccionar las ramas a eliminar

Diálogo de Creación de Ramas

Hay varias acciones disponibles para crear una rama local. Toda esas acciones utilizan el diálogo de Creación de Ramas:

Introduzca el nombre de la rama local que quiera crear. Si se selecciona una rama fuente la cual es una rama de seguimiento remoto EGit sugerirá crear una nueva rama local con el mismo nombre.

Pinche Select... para seleccionar la rama fuente sobre la que se basará la nueva rama. Típicamente, ésta es una rama de seguimiento remoto, pero podría ser cualquier rama o acometida del repositorio (no se recomienda seleccionar una rama local si estás trabajando con un repositorio remoto). Si quiere basa la nueva rama en una acometida a la cual ninguna rama se refiere haga entonces clic en (Crear Rama...) Create Branch... desde la acometida mostrada en Vista de Historia.

Cuando se selecciona una rama fuente usted puede configurar la ("configuración flujoarriba") "upstream configuration" de la nueva rama lo cual es de utilidad cuando se extrae y empuja, pero particularmente cuando se arrastra. Dependiendo de la opción seleccionada se puede elegir la siguiente configuración:

• ("Mezclar acometidas flujoarriba en la rama local") "Merge upstream commits into local branch": Cuando se arrastra, los cambios serán extraídos desde flujoarriba y se actualizará la rama de seguimiento remoto. Entonces la rama local actual se mezclará con los nuevos cambios. Esto es lo habitual si la nueva rama se basa en una rama de seguimiento remoto (pero esto puede ser anulado por la configuración específica del repositorio)
• ("Refundar acometidas de la rama local a flujoarriba") "Rebase commits of local branch onto upstream": Cuando se arrastra, los nuevos cambios se extraerán del flujo arriba y se actualizará la rama de seguimiento remoto. Entonces la rama local actual se refundará en la rama de seguimiento remoto actualizada
• Si desmarca la opción ("Configurar flujoarriba para empujar y arrastrar") "Configure upstream for push and pull": Cuando se arrastre, no se hará ninguna configuración específica de flujoarriba para la nueva rama; sin embargo, si existiera una remota por defecto (una remota con nombre "origin", arrastrar intentará utilizar la configuración de esta remota; esto es lo normal si la nueva rama no está basada en una rama de seguimiento remoto

Usted puede visualizar y editar la configuración flujoarriba en la configuración de repositorio o seleccionando (Mostrar en > Propiedades) Show In > Properties en una rama en la Vista de Repositorios.

EGit también soporta el parámetro de configuración de git branch.autosetuprebase, póngalo a siempre always si quiere utilizar por defecto la estrategia de refundar arrastre. Si usted establece esto en la configuración del repositorio, esto se utilizará para todas las ramas locales creadas basadas en una rama de seguimiento remoto en este repositorio, si usted lo establece en la configuración de usuario se utilizará para todos sus repositorios.

En la parte inferior, usted puede decidir si la nueva rama será verificada inmediatamente.

Diálogo de configuración de Rama

Pinche Configure Branch... en una rama en la Vista de Repositorios para cambiar la configuración flujoarriba de una rama local. Seleccione que remoto ("." significa repositorio local) y rama debería seguir la rama local seleccionada. Marque "Rebase" si quiere que el arrastre refunde la rama local sobre los nuevos cambios que lleguen de la rama seguida, de otro modo el arrastre mezclará los nuevos cambios que lleguen de la rama seguida.

Mezclar

Una mezcla incorpora cambios de otra rama o etiqueta, desde el momento en que sus historias divergieron desde la rama actual, en la rama actualmente verificada.

Mezclar una rama o una etiqueta en la rama actual

Usted puede desencadenar la mezcla desde:

• la Vista de Historia
• el menú de Equipo o Team
• la vista de repositorios de Git

Iniciar una mezcla desde la vista de Historia

Ésta es la vista recomendada para iniciar una mezcla ya que muestra la historia de su repositorio. Asegúrese de que los botones conmutadores (Mostrar todos los cambios del repositorio) Show all changes in repository y (Mostrar todas las ramas y etiquetas) Show all Branches and Tags están seleccionadas en la barra de herramientas de la Vista de Historia. Esto asegura que usted vea la historia completa de su repositorio para que decida que rama quiere mezclar. Seleccione la acometida con la rama o rótulo de etiqueta que quiera mezclar y pinche Merge.

Iniciar mezcla desde el menú de (Equipo) Team

En el explorador de paquetes o navegador, abra le menú contextual de un nodo de proyecto. Seleccione (Equipo > Mezclar...) Team > Merge...

Ahora se abre el diálogo de Mezcla:

En el diálogo, seleccione una rama o etiqueta que quiera mezclar con su rama actual. Este diálogo también permite que usted seleccione las opciones de mezcla aplastada y avance rápido.

Iniciar una mezcla desde la Vista de Repositorios Git

Usted puede desencadenar una mezcla desde cualquier rama y nodo de etiqueta y desde el nodo de repositorio si ha verificado una rama local. Véase Mezclar una Rama o Etiqueta para más detalles.

Opciones de Mezcla

Las siguientes opciones de configuración de avance rápido para mezcla son reconocidas por EGit, las cuales se utilizan para todas las ramas:

[merge]
    ff = true|false|only

Cuando usted sólo quiera configurarlo para cierta rama, utilice lo siguiente:

[branch "name"]
    mergeoptions = --ff|--no-ff|--ff-only

opciones avance rápido

ff = true or mergeoptions = --ff 

Cuando la mezcla resuelve ser una de avance rápido, sólo actualiza el puntero de rama, sin crear una acometida de mezcla. Éste es el comportamiento por defecto.

ff = false or mergeoptions = --no-ff 

Crea una acometida de mezcla incluso cuando la mezcla se resuelve como una de avance rápido.

ff = only or mergeoptions = --ff-only 

Rechaza mezclar y abortar la operación de mezcla a menos que la HEAD actual esté actualizada o que la mezcla pueda ser resuelta como de avance rápido.

Cuando usted inicie la mezcla desde el menú de equipo ("Equipo > Mezcla") "Team > Merge..." puede establecer las opciones de mezcla de avance rápido, apastada o sin-acometer en el diálogo de mezcla.

Posibles resultados de mezcla

Tras presionar el botón de Mezcla, pueden suceder los siguientes escenarios:

• (Ya actualizada) Already up to date: Su rama actual apunta a una acometida que tiene la rama o etiqueta seleccionada como predecesora. En este caso nada ha cambiado.
• (Avance rápido) Fast-forward: Su rama actual apunta a una acometida que es una predecesora de la rama o etiqueta seleccionada. En este caso su rama se mueve y apunta a la rama o etiqueta seleccionada; esta nueva HEAD se verifica al árbol de trabajo. El avance rápido es muy común cuando se trabaja con repositorios remotos: cuando una rama de seguimiento remoto se actualiza, la mezcla con la rama correspondiente generalmente es una de avance rápido. Usted puede realizar un arrastre extrayendo de la rama remota (p. ej. origin/master) y mezclándolo en la rama local correspondiente (p. ej. master).
• (Mezcla verdadera) Real merge: Cuando ninguna de las condiciones de arriba se aplican egit desencadena una mezcla de las acometidas. Hay dos posibles salidas: si no ocurre ningún conflicto la rama actual apuntará a la acometida recién creada; si ocurren conflictos los archivos en conflicto serán marcados con rótulos decoradores (véase Resolver un conflicto de mezcla para más acciones en caso de conflictos de mezcla).

Diálogo de Resultados de Mezcla

El resultado de la mezcla se resume en un diálogo:

En la primera línea verá el resultado de la mezcla. Los posibles resultados son ("Ya-actualizado") "Already-up-to-date", ("Avance-rápido") "Fast-forward", ("Mezclado") "Merged", ("En conflicto") "Conflicting" o ("Fallido") "Failed". Un a posible razón para ("Fallido") "Failed" puede ser que haya cambios conflictivos en el directorio de trabajo.

En la segunda línea verá la nueva acometida de HEAD en caso de una mezcla exitosa (Already-up-to-date, Fast-forward or Merged).

En la tabla verá las acometidas que fueron mezcladas.

Resolver un conflicto de mezcla

Una mezcla puede producir conflictos que requieran acción del usuario. Esto es el caso cuando los contenidos de los archivos no se pueden mezclar automáticamente. Estos conflictos están marcados con un rótulo decorativo en la vista de preparación o Staging View. Usar la vista de preparación para encontrar los archivos en conflicto para solucionarlos es práctico ya que la Vista de Preparación muestra solamente los archivos modificados tal que no necesite vadear por sus recursos sino por solo aquellos que podrían necesitar su atención para solucionar los conflictos.

También los recursos en conflicto se decoran en los árboles de navegación como el Explorador de Proyectos o Explorador de paquetes

Los conflictos de mezcla el contenido de los archivos se muestran como marcadores de conflicto textuales (véase http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented para más detalles).

Utilizar la herramienta de Mezcla

• seleccione el recurso de nivel tope que muestre un rótulo decorador rojo de conflicto
• pinche (Equipo > Herramienta de Mezcla) Team > Merge Tool
• seleccione el modo de mezcla Utilizar HEAD (la ultima versión local) de archivos conflictivos y pinche OK

• Se abre el editor de mezcla mostrando la versión del árbol de trabajo en el panel izquierdo y la versión a ser mezclada en el panel derecho

• edite la versión del árbol de trabajo hasta que esté contento con ella
• (Equipo > Añadir) Team > Add el recurso mezclado para marcar el conflicto como resuelto
• acometa la mezcla vía (Equipo > Acometer) Team > Commit

Resolución Manual de Conflictos

Para resolver un conflicto tiene que seguir estos pasos:

• Navegue al recurso en conflicto
• Edite el contenido del recurso en conflicto
• Dígale a EGit que el conflicto está resuelto con Equipo > Añadir (Team > Add)
• Acometa la resolución del conflicto con Equipo > Acometer (Team > Commit)

Encontrar archivos en conflicto

Un repositorio que contenga archivos en conflicto tiene un rótulo de texto decorador "|Conflicts" adjunto al nombre del repositorio. Los recursos en conflicto y las carpetas que contengan tales recursos en conflicto obtienen un decoración de rótulo de conflicto.

Editar archivos en conflicto

En el archivo en conflicto , el área donde sucedieron los cambios conflictivos está marcada con los marcadores <<<<<<<, =======, y >>>>>>>. La parte antes de la ======= es típicamente su parte, y la parte tras ella es típicamente la de otros (véase http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented para más detalles).

Abra el archivo en un editor, edite el contenido y salve el editor.

Note que este paso no es obligatorio. EGit no comprueba el contenido para decidir si un conflicto está resuelto. El siguiente paso ES relevante.

Añadir la resolución de conflicto al índice git

Una vez que haya acabado con la edición de un archivo, bien pinche Añadir al Índice (Add to Index) en la Vista de Preparación o pinche Equipo > Añadir (Team > Add) para añadirla resolución del conflicto al índice de git. Esto también marcará el correspondiente conflicto como resuelto.

Cuando hayas resuelto todos los conflictos la decoración textual del rótulo de repositorio cambia a "Mezclado" ("Merged"). No quedan ya más marcadores de conflictos.

Acometer una mezcla

Cuando el repositorio está en estado "Mezclado" ("Merged") (tal como se indica con con el rótulo textual decorativo "|Conflicts" adjunto al nombre del repositorio) la mezcla puede ser finalmente acometida.

En la Vista de Preparación usted puede querer eliminar las marcas de conflicto del mensaje estándar de acometida de mezcla el cual está generado por la operación y actualizar el mensaje de acometida si fuera necesario. Entonces pinche Acometer (Commit) para acometer la resolución de conflicto.

Si quiere utilizar el Diálogo de Acometida para acometer la resolución del conflicto pinche Equipo > Acometer... (Team > Commit...) en cualquier sitio del árbol de navegación. Se abre el Diálogo de acometida con un aspecto ligeramente diferente comparado con una acometida normal:

• El área de mensaje de acometida se rellena con un mensaje estándar de acometida de mezcla.
• No es posible enmendar la acometida previa.
• No es posible añadir archivos no seguidos.
• No es posible desmarcar las casillas. Esto garantiza que todos los conflictos resueltos son acometidos.

Tras presionar el botón "Acometer" ("Commit") la mezcla está completada.

Abortar Mezcla

Si una mezcla resultó en conflictos usted puede abortar la mezcla con un reseteo duro a la rama actual. Esto se puede hacer en el estado "En conflicto" ("Conflicts") y en el estado "Mezclado" ("Merged"), p. ej. antes y después de que hayas resuelto los conflictos.

El reseteo duro se puede hacer desde el menú de equipo o team, la Vista de Repositorios Git o la Vista de Historia. Véase Revertir todos los cambios locales y preparados para más detalles.

Refundar (Rebasing)

Introducción de refundar

Refundar aplica una cadena de acometidas sobre una acometida dada. Un escenario típico es el desarrollo de alguna característica en una rama "tema" la cual haya sido creada desde una rama maestra "master" en algún momento dado. Cuando se actualiza la maestra "master" con cambios p. ej. de otros desarrolladores mientras "tema" está aún en desarrollo, puede hacerse necesario incorporar esos cambios a "tema".

Asumamos que iniciamos el desarrollo en "tema" creando la rama "tema" a partir de la maestra. En este punto, ambas "master" y "tema" apuntan a la acometida "E". Cuando se añade la primera acometida ("A") a "tema", la historia de acometidas del repositorio se parece a esto:

          Un tema
         /
    D---E master

Ahora, asumamos que hubo algunas acometidas más en "tema" y así también como en "master" (por ejemplo, "master" puede seguir algún repositorio remoto y que hubo ciertos cambios en aquel repositorio que han sido arrastrados en la "master"):

          A---B---C tema
         /
    D---E---F---G master

Ahora, para incormporar los cambios de "master" al "tema", una Refundación (Rebase) del "tema" sobre "master" produciría

                  A'--B'--C' tema
                 /
    D---E---F---G master

Técnicamente, la secuencia de acometidas que están contenidas en "tema" pero no en "master" se aplican (esto es, selectivamente) sobre la maestra "master" una a una.

Note que las acometidas A, B, C ni son perdidas ni cambiadas, sino que en cambio será creada una nueva cadena de acometidas A', B', C' con los mismo cambios y mensajes de acometida como las acometidas originales (pero diferentes IDs de acometida). Las viejas acometidas A, B, C están todavía por ahí en la base de datos de objetos pero no son ya visibles puesto que no son alcanzables desde ninguna rama. A', B', C' son diferentes de las viejas puesto que ahora contienen los cambios F y G.

Refundar, Un Ejemplo Simple

Veámos un simple ejemplo: tenemos un archivo de texto "FamousWords.txt" el cual inicialmente podría tener algún contenido como

Chapter 1
Once upon a time...

Chapter 2
To be or not to be

Ahora, en "tema", se crean dos acometidas, la primera añadiendo una traducción al francés del capítulo 2, y otra añadiendo la traducción al alemán:

Tras el primer cambio en "tema":

Chapter 1
Once upon a time...

Chapter 2
To be or not to be
Être ou ne pas être

Tras el segundo cambio en "tema":<br/>
<pre>Chapter 1
Once upon a time...

Chapter 2
To be or not to be
Être ou ne pas être
Sein oder nicht sein

Al mismo tiempo, el archivo se cambió en "master" al añadir dos acometidas de traducción al francés y al alemán para el Chapter 1:

Chapter 1
Once upon a time...
Il était une fois
Es war einmal

Chapter 2
To be or not to be

La historia de acometidas se verá así:

Ahora, si se refunda "tema" sobre "master", los dos cambio en tema se aplican en la misma secuencia que se hubieran aplicado durante la evolución de "tema".

El resultado es una versión mezclada de "FamousWords.txt":

Chapter 1
Once upon a time...
Il était une fois
Es war einmal

Chapter 2
To be or not to be
Être ou ne pas être
Sein oder nicht sein

y una historia de acometidas con la historia de acometidas de "tema" sobre la actual "master":

El Mundo Real: Conflictos de Refundar

Hasta ahora, hemos asumidos que los cambios en "tema" pueden ser auto-mezclados a la "master". En el mundo reaI, sin embargo, puede suceder que encuentre conflictos durante la refundación (rebase). Ahora, si una acometida que va a ser selectivamente escogida contiene cambios que entran en conflicto en "master", la operación de refundar se interrumpe tras aplicar el cambio en conflicto; los conflictos se visualizan del modo habitual (con marcadores de conflicto) y el usuario obtiene una oportunidad de decidir que hacer:

• resolver estos conflictos manualmente,
• saltarse la acometida actual, o
• abortar la refundación completamente

Si se escoge (Resolver Conflictos) Resolve Conflicts, y los conflictos han sido resueltos manualmente, los cambios deben ser ("Añadidos") "Added", y entonces la (refundación) rebase puede continuarse, p. ej. será aplicada la siguiente acometida en la cadena.

Si se escogió (Evitar) Skip, los cambios en conflicto se revertirán y se aplicará la siguiente acometida en la cadena.

Si se escogió (Abortar) Abort, se deshará completamente la operación de refundar, devolviendo el repositorio a su estado original antes de que comenzara la refundación. Este proceso se repite hasta que la última acometida fuera aplicada o evitada. Finalmente, la rama "tema" se cambiará para apuntar a la última acometida.

Para entender mejor ("Evitar") "Skip", miremos de nuevo la introducción de arriba. Si asumimos que la acometida "B" causa algunos conflictos con la actual "master", el usuario podría decidir simplemente evitar "B"; la nueva historia de acometidas tras refundar quedaría así:

                  A'--C' tema
                 /
    D---E---F---G master

Iniciar Refundar

en la vista de historia o In the History View:

• verificar la rama que quieres refundar
• Seleccionar la acometida sobre la cual quieres refundar la rama verificada. Esta acometida se convertirá en la nueva base para todas las acometidas que son refundadas
• Pinche Rebase

En la vista de Repositorios Git o In the Git Repositories View: En los nodos de Repositorios, Rebase... abre un diálogo que pregunta al usuario que seleccione una rama que no está verificada; la rama actualmente verificada se refundará sobre la rama seleccionada. En los nodos rama o "Branch" (ambas ramas Local o Seguimiento Remoto, pero no en la rama actualmente verificada), Rebase refunda inmediatamente la rama actualmente verificada sobre la rama seleccionada:

Diálogo de confirmación de Refundar

Si Refundar tuvo exito, se mostrará un diálogo de confirmación; este diálogo puede ser suprimido marcando una casilla; una preferencia en ña página de preferencias de Git permite hacer que los diálogos vuelvan a aparecer. Si el diálogo se suprime, se escribe un mensaje de "Información" al log de Eclipse.

Conflictos de Refundar

Si ocurre un conflicto durante una refundación, se muestra un diálogo que da alguna información sobre la acometida que causó el conflicto. Seleccionando el botón radial, puede usted decidir s:i

• Iniciar la Herramienta de Mezcla para resolver los conflictos manualmente
• Evitar la acometida actual
• Abortar toda la refundación
• No hacer nada (regresar al espacio de trabajo), esto equivale a pulsar "Escape":

A menos que se haya escogido (Evitar) Skip o (Abortar) Abort en el diálogo, los conflictos deben ser resueltos manualmete editando los archivos de conflictos. Cuando se acaba con la edición, los archivos deben ser declarados como resueltos añadiendolos al índice de git.

Si usted canceló el asistente de refundar el modo más fácil de encontrar las archivos con conflictos es utilizar la Vista de Preparación. Pinche (Herramienta de Mezcla) Merge Tool en el archivo con conflictos para abrir la herramienta de mezcla para este archivo. La Herramienta de Mezcla también puede iniciarse desde la entrada correspondiente en el menú de (Equipo) Team.

Edite el archivo hasta estar contento con la resolución de conflicto y pinche anadir al índice Add to Index en la entrada correspondiente de la Vista de Preparación. Esto prepara la resolución del conflicto y marca el conflicto como resuelto.

Tras resolver todos los conflictos, se activa loa operación de continuar Continue. Para continuar la operación de refundación que fue parada debido a los conflict pinche en el botón Continuar de la Vista de Preparación o pinche Refundar > Continuar (Rebase > Continue) en el nodo de repositiorio de la Vista de Repositorios.

Si en vez de resolver conflictos quiere evitar la acometida que causa el conflicto pinche mejor Evitar (Skip).

Si quiere abortar la operación de refundación que está haciéndose pinche Abortar. Esto revierte al estado antes de que comenzara la refundación.

Abortar la Refundación

Mientras que el Repositorio esté en estado refundando o "Rebasing", el usuario puede siepre abortar la refundación en la Vista de Repositorios Git utilizando la acción de menú "Rebase > Abort" la cual está disponible en el nodo de Repositorio.

Refundación Interactiva

Sinopsis

La refundación interactiva permite editar rápidamente una serie de acometidas utilizando las siguientes acciones definidas en un plan de refundación:

• pick para definir el orden de las acometidas, mover entradas selectas permite reordenar
• skip para eliminar una acometida
• edit para enmendar una acometida
• reword para editar el mensaje de una acometida
• squash para aplastar o juntar una acometida con su acometida predecesora imcluyendo sus mensajes de acometida
• fixup para aplastar las diferencias de un acometida con su predecesora descartando el mensaje de la acometida aplastada

Warning: Atención no reescriba las acometidas que ya hayan sido publicadas en un repositorio remoto, se considera una mala práctica para todo salvo para ramas experimentales o de revisión ya que sus colegas pueden haber basado ya su trabajo en estas acometidas publicadas y les forzarías también a reescribir sus cambios. Aunque es una herramienta frecuentemente utilizada en ramas de revisión p. ej. cuando se utiliza Gerrit para reescribir cambios que tengan que ser mejorados basandose en retroalimentación de revisión.

Iniciar refundar interactivo

Primero verifique la rama local (aquí rama a refundar o toRebase) que contenga la serie de acometidas que quiera usted editar. Entonces abra la Vista de Historia para este repositorio y pinche Interactive Rebase en la acometida que precede a la acometida más antigua que quiera reescribir. Con frecuencia es a la que apunta origin/master.

Esto abre una nueva vista (Refundación interactiva de Git) Git Interactive Rebase que muestra el pan de refundación poblado con las acometidas a ser modificadas en órden topológico en la secuencia en que se procesarán durante la operación de (refundar) rebase. La acción inicial para todos las acometidas es (Escoger) Pick la cual escogerá selectivamente la acometida correspondiente. Note que Egit también rebobina HEAD a la acometida precursora a la primera de la lista de edición para preparar el repositorio para refundarlo.

Planificar refundación

Aquí el plan inicial de refundar, primero viene la primera acometida a aplicarse en la HEAD rebobinada y luego todas las demás acometidas a ser refundadas en el orden en que se aplicarán cuando se pinche "Start".

Después preparamos el plan de refundar, moviendo las acometidas arriba y abajo utilizando los botones de flechas para reordenar acometidas y elegir la acción de refundar que queremos aplicar en las acometidas que queremos ajustar.

En este ejemplo primero se reordenó las acometidas tal que la implementación de nuevas operaciones de calculadora precedan inmediatamente la acometida de la implementación de las pruebas para cada operación respectiva.

Aquí lo que se quiere modificar en esta serie de acometidas o Here what I want to modify in this series of commits:

Se quiere evitar acometer la "TODO list" ya que contiene una lista privada de cosas por hacer usadas al implementar las operaciones y no se necesitan más. Se necesita enmendar la acometida "Add divide operation" ya que está errónea, esto fue revelado por la prueba correspondiente en un cambio posterior, por lo tanto seleccione la acción Edit aquí La acometida "Add multiply operation" obviamente tiene un fallo en el mensaje de acometida así que se elige refrasear Reword. Se quiere aplastar la acometida de7647b en su predecesora ya que no tiene sentido tener el arreglo del javadoc separado de la implementación que describe, por lo que se elige Squash para aplastarla con su predecesora.

Ejecutar refundar interactiva

Cuando se acaba con la planificación de refundar pinche Start para iniciar la ejecución del comando de refundar. EGit precesará el plan y parará en las acometidas donde haya seleccionado acciones que necesiten su intervención para editar interactivamente la acometida correspondiente.

En nuestro pequeño experimento refundar para la primera vez en la acometida "Add divide operation" ya que se ha señalado que se quiere editar. La última acometida escogida se resalta en negrita. en ese momento el primer paso evitando la acometida "TODO list" fue ya procesado y esta acometida ya no está en la serie de acometidas que se están reescribiendo mientras se ejecuta refundar. También la acometida "Add divide operation" fue escogida selectivamente ya que se quiere arreglar. Note que EGitya ha seleccionado la opción enmendar o "Amend" en la Vista de Preparación para preparar la enmienda de esta acometida.

Ahora se arregla el fallo de esta acometida, se preparan los cambios necesarios para arreglar el fallo, se ajusta el mensaje de acometida si es necesario y se pincha acometer Commit para enmendar la acometida defectuosa.

Veamos la vista de historia para ver el grafo de acometidas resultante. La HEAD ahora apunta a la acometida arreglada reescrita "Add divide operation", note que si SHA1 es diferente de su versión original desde la reescritura de la acometida para arreglar el fallo.

Seguido de pincha Continue para continuar el proceso del plan de refundar. Refundar selecciona las acometidas "Divide test" y "Add multiply operation" y se para de nuevo sacando el editor de mensajes tal que se pueda arreglar el fallo de escritura de el mensaje de acometida de la última acometida.

Edite el mensaje de acometida para arreglar el fallo de escritura y pinche OK para enmendar el mensaje de acometida y continuar procesando.

Refundar selecciona las tres siguientes acometidas, aplasta las acometidas "add power" y "Fix javadoc for power operation" en una sola nueva acometida y para de nuevo tal que se pueda preparar el mensaje de acometida de la nueva acometida. Se inicializa con la concatenación de mensajes de las acometidas que se aplastan.

Edite el mensaje de la acometida aplastada y pinche OK para continuar procesando.

Refundar elige la acometida final "Power test" y finaliza con éxito.

Finalmente demos otro vistazo a la vista de Historia para examinar el resultado de la orden refundar interactivamente. Compare la serei de acometidas reescritas ahora contenidas en la rama a refundar o "toRebase" con la vieja serie de acometidas aún visible ya que se puso otra rama local "start" ahí para mantener la vieja serie visible.

Instrucciones de Seguridad

Si sucede que se equivoca durante este proceso multipaso siempre puede pulsar (Abortar) Abort para parar la operación de refundar que esté en progreso y retroceder al punto inicial.

Cuando comience a utilizar esta característica puede ser buena idea ubicar una segunda rama local en el punto inicial (como se mostro en este ejemplo) para hacer más obvio lo que sucede hasta que se familiarice con este poderoso comando de Git.

Refundar con auto-escondido (auto-stashing)

EGit también soporta la opción de configuración de Git rebase.autostash. Establece la opción de autoescondido rebase.autostash = true para crear automáticamente un escondite temporal antes de que comience la operación de refundar, y aplicarlo después de que finalice la operación. Esto significa que puede ejecutar refundar y también refundar interactivamente en un árbol de trabajo sucio. Sin embargo, (utilícese con cuidado:) use with care: la aplicación final de escondido tras un refundar exitoso puede resultar en conflictos nada triviales.

Elección selectiva

Introducción a la elección selectiva

Una acometida C dada en al rama stable-1.0 contiene un conjunto de cambios que querrias integrar en su desarrollo actual en la rama maestra master.

                  A--B--C--D stable-1.0
                 /
    D---E---F---G master HEAD

Elija selectivamente la acometida C para crear una nueva acometida C' sobre la acometida head de la rama master actualmente verificada. C' contendrá entonces los cambios realizados en C aplicados sobre la HEAD de la rama maestra master actualmente verificada.

                  A--B--C--D stable-1.0
                 /
    D---E---F---G--C' master HEAD

Ejemplo de elección selectiva

Usted está trabajando en la rama "feature2" (HEAD). Hay una acometida "feature 1" en otra rama.
Quiere integrar los cambios realizados por la acometida "feature 1" en su desarrollo actual de la rama "feature 2".

• En la Vista de Historia seleccione la acometida "feature 1" y pinche Cherry-pick:

• Como resultado obtendrá una nueva acometida "feature 1" al extremo de su actual rama "feature" que contiene los cambios de "feature 1":

• La elección selectiva puede encontrar conflictos. En este caso los marcadores de conflicto se muestran en las fuentes afectadas:

• Abra la vista de Preparación para encontrar rápidamente los archivos en conflicto.
• Pinche Herramienta de Mezcla (Merge Tool) en un archivo con conflictos para abrir la herramienta de mezcla para este archivo
• Resuelva los conflictos editando los fuentes correspondientes del mismo modo en que se describió en Resolver un conflicto de mezcla
• Añada (Add) los archivos que usted editó para marcar los conflictos como resueltos
• Acometa (Commit) la resolución del conflicto

Etiquetar

Crear una etiqueta o Tag

• Abra la vista de Historia y pinche Crear Etiqueta... (Create Tag...) en la acometida que quiera etiquetar

• Introduzca el nombre de la etiqueta
• Introduzca l mensaje de al etiqueta
• Pinche OK para crear la etiqueta anotada

Las etiquetas pueden ser también creadas desde el menú de equipo, pinche Equipo > Avanzado > Eiqueta... (Team > Advanced > Tag...), introduzca el nombre de la etiqueta y el mensaje, seleccione la acometida que quiere etiquetar (por defecto es HEAD) y pinche OK.

Reemplazar una Etiqueta Existente

¿Qué hacer si etiquetó la acometida errónea o acabó con algún tipo de error de escritura?

• Si usted aún no empujó esto justo reemplace la etiqueta y habŕá finalizado.
• Si ya está publicado no debería reemplazar la etiqueta If it's already published you shouldn't replace the tag sino usar un nuevo nombre ya que de otro modo tendrá que decir a todo el mundo que obtuvo la vieja etiqueta que la reemplace manualmente con la que usted actualizó. Esto se debe a que Git no cambia (y no debería cambiar) etiquetas a espaldas de sus usuarios. Así que si alguien ya consiguió la vieja etiqueta, hacer un arrastre git de su árbol no debería hacerles sobrescribir la vieja.

Así que si la vieja etiqueta no ha sido aún empujada puede corregirla del siguiete modo :

• En la Vista de Historia pinche Tag... en la acometida sobre la que quieres colocar la etiqueta

• Selecciona la etiqueta que quieres reemplazar desde la lista de etiquetas existentes
• o comience a escribir cualquier parte de la etiqueta que quiere buscar en el campo Nombre de Etiqueta o Tag Name, esto filtrará la lista de etiquetas existentes para mostras aquellas que que contengan la cadena que está escribiendo, entonces seleccione la etiqueta que quiere reemplazar
• Marque la casilla forzar reemplazo de la etiqueta existente o Force replace existing tag
• Cambie la etiqueta y pulse OK

Borrar Etiquetas

Para borrar etiquetas , seleccione la etiqueta a borrar y pinche Delete Tag.

Note: es una mala práctica borrar etiquetas que han sido ya publicadas en un servidor público, algunos servidores Git incluso desautorizan el borrado de etiquetas para asegurar la trazabilidad de lanzamientos que son normalmente etiquetados. Véase también Sección ("Sobre reetiquetar") "On re-tagging" en la documentación de referencia de Git del comando etiquetar.

Etiquetas Ligeras y Firmadas

En la vista de repositorios se muestran etiquetas ligeras así también como en el diálogo crear etiqueta, pero no pueden ser editadas. En la vista de Repositorios se muestran etiquetas con un icono azul, se decoran con amarillo las etiquetas anotadas.

En la vista de Historia, las etiqueta se muestran como rótulos amarillos.

Las etiquetas firmadas aún no están soportadas por EGit, utilice en cambio la línea de comandos git tag -s.

Parches

Crear Parches

"Un parche es una pieza de software diseñada con la que arreglar problemas, o actualizar un programa de ordenador o sus datos de soporte" (wikipedia). Un archivo de parche contiene una descripción de los cambios de un conjunto de recursos que puede ser automáticamente aplicado sobre otro espacio de trabajo de eclipse o repositorio de Git.

Los formatos de parche utilizados por eclipse "quipo > Aplicar parche (Team > Apply Patch) y por git (git apply o git am en la ĺinea de comandos) son diferentes. Es posible crear ambos tipos de un parche en EGit.

Crear un Parche desde una Acometida

Es el caso de uso más común para un sistema de versionado distribuido. Un desarrollador acomete un cambio en una característica local o en una rama de soluciona un error y quiere exportar este cambio a un archivo de parche.

Se puede hacer desde la Vista de Historia:

El archivo de parche contendrá la diferencia entre la acometida y su padre en la Vista de Historia. Note que el filtro de la Vista de Historia se aplica también para la creación de parches.

Asistente de Parche

El asistente consite en dos páginas. La página uno le permite seleccionar la ubicación del parche:

El nombre del archivo de parche se crea a partir de la primera línea del mensaje de acometida.

En la segunda página puede cambiar el formato del parche.

ACtualmente hay una casilla: Exportar en formado de parche git o Export in git patch format.

• Si no lo marca (esto es por defecto) el parche se puede aplicar con el asistente de eclipse Aplicar parche Apply Patch.... Las rutas son relativas a los proyectos de eclipse y no contienen prefijos (como git format-patch --no-prefix en la línea de comandos).
• Si lo marca el parche parecera como el del resultado de git format-patch --no-stat en la línea de comandos.

No se muestran diffs binarios.

Aplicar Parches

Actualmente EGit no es capaz de aplicar parches en formato Git. Es posible aplicar parches utilizando el formato estándar de Eclipse (diff unificado) utilizando Team > Apply Patch.... Los parches de Git pueden contener extensiones no estándar para renombres y diffs binarios. La versión actual de Egit no genera estas extensiones.

Gestionar Repositorios

La "Vista de Repositorios Git" es el elemento de IU primaria para facilitar el trabajar con múltiples repositorios simultáneamente (p. ej. dentro de un espacio de trabajo de Eclipse).

Esta vista puede ser abierta utilizando la ruta de menú
Windows > Show View > Other... > Git > Git Repositories

También es parte de la perspectiva Explorar repositorios de Git o "Git Repository Exploring" disponible utilizando la ruta de menú
Window > Open Perspective > Other... > Git Repository Exploring

Si ya tiene proyectos en su espacio de trabajo que estén compartidos con un Repositorio de Git, puede utilizar
Team > Show in Repositories View

en cualquier recurso para abrir la vista.

Añadir Repositorios a la Vista de Repositorios Git

Inicialmente, la Vista de Repositorios Git está vacía. Para añadirle Repositorios, hay varias opciones:

1. Añadir manualmente un Repositorio desde el Sistema de Archivos Local
2. Clonar y hacer que se añada automáticamente a la vista un Repositorio
3. Crear un Repositorio en el Sistema de Archivos Local
4. Añadir a la vista un Repositorio pegándo una ruta de Repositorio Git

Añadir manualmente un Repositorio

Puede añadir un repositorio desde su sistema de archivos local a la vista de Repositorios Git sin clonarlo. Esto puede ser de utilidad si está usted configurando un nuevo espacio de trabajo de Eclipse y quieres reutilizar sus Repositorios Git. Utilice el botón añadir un repositorio git existenet o Add an existing Git Repository desde la barra de herramientas de la vista:

Aparecerá un diálogo preguntando por un directorio de su sistema de archivos. Tras seleccionar el directorio adecuado, puede pulsar el contón buscar o Search para ver una lista de Repositorios en este directorio. Puede seleccionar entonces alguno o todos los repositorios encontrados y añadirlos a la vista utilizando OK:

Clonar un Repositorio

Para clonar un Repositorios, refierase a Clonar Repositorios remotos. Tras una operación de clonado exitosa, el Repositorio recién clonado debería aparecer en la vista de Repositorios Git automáticamente.

Puede utilizar el botón clonar un repositorio git o Clone a Git Repository desde la barra de herramientas de la vista para comenzar el asistente de clonado:

Por favor refiérase a Clonar Repositorios remotos para saber cómo utilizar el asistente.

Crear un Repositorio

Puede crear un nuevo repositorio vacío en el sistema de archivos local. Esto es útil si después quiere crear uno o más proyectos nuevos bajo este repositorio. Otro caso de uso es crear un nuevo repositorio desnudo a donde empujar. Utilice el botón Create a new Git Repository de la barra de herramientas de la vista:

Aparecerá un diálogo que le permitirá escoger un directorio:

Si selecciona la casilla crear Repositorio Desnudo oCreate as Bare Repository el nuevo repositorio no tendra directorio de trabajo. Entonces sólo podrá añadir contenido empujando cambios desde otro repositorio.

Añadir un Repositorio utilizando Copiar y Pegar

Como atajo, es también posible pegar la ruta del sistema de archivos local a un repositorio Git desde el portapapeles en esta vista. Para hacerlo, copia la ruta de un repositorio Git (la ruta completa de su carpeta .git) al portapapeles, entonces abre el menú de contexto en el panel de la vista:

o pinche Editar > Pegar (Edit > Paste) desde el menú principal (o la correspondiente atajo de teclado). Si el contenido del portapapeles no es adecuado, surgirá un error, de otro modo aparecería automáticamente el Repositorio añadido.

después de que la vista haya sido poblada con algunos repositorios, debería parecer algo así:

Eliminar Repositorios

Eliminar repositorios desde la Vista de Repositorios

Para eliminar un repositorio desde la Vista de Repositorios seleccione un repositorio y pinche en eliminar Repositorios o "Remove Repository"

Eliminar un Repositorio

Para eliminar un repositorio, seeleccione en la vista de repositorios y pinche eliminar repositorio o "Delete Repository".

Entonces confirme que quiere eliminar el repositorio y decida si quiere eliminar el directorio de trabajo del repositogrio con los proyectos contenidos en el repositrorio desde el entrono de trabajo de Elipse.

[parcial]

Estructura de la Vista de Repositorios Git

El siguiente pantallazo muestra los des niveles superiores de la Vista de Repositorios Git:

El nodo raíz representa el propio Repositorio. El nodo texto indica el nombre del Repositorio y su ubicación en el sistema de archivos local. Los nodos ramas o "Branches" y etiquetas o "Tags" permiten la navegación y manipulación de etiquetas o ramas. el nodo de referencias o "References" lista otras referencias las cuales no son ramas ni etiquetas, mayormente las referencias simbólicas "HEAD" y "FETCH_HEAD" (véase Referencias Git).

El nodo de ("Directorio de Trabajo") "Working Directory" muestra la ubicación y estructura del directorio de trabajo en el sistema de archivos local (solamente en caso de un desarrollo, o un repositorio no desnudo o non-bare, para repositorios desnudos o bare, este nodo es siempre una hoja).

Finalmente, el nodo de remotos o "Remotes" permite la exploración y maniupulación de configuraciones remotas utilizadas por Extracción o Fetch y Empuje o Push.

Funciones de la Vista de Repositorios Git

Importar Proyecto

Para trabajar con los contenidos de un repositorio git, sus archivos y carpetas deben ser importados en el espacio de trabajo de Eclipse en forma de proyectos. Mientras que el asistente de Clonado de Git permite hacer tales importacionies tras el clonado, la vista de Repositorios Git permite desencadenar importaciones de proyectos independientemente de la operación de clonado.

El menú de contexto ("Importar proyectos...") "Import Projects..." está disponible en el nodo "Repositorio" así como en cualquier "Carpeta" dentro del "Directorio de Trabajo" y en el propio nodo de "Directorio de Trabajo":

La razó para ofrecer la acción (Importar proyectos...) Import Projects... en varios nodos es que ciertos asistenes utilizados para importar proyectos pueden tener en cuenta el directorio de del Sistema de Ficheros, por ejemplo el asistente de (Importar proyectos existentes) Import Existing Projects. Si la importación se inicia desde el nodo "Repositorio" o el "Directorio de Trabajo", el directorio de tragajo de l repositorio se establece como contexto, de otro modo el directorio que corresponda al nodo de ("Carpeta") "Folder" actualmente seleccionado.

Los detalles de importar proyecto se discuten en Utilizar el asistente de Nuevos Proyectos.

Soporte de Rama y Etiqueta

El nodo ("Ramas") "Branches" permite crear, explorar, verificar y borrar ramas locales y remotas. El nodo de ("Etiquetas") "Tags" permite explorar y verificar etiquetas. Ambos nodos "Ramas" y "Etiquetas" permiten mezclar la rama o la etiqueta en la rama actualmente verificada y también sincronizarse con la rama actualmente verificada.

Para mejor lectura, las ramas se organizan en dos sub-nodos para ramas locales y remotas respectivamente y solamete se muestran los nombres abreviados, p. ej. en vez de "refs/heads/master" encontrará una entrada "master" bajo el nodo ("Ramas Locales") "Local Branches", en vez de "refs/remotes/origin/master" se muestra el nombre abreviado "origin/master" bajo el nodo ("Ramas Remotas") "Remote Branches". Similarmente, los nombres de etiquetas se abrevian omitiendo el prefijo "refs/tags/":

Verificar Ramas y etiquetas

Las Ramas y Etiquetas se pueden verificar bien con un doble clic en el nodo respecivo o bien seleccionando la entrada del menú de contexto correspondiente.

Creación y Borrado de Ramas

Se puede crear Ramas locales utilizando el Diálogo de Creación de Rama. Se abre el asistente con un doble clic en las "Ramas", "Ramas Locales" o en cualquier nodo "Rama"o "Etiqueta").

El Borrado de Ramas se hace utilizando la entrada del menú de contexto correspondiente.

Refundar

Puedes desencadenar la refundación de la rama actualmente verificada sobre otra rama haciendo clic derecho (Refundar) Rebase en cualquier nodo rama (local o de seguimiento remoto).

Mezclar una rama o Etiqueta

Usted puede desencadenar una mezcla desde cualquier rama y nodo de etiqueta y desde el nodo de repositorio si ha verificado una rama local. Véase Mezclar para más detalles de las características de mezcla.

• Cuando seleccione cualquier nodo de rama que no sea la rama actualmente verificada o cualquier nodo de etiqueta, utilice Mezcla para desencadenar directamente una mezcla sobre la rama actualmente verificada.

• Cuando seleccione el nodo de rempositorio o la rama actualmente verificada, utilice (Mezcla...) Merge... para abrir el diálogo de mezcla. El diálogo de mezcla se describe en Mezclar una rama o etiqueta en la rama actual.

Sincronizar con una Rama o Etiqueta

Puede ejecutar una comparación de cambios en su HEAD con los cambios hecho en cualquier otra Rama o etiqueta. Haga clic derecho y seleccione (Sincronizar...) Synchronize... en cualquier rama o etiqueta. Entonces la vista de sincronización de eclipse se abre, la cual contiene una representación de los cambios que están contenidos en su HEAD pero no en la otra rama o etiqueta (cambio saliente) o viceversa( cambio entrante). Por favor refiérase a la documentación de la característica de sincronización para más detalles.

Determinar la Rama Verificada

Hay dos modos de determinar cuál rama o etiqueta está actualmente verificada: el nodo de la rama/etiqueta verificada está decorada con una marca y la entrada "HEAD" bajo el nodo ("Referencias simbólicas") "Symbolic References" muestra el nombre completo de la rama verificada.

Resetear a una Rama o Etiqueta

Haga clic derecho y seleccione (Resetear...) Reset... en cualquier rama o etiqueta. Esto abre un diálogo que le permite a usted decidir acerca del tipo de reseteo. Véase Resetear su HEAD actual para más detalles.

HEAD Suelta o "Detached" HEAD

Si la HEAD está ("suelta") "detached", p. ej. no está apuntando al extremo de una rama local sino a una acometida o etiqueta, entonces ninguna o varios marcadores de ("verificado") "checked-out" pueden aparecer en el árbol, puesto que cualquier número de ramas remotas o etiquetas pueden apuntar a la acometida actualmente verificada. El estado en el que usted está mientras la HEAD está suelta no se registra por ninguna otra rama (lo cual es natural --- no estás en ninguna rama).

Inspeccionar Referencias

El nodo de Referencias muestra algunas referencias que no son las ramas y etiquetas (la lista es dinámica y depende del estado actual del Repositorios):

Si la Referencia es simbólica, p. ej. apunta a otra Referencia, se muestra el nombre de la referencia objetivo, seguida del ID de objeto de la referencia objetivo. Si la Referencia no es simbólica, solamente se muestra el ID del objeto.

En el ejemplo superior, HEAD es una referencia simbólica apuntando a la rama "refs/heads/master" (p. ej. la rama "master" está verificada", mientras que FETCH_HEAD apunta directamente a la acometida 226a7f... .

Las siguientes acciones están disponibles haciendo clic derecho en una Referencia: ('Verificar) Checkout (salvo que la Referencia esté ya verificada) y (Crear Rama) Create Branch'... .

Explorar el Directorio de Trabajo

El nodo "Directorio de Trabajo" visualiza la estructura del sistema local de archivos del Repositorio Git. También es posible abrir un editor de texto en los archivos:

Alternativamente, se pueden abrir ficheros al arrastrarlos desde el directorio de trabajo al Área de Editor.

También, en todos los nodos de archivos y carpetas así como en el nodo "repositorio", se ofrece una opción para copiar la ruta (específica del sistema de archivos) al portapapeles. Esto algunas veces es útil cuando la ruta hace falta, por ejemplo para abrir un directorio utilizando un navegador de archivos o para copiar y pegar Repositorios entre instancias de vistas (véase arriba acerca de como añadir Repositorios a la vista). La acción Copiar al portapapeles está también disponible utilizando Editar > Copiar (Edit > Copy) (o la abreviación correspondiente de teclado).

Configuración de Repositorio

La integración con la vista genérica de "Propiedades" en Eclipse permite ver y editar la Configuración Git (global y propia del repositorio). Si la vista de "Propiedades" está abierta, se actualiza automáticamente cuando un nodo de "Repositorio" se selecciona. Con una caja de despliegue (caja roja en la captura de pantalla) puedes cambiar entre mostrar la Configuración de Repositorio, la Configuración Global y una vista que agregue a ambos. Si la vista muestra la Configuración de Repositorio o la Configuración Global usted puede abrir un diálogo de editor con el botón Editar (caja roja derecha en la captura de pantalla). El diálogo de editor tiene la misma funcionalidad que en la página de preferencia Equipo > Git > Configuración (Team > Git > Configuration).

En la vista de Repositorios Git, hay una acción Propiedades en el menú de contexto, la cual abrirá un diálogo de configuración permitiendo editar la Configuración de Repositorio. Aquí, se puede añadir pares clave valor, cambiarlas o eliminarlas. El botón Abrir permite abrir el archivo de configuración de repositorio en un editor de texto.

Repositorios Remotos

El nodo "Remotos" permite explorar y editar configuraciones Remotas. Cada configuración remota tiene un nombre y una (Especificación de Empuje) Push Specification, una (Especificación de Extracción) Fetch, o ambas. Si un nodo de ("Configuración Remota") "Remote Configuration" o cualquiera de sus hijios es seleccionado, la vista Propiedades mostrará un resumen de la configuración Remota. En este ejemplo: hay una configuración remota denominada "origin" la cual sólo tiene una Especificación de Extracción, pero no Especificación de Empuje:

Las acciones de menú se proveen para añadir, configurar, y eliminar configuraciones remotas y especificaciones de extracción y empuje.

Soporte de Extracción y Empuje Directo

Se puede ejecutar directamente extracción y empuje (p. ej. sin asistentes) sobre un nodo remoto también como en los respectivos nodos de ("Extracción") "Fetch" y ("Empuje") "Push":

Note que la operación de extracción o empuje sera inmediatamente ejecutada en una taréa asíncrona; al acabar obtendrá un popup de confirmación mostrando el resultado obtenido.

El nodo ("Extracción") "Fetch" contiene la llamada especificación de extracción y el nodo de ("Empuje") "Push" contiene la llamada especificación de empuje.

Una especificación de extracción por defecto se crea cuando se clona el repositorios. Usted puede editar la especificación de extracción con la entrada del menú (Configurar Extracción...) Configure Fetch.... Esto abre un asistente. En la primera página puede editar la URI de Extracción o Fetch. En la segunda página puede determinar las especificaciones de extracción de ref, véase Especificciones de extracción de Ref.

Puede crear o editar una especificación de empuje con la entrada de menú (Configurar Empuje...) Configure Push.... Esto abre un asistente. En la primera página puede editar la URI de Empuje o Push. Si se especifica una extracción la URI de extracción o fetch se incluye automáticamente en la especificación de empuje y no se necesita una URI de Empuje adicional. En las segunda pñagina puede determinar las especificaciones de empuje ref, véase Especificaciones de Empuje de Ref.

Añadir una Configuración Remota

Esto se hace utilizando una acción del menú de contexto en el nodo "Remotos". Se inicia un asistente pregintando por la nueva configuración y si configurar Extracción, Empuje o ambas:

Si se seleccionó la casilla de "Configurar Extracción, la siguiente página del asistente le pedirá la URI del Repositorio del cual extraer:

Pinche ( Cambiar...) Change... para abrir un diálogo que le permita seleccionar una URI. El siguiente paso es definir la Especificación Remota para la URI de extracción. Véase Esoecificaciones de Ref de Extracción para saber más de los detalles.

Si se seleccionó la casilla de "Configurar Empuje, la siguiente página del asistente le pedirá la URI del Repositorio al cual empujar. Esto es realmente una lista, ya que usted puede empujar a múltiples repositorios al tiempo. Pinche (Añadir...) Add.... para añadir URIs a la lista utilizando el mismo diálogo que arriba. Puede eliminar URIs marcandolas en la lista y pinchando en (Eliminar) Remove. Este paso es completamente opcional si ya se ha definido una URI de (Extracción) Fetch. En este caso, la URI de Extracción también puede usarse para empujar. Si al menos una URI de empuje está definida durante estos pasos, anulará la URI de extracción. En este ejemplo, hay ya una URI de extracción, tal que el botón (Siguiente) Next está activado, incluso aunque no haya URI de empuje en la lista:

El siguiente paso es definir la Especificación Remota para las URIs de empuje. Véase Especificaciones de Ref de Empuej para más detalles.

Al acabar, la nueva configuración Remota sera visible:

Cambiar Configuraciones Remotas

También es posible añadir, eliminar o cambiar especificaciones de extracción/empuje para una Configuración Remota existente utilizando el menú de contexto.

Configuración de Gerrit

Si trabaja con Gerrit Code Review como servidor de repositorios remoto usted puede

• Especificar la configuración de empuje utilizada para empujar cambios a la revisión de código
• Especificar la configuración de extracción para extraer las notas de revisión desde Gerrit
• Configurar su repositorio para seleccionar la opción (Computar el Change-Id para la Revision de código Gerrit) Compute Change-Id for Gerrit Code Reviewen el diálogo de acometida por defecto

Seleccione (Configuración de Gerrit...) Gerrit Configuration... del menú de contexto de un Remoto. Esto abre un asistente con una página:

• Cuando pinches en (Finalizar) Finish el asistente establece el parámetro de configuración de repositorio gerrit.createchangeid a true. Esto asegura que la casilla (Calcular Change-id para la revision de código Gerrit) Compute Change-Id for Gerrit Code Review del diálogo de acometida se selecciona por defecto. Véase Mensaje de acometida para más detalles.

• Si quiere configurar la inserción automática de Change-Id en otro momento puede utilizar el editor de configuración del repositorio (Preferencias > Equipo >Git > Configuración) para establecer el parámetro de configuración gerrit.createchangeid a cierto. Si quiere esta configuraciión para todos sus repositorios puede ponerla en ~/.gitconfig entonces no necesitará repetir esta configuración para cada nuevo repositorio en el que usted esté trabajando.

Además al asistente añade una refspec "refs/notes/*:refs/notes/*" a su especificación de extracción. Gerrit almacena datos acerca de la revisión en notas de git. Con esta refspec estas revisiones de datos se extraerán automáticamente cuando extraiga desde este remoto y se mostrarán en el visor de acometidas.

• En la sección (URI de Empuje) Push URI usted puede configurar la URI que se usa para la configuración de empuje por defecto. Se prerellena dependiendo de la URI desde la que esté usted clonando. Si usted clona con el protocolo git, tel protocolo se cambia automáticamente a ssh, y se añade el puerto 29418 del ssh por defecto de Gerrit. Para protocolos que requieran un usuario hay un campo de usiario por conveniencia.

• La sección (Configuración de Empuje) Push Configuration tiene un campo, (Rama destino) Destination Branch. Aquí usted debería introducir el nombre de la rama objetivo donde se enviarán los cambios aceptados en el flujo de trabajo de revisión de código de Gerrit. Esto arrojará una entrada HEAD:refs/for/<nombrerama> en la configuración de empuje del remoto que especificó en el asistente de clonado.

• los Repositorios que se hayan configurado para Gerrit se mostrarán con el decorador verde de Gerrit

Refrescar

La vista se auto-refresca periodicamente. El botón Refrescar oRefresh de la barra de herramientas permite desencadenar un refresco inmediato:

Enlace con la Selección

Si el conmutador (Enlace con la selección) Link with selection está activo, el archivo o carpeta correspondiente a la selección del espacio de trabajo se mostrará automáticamente:

Enlace con el Editor

Si el conmutador (Enlazar con el editor) Link with editor está activo, el archivo o carpeta correspondiente al editor activo se mostrará automáticamente:

Disposición de Rama Jerárquica

Si el conmutador de (Disposición Jerárquica de Rama) Hierarchical Branch Layout está activo, se mostrarán las ramas en disposición jerárquica utilizando la barra (/) como separador jerarquico:

Esto puede ser de utilidad para organizar grandes cantidades de ramas.

Repositorios desnudos o Bare

Los Repositorios Git ("Desnudos") "Bare" (en oposición a los de "desarrollo" o "estándar") no tienen directorio de trabajo por definición, así que todas las acciones relacionadas con el directorio de trabajo (verificar, importar proyecto, explorar el directorio de trabajo) no están disponibles para tales Repositorios. La ("Desnudez") "Bare-ness" de un Repositorios se visualiza en el nodo "Directorio de trabajo", el cual siempre es una hoja:

Los repositorios Desnudos sólo cambian empujando cambios en ellos.

Eliminar Repositorios desde la vista de Repositorios Git

Esto se ofrece como una acción de menú en el nodo "Repositorio". Note que esto no borra el Repositorios, sino justo elimina el nodo de la vista. Si hay proyectos en el espaciode trabajo que se localizan en el directorio de trabajo del repositorio, se el preguntará al usuarui que confirmeel borrado de estos proyectos desde el espacio de trabajo de Eclipse.

Mostrar Repositorio en Vistas Relacionadas

Mostrar en Historia

El comando Mostrar en > Historial ('Show in > History) abrirá la Vista de Historia que muestra todos los cambios en el repositorio seleccionado.

Mostrar en Reflog

El comando Mostrar en > Reflog mostrará la Vista de Reflog de Git que muestra el reflog de Git del repositorio seleccionado.

Mostrar en Propiedades

El comando Mostrar en > Propiedades abrirá la Vista de Propiedades que muestra las propiedades del repositorio seleccionado.

Trabajar con Tareas

Desde EGit 0.11 está disponible una primera integración con Mylyn para soportar trabajar con repositorios de tareas.

Instalación

Necesita instalar la característica "EGit Mylyn" para utilizar la integración Mylyn de EGit. Esto requiere instalar Mylyn.

Plantilla de Mensaje de Acometida

• Configure la plantilla de acometida de Mylyn bajo Preferencias > Tareas > Equipo (Preferences > Tasks > Team) y edite Plantilla de comentario de acometida (Commit Comment Template).
• Utilice las siguientes variables así como cualquier texto para alterar el mensaje de acometida.
  • connector.task.prefix, repository.kind, repository.url, task.assignee, task.cc, task.description, task.id, task.key, task.keywords, task.lastmodified, task.notes, task.priority, task.product, task.reporter, task.resolution, task.status, task.summary, task.type, task.url, task.completiondate, task.creationdate, task.reminderdate

• Antes de acometer su cambio active la tarea correspondiente utilizando la IU de Mylyn.

• Cuando se lanza, el diálogo de acometida de EGit repoblará el mensaje de acometida utilizando la plantilla de mensaje de acometida.

Véase la Guía de Usuario de Mylyn para más información sobre como trabajar con tareas.

Ver Acometidas

El visor de acometidas de Egit permite que las acometidas se abran en el área de editor de Eclipse.

El visor de acometidas de EGit muestra la siguiente información de acometida:

• Pestaña de Acometida
  • Enlaces a acometidas padres abiertas
  • Autor
  • Acometedor
  • Mensaje
  • Lista de etiquetas apuntando a esta acometida
  • Lista de ramas en las que existe esta acometida

• Pestaña de Diff
  • Visor de texto con la salida de las diferencias entre archivos
  • Los colores utilizados en el visor se pueden configurar desde la carpeta (Preferencias > Apariencia > Ccolores y fuentes > Git) Preferences > General > Appearance > Colors and Fonts > Git

• Pastaña de Notas
  • Todas las notas de Git para la acometida

Etiquetar una acometida

• Seleccione el icono Crear Etiqueta desde la barra de herramientas del visor de acometidas
  • El diálogo de Etiqueta se abrirá permitiéndole a usted crear la etiqueta desde la acometida.

Crear una rama desde una acometida

• Seleccione el icono Crear Rama desde la barra de herramientas del visor de acometidas.
  • El diálogo de Rama se abrirá permitiéndole a usted crear una nueva rama para la acometida

Verificar una acometida

Esto verifica la acometida mostrada en el visor de acometidas. La acometida será verificada y HEAD será desenlazada.

Elegir selectivamente una acometida

Aplica el cambio introducido por la acometida mostrada en el visor de acometida cobre la rama o acometida actualmente verificada.

Abrir el visor de acometida

El visor de acometida puede abrirse desde los siguientes lugares:

• Menú de contexto de la tabla de vista de Historia
• Haciendo doble clic en acometidas en la tabla de resultados del diálogo de empuje/extracción
• Diálogo de Abrir Acometida
• Popup de anotaciones de culpa
• Vista Reflog

Buscar Acometidas

EGit soporta buscar acometidas.

Página de búsqueda de Git

Las acometidas pueden buscarse desde la pestaña Git Search en el diálogo estándar de búsqueda de Eclipse.

Este diálogo soporta buscar texto o patrones presentes en diferentes campos de una acometida de Git tales como Mensaje, línea de autor, línea de acometedor, y los ids SHA-1 de la acometida, sus padres, y el árbol asociado con ella.

Explorar Resultados de Búsqueda

Los resultados de la búsqueda de acometidas se mostrarán en la vista estándar de búsqueda de eclipse. Los resultados se agrupan por repositorio cuando esté en modo Árbol. Haciendo doble clic en una acometida desde la vista de búsqueda se abrirá en el visor de acometida.

Lanzar Búsqueda de Git

La página de búsqueda de Git puede abrirse seleccionando la opción búsqueda de Git o Git Search desde el desplegable Búsqueda o Search en la barra de herramientas de Eclipse.

Abrir Diálogo de Acometida

EGit tiene un diálogo de (Abrir Acomentida de Git) Open Git Commit similar a los diálogos de Mylyn (Abrir Tarea) Open Task y la nuclear (Abrir Recurso) Open Resource. El diálogo busca cada repositorio Git configurado para la rama, etiqueta o SHA-1 de acometida introducidas en la caja de filtrado y muestra las acometidas coincidentes.

El diálogo puede ser abierto seleccionando el botón (Abrir Acometida de Git) Open Git Commit en la barra de herramientas de navegación de Eclipse.

Encontrar al autor de cada línea en un archivo

EGit soporta mostrar información (culpable git) git blame dentro de la regla del editor.

Seleccionar la acción Team > Show Annotations en las selecciones de archivo abrirá el editor y mostrará una regla de anotación con información sobre la acometida y su autor por cada línea de un archivo. Pasando el raton por encima de la regla mostrará un pop-up con la id de acometida, autor, acometedor, mensaje de acometida y el diff aplicado por esta acometida en el bloque seleccionado.

El aspecto y sensación de la anotacionde culpa de la regla del editor se puede configurar desde el submenú (Revisiones) Revisions disponible desde el menú de contexto de la regla.

Pinche (abrir acometida) open commit Para abrir la acometida en el visor de acometida, pinche (mostrar en historia) show in history para mostrar la acometida en la Vista de Historia. Pinche (mostrar anotaciones) show annotations para mostrar anotaciones de la acometida padre de la acometida mostrada en ese sobrevuelo.

Trabajar con submódulos

Puede leer más acerca de que son los submódulos de Git y como funcionan en este capítulo del libro de Comunidad Git.

Clonar Repositorios con Submódulos

Los submódulos son repositorios embebidos dentro de un repositorio padre. Por lo tanto al hacer un clon de un repositorio padre es necesario clonar los repositorios de submódulo tal que los archivos/carpetas esté disponibles en el directorio de trabajo del repositorio padre.

Pinchar el botón ("clonar submódulos") Clone Submodules desde el asistente (Clon de Git) Git Clone clonará todos los repositorios de submódulo tras acabar de clonar el repositorio padre.

Explorar Submódulos

Hay un nodo de "Submódulos" mostrado en la vista Repositorios de Git para repositorios que contengan submódulos.

Todos los submódulos en el repositorio padre dado se muestran bajo este nodo tanto como la información acerca de que acometida está actualmente verificada.

Añadir un Submódulo

Puede añadir un submódulo a un repositorio seleccionando un repositorio en la vista ( Repositorios de Git) Git Repositories y seleccionando la opción de menú de contexto (Añadir Submódulo) Add Submodule.

El asistente preguntará la ruta y la URL del submódulo que se añade. La ruta introducida será relativa al directorio de trabajo del repositorio padre y la URL será utilizada para clonar el repositorio localmente.

Una vez que el asistente se complete el submódulo sera clonado, añadido al índice, y el submódulo se registrará en el archivo .gitmodules así como en el archivo del repositorio padre .git/config.

Actualizar Submódulos

Hay dos acciones que pueden utilizarse para actualizar submódulos, (Actualizar submódulos) Update Submodule y (Sincr. Submódulo) Sync Submodule.

Seleccionar la acción de actualizar submódulo Update Submodule en un submódulo verificará la acometida referenciada en el índice del repositorio padre de ese submódulo. Este comando también realizará una mezcla o refundará si se ha sido configurado en el campo (actualizar) update para la sección de configuración del submódulo seleccionado en el archivo .git/config del repositorio padre.

Seleccionar la acción (Sincronizar submódulo) Sync Submodule actualizará la URL remota utilizada por el submódulo desde el valor actual del archivo .gitmodules en la raíz del directorio de trabajo del repositorio padre.

Conjuntos de Proyecto de Equipo

Los conjuntos de proyectos de equipo (archivos .psf) están soportados por el proveedor de equipo de Git.

Importar

Para importar un conjunto de proyecto existente, utilice el asistente (Importar...) Import... y entonces seleccione (Conjunto de Proyecto de Equipo) Team Project Set desde (Equipo) Team.

Puede seleccionar un archivo que contenga las definiciones de importación y opcionalmente elegir añadir los proyectos importados al conjunto de trabajo.

En el próximo paso, los repositorios se clonan, los proyectos se importan y se conectan. Esto puede llevar un tiempo dependiendo del tamaño de los repositorios.

Exportar

Para crear un archivo de conjunto de proyecto para los proyectos Git existentes, seleccione los proyectos/conjuntos de trabajo que ya estén conectados al proveedor de equipo de Git.

Entonces abra el asistente (Exportar...) Export... y seleccione (Conjunto de Proyecto de Equipo) Team Project Set del (Equipo) Team. Ahí puede escoger exportar conjuntos de trabajo o solo proyectos y puede refinar su selección. En el próximo paso, seleccione una ruta de salida y termine el asistente.

Formatear

Puede editar manualmente un archivo .psf. Cada proyecto tiene una entrada que se parece a ésta:

<project reference="1.0,git://egit.eclipse.org/egit.git,master,org.eclipse.egit"/>

Los Valores están separados por comas y tienen el siguiente significado:

1. Versión de formato
2. URL del repositorio Git
3. Nombre de la rama a verificar inicialmente
4. Ruta al proyecto a importar (carpeta que contenga .project), relativa al repositorio

Cada proyecto tiene una entrada. Así que para múltipes proyectos en el mismo repositorio, cree tal entrada para cada proyecto con la misma URL de repositorio. La importación es suficientemente inteligente para sólo clonar cada repositorio una sola vez.

Si el repositorio contiene un prouecto en la raíz, utilice . como ruta del proyecto.

Referencia

Menús

Menú de Contexto de Proyecto

En los nodos de proyecto de las vistas de navegación (Navegador, Explorador de Paquete etc.) están disponibles las siguientes acciones Git para los proyectos compartidos con el proveedor de equipo de Git:

(menú principal del proyecto) main project menu

(Submenú "Remoto") "Remote" sub-menu

(Submenú "Cambiar a") "Switch To" sub-menu

(Submenú "Avanzado") "Advanced" sub-menu

Menú de contexto de Recurso

En los nodos de recurso (archivos y carpetas) de las vistas de navegación se dispone de las siguientes acciones Git para proyectos compartidos con el proveedor de equipo de Git:

Menús de Vista de Repositorios

En la Vista de Repositorios el menú depende del tipo de nodo que se selecciona:

Menú en los nodos de repositorio:

Menú en los nodos de rama:

Menú en los nodos de etiqueta:

Menú en los nodos de Referencia:

Menú en los nodos Remoto:

Menú en los nodos Configuración de Extracción) Fetch Configuration:

Menú en los nodos de (Configuración de Empuje) Push Configuration:

Menú en los nodos de Árbol de trabajo o Working Tree:

Menús de Vista de Historia

Menú en entradas de la lista de acometidas de la Vista de Historia

Entradas de menú del submenú Quickdiff de la Vista de Historia

Barra de herramientas de espacio de trabajo de Git y Menú de espacio de trabajo de Git

Para facilitar el uso de las acciones más frecuentemente utilizadas el Grupo de Órdenes de Git (Git Command Group) puede ser activada para mostrar una barra de herramientas y/o un menú del Menú de espacio de trabajo de Git

• Pinche Ventana > Personalizar perspectiva... (Window > Customize perspective...)
• En la pestaña Disponibilidad de Grupos de Órdenes (Command Groups Availability) pinche Git, esto activará tanto el menú como la barra de herramientas
• En las pestañas Visibilidad de Barra de Herramientas (Toolbar Visibility) y Visibilidad de Menú (Menu Visibility) puede configurar que acciones deberían aparecer en ese menú y barra de herramientas

Acciones de Menú

• (Añadir) Add
  • Añadir los cambios presentes en el árbol de trabajo al índice de Git, también conocido como preparar cambios.
  • Ponga los recursos recién creados bajo el control de versiones de Git (Git no comienza a seguir recursos automáticamente).
  • (Resolver conflictos) Resolve conflicts.
• (Aplicar parche) Apply Patch - Aplicar un parche.
• (Asumir invariable) Assume unchanged - Los recursos se pueden marcar como "asumir sin cambios". Esto significa que el Git para de comprobar el árbol de trabajo buscando modificaciones, así que necesitas desmarcar manualmente el bit para contarle a Git cuándo cambia el árbol de trabajo. Esta configuración puede ser encendida con la acción del menú Equipo > Asumir inalterado (Team > Assume unchanged) y apagada con la acción de menú Equipo > No asumir inalterado (Team > No Assume unchanged).
• Ramificar, Crear Rama - Verificar una rama o crear un rama.
• Cambiar credenciales (Change Credentials) - Cambia las credenciales de logon de una especificación de Extracción o Empuje, las credenciales se almacenan por URL en el Almacén seguro de Eclipse.
• Verificar (Checkout) - Verificar una Rama, Etiqueta, Acometida o Referencia.
• (Escoger) Cherry-pick - Elección selectiva de una acometida suelta sobre la rama actualmente verificada.
• Limpiar credenciales (Clear Credentials) - Limpia las credenciales de una especificación de Extracción o Empuje, las credenciales se almacenan por URL en el Almacén seguro de Eclipse.
• (Acometer) Commit - Acometer cambios.
• Eliminar Extracción (Delete Fetch) - Eliminar una especificación de extracción.
• Eliminar Empuje (Delete Push) - Eliminar una especificación de Empuje.
• (Configurar extracción) Configure Fetch - Configurar una Especificación de Extracción.
• (Configurar Empuje) Configure Push - Configurar una Especificación de Empuje.
• (Eliminar Rama) Delete Branch - Eliminar una rama.
• (Eliminar Repositorio) Delete Repository - Eliminar un repositorio.
• (Desconectar) Disconnect - Desconectar el Proveedor de Equipo de Git de este proyecto. El repositorio de git aún existe pero ya no se integra con Eclipse.
• (Ignorar) Ignore - Añadir archivos a .gitignore tal que git los ignore.
• Import Projects - Importar proyectos al espacio de trabajo de Eclipse.
• (Mezcla) Merge - Mezclar ramas.
• (Herramienta de Mezcla) Merge Tool - Resolver conflictos usando la Herramienta de Mezcla o Merge Tool.
• (Abrir Vista de Propiedades) Open Properties Vview - Ver y editar la configuración del repositorio.
• (Arrastrar) Pull - Arrastrar cambios desde la rama remota seguida por la rama local actualmente verificada.
• Remoto >(Extraer desde) Fetch From - Extraer cambios desde un repositorio remoto
• Remoto > (Extraer desde Gerrit) Fetch from Gerrit - Extraer cambios desde un servidor de Revisión de Código Gerrit
• Remoto > (Empujar) Push - Empujar cambios a otros repositorios
  
• Remoto > (Configurar Extraer desde Flujoarriba) Configure Fetch from Upstream - Configurar flujoarriba para extracción automática
• Remoto > (Configurar Empujar a Flujoarriba) Configure Push to Upstream - Configurar flujoarriba para empuje automatizado
  
• (Refundar) Rebase - Refundar una rama sobre otra.
• (Eliminar Repositorio) Remove Repository - Eliminar un repositorio de la Vista de Repositorios.
• (Renombrar Rama) Rename Branch - Renombrar una rama.
• Resetear - Resetear la HEAD, Índice o Árbol de Trabajo actuales.
• (Ver en Historia) Show in History - Mostrar el recurso seleccionado en la Vista de Historia.
• (Mostrar en vista de Repositorios) Show in Repositories View - muestra el recurso seleccionado en la Vista de Repositorios.
• (Cambiar a...) Switch to... - Cambia a otra rama o etiqueta (también conocido como verificar o checkout).
• (Sincronizar) Synchronize - Sincroniza las ramas local y remota una con otra.
• (Etiquetar) Tag - Crear, borrar etiquetas.
• Untrack - Elimina recursos del control de versiones Git. Si quiere eliminar el recurso del árbol de trabajo pinche también (Eliminar) Delete en el menú de contexto de recurso.

Perspectiva y Vistas de Git

Perspectiva de Git

Window > Open Perspective > Git Repository Exploring abre la perspectiva de Explorador de Repositorios Git

Vista de Repositorios Git

Window > Open View > Git > Git Repositories abre la vista de Repositorios Git la cual está explicada al detalle aquí.

Vista de Historia

Visión de conjunto

La Vista de Historia para Recursos bajo el control de versiones Git es una vista de los recursos de un Repositorio dado centrada en acometidas. Se puede utilizar para realizar las siguientes tareas:

• Inspeccionar la historia de cambios de un archivo dado bajo control de versiones de Git (ver y comparar las versiones de tal archivo en el repositorio)
• Buscar una cierta acometida utilizando diferentes criterios de búsqueda
• Verificar una acometida dada
• Creación de ramas y etiquetas basadas en una acometida dada
• Creación de parches basados en los cambios de cierta acometida
• Resetear el repositorio completo a cierta acometida
• Establecer y resetear la línea base de quickdiff a cierta acometida

Abrir la Vista de Historia

La vista de Historia puede ser abierta al

• hacer clic derecho Mostrar en > Vista de Historia (Show In > History View) en cualquier recurso bajo el control de versiones de Git en el explorador (no disponible en todas las Perspectiva)
• hacer clic derecho Equipo > Mostrar en Historia (Team > Show in History) en cualquier recurso bajo el control de versiones de Git en el explorador
• Pinchar ventana > Mostrar Vista > Otros... (Window > Show View > Other...), entonces Equipo > Historia (Team > History)

Una vez que la Vista se abra , puede activar el botón Enlazar con Selección (Link with Selection) para mantener la entrada de la vista en sincronía con la selección del explorador automáticamente.

Organización de la Vista de Historia

La Vista de Historia se organiza en varios paneles:

El panel superior es la Gráfica de la Acometida que muestra el log de acometida (o historia de Acometida) en orden cronológico inverso (acometida más reciente arriba). Bajo el gráfica de acometida, hay dos paneles: en la izquierda , el área de Comentarios de Revisión, el cual muestra el mensaje de acometida y in Diff textual de el/los archivos de la acometida, y en la parte derecha, el área de Detalles de Revisión, el cual muestra una tabla de archivos que fueron cambiados por la acometida.

La primera columna de esta tabla describe la naturaleza del cambio por cada archivo:

ADD  el archivo fue añadido por la acometida

MODIFY  el archivo fue modificado por la acometida

DELETE  el archivo fue eliminado por la acometida

El contenido de los paneles inferiores depende en la selección del panel superior y se actualiza automáticamente cuando esta selección cambia.

Ambos paneles inferiores pueden ser encendidos y apagados separadamente haciendo clic derecho en cualquier lugar del panel superior y seleccionando (Mostrar Comentario de Revisión) Show Revision Comment y (Mostrar detalles de Revisión) Show Revision Details, respectivamente.

Arriba en el gráfica de acometida, se visualiza la entrada actual. La entrada siempre es un recurso del espacio de trabajo, bien un proyecto, una carpeta o un archivo. Detrás del tipo de entrada, se muestra la ruta, seguida del nombre del Repositorio que contiene el recurso entre corchetes.

Utilizar la Vista de Historia

Inspeccionar Gráfica de Acometida

El área de la gráfica de acometida es la parte principal de la Vista de Historia. Por defecto, muestra la acometida actualmente verificada y sus ancestros, p. ej. la primera entrada de la lista es la acometida verificada. La siguiente imagen se usa para explicar ciertas características de la Vista de Historia:

Cada línea de la Gráfica de Acometida corresponde a una acometida. Ramas, etiquetas y HEAD se visualizan como sigue:

• Los extremos de las ramas locales se muestran como rectángulos verdes
• Los extremos de las ramas remotas se muestran como rectángulos grises
• La HEAD local se muestra como un rectángulo blanco
• Las etiquetas se muestran como rectángulos amarillos

(nuestro ejemplo no tiene ramas remotas).

La línea a la izquierda es la gráfica de la acometida actual, la cual muestra la relación paterno-filial de las acometidas de la lista (cada acometida tiene al menos un padre, excepto por la primera acometida del Repositorio). Puede haber bifurcaciones, las cuales corresponden con una operación de ramificación, y uniones, las cuales corresponden a una operación de mezcla. En nuestro ejemplo, había una rama "experimental" creada tras la acometida con la rama "beforeSplit", y el mismo archivo fue cambiado tanto en la "master" y en la rama "experimental". La última acometida es una acometida de mezcla donde el contenido de la rama "experimental" se mezcló con la rama "master".

El cambio exacto puede ser inspeccionado marcando una acometida mirando en el área de Comentarios de Revisión. Cuando desplace hacia abajo el área de Comentarios de Revisión, será visible un diff textual para los cambios, en nuestro ejemplo dice que el contenido de Project1/f1/file1.txt fue cambiado de "modified" a "modified in master". Al seleccionar la siguiente acometida (la cual corresponde con la rama "experimental"), se mostrará un diff similar, diciendo que el contenido de ese archivo se cambió de "modified" a "modified in experimental". La acometida más nueva es el resultado de mezclar "experimental" en la "master". Acordemente, la nueva acometida tiene dos ancestros y las líneas "master" y "experimental" se juntan otra vez.

Mostrar y Comparar versiones de un Archivo

Si la entrada actual está ya en una archivo, haciendo clic derecho (Abrir) Open sobre una acometida abrirá un editor con el contenido de archivo correspondiente a la acometida actualmente seleccionada. Si el archivo no existe en la acometida seleccionada, se mostrará un mensaje de error. Pinchando (Comparar con el árbol de trabajo) Compare with working tree abrirá un editor de comparación que compara el contenido del archivo de la acometida actualmente seleccionada con el contenido del archivo del espacio de trabajo.

Las acciones (Abrir) Open y (Comparar con árbol de trabajo) Compare with working tree también se pueden ejecutar haciendo doble clic en la acometida: si se presiona el botón de la barra de herramientas ("Modo Comparar") "Compare Mode" (véase abajo), se ejecutará (Comparar con árbol de trabajo) Compare with working tree, si no (Abrir) Open.

Es posible comparar los contenidos de dos acometidas filtradas por la entrada actual haciendo una selección de dos acometidas y dando clic derecho en (Comparar entre sí) Compare with each other. Si la entrada actual no es un archivo, hay una acción de menú adicional (Comparar entre sí en Árbol) Compare with each other in Tree. La primera acción abre un editor de comparación de Eclipse, la segunda abre la Vista de Comparación de Árbol de Git.

Más aún, es posible seleccionar cualquier número de acometidas y hacer clic derecho (Abrir) Open para ver todas las versiones del archivo correspondiente a las acometidas seleccionadas (se abrirá un editor por cada versión).

Si la entrada actual no es un archivo, entonces no habrá acciones de menú para (Abrir) Open. Sin embargo, es posible hacer doble clic en una entrada del área de Detalles de Revisión. Si se activa el modo comparar, se abrirá un editor de comparación mostrando los cambios para el archivo al que se hacia doble clic en la acometida actualmente seleccionada (p. ej. un diff del contenido del archivo de la acometida actualmente seleccionada contra el contenido del archivo del ancestro de esta acometida). Si no se activa el modo comparar, se muestra un editor con el contenido del archivo correspondiente a la acometida actualmente seleccionada.

Trabajar con los ajustes de Filtrado

Los ajustes de filtrado pueden ser cambiados utilizando las acciones correspondientes de la barra de tareas (véase abajo). Por defecto, el ajuste "Resource" está activo, p. ej. sólo serán mostradas aquellas acometidas que contengan cambios para la entrada actual. Si la entrada actual no es un archivo, se muestran todas las acometidas que contengan cambios para cualquier hijo de la entrada actual.

Si el ajuste de filtro es "Resource" y la entrada actual es un archivo, entonces la lista de acometidas contiene solo las acometidas que contengan cambios para ese archivo. Esto es útil cuando se analiza la historia de ese archivo. En algunos casos, sin embargo, es útil también ver otras acometidas las cuales no hayan cambiado el archivo actual. Por ejemplo, puede ser interesante ver si un cambio dado en el archivo sucedió antes o después de alguna otra acometida la cual no cambió por si misma aquel archivo. En nuestro ejemplo, podemos querer conocer si un cambio dado sucedió "antes" o "después" de una acometida etiquetada como "Project1". Cambiando el ajuste de filtrado desde "Resource" a "Repository", esto se hace fácilmente:

El comportamiento de los otros dos ajustes ("Carpeta" y "Proyecto") es similar en que incluyen respectivamente las acometidas que cambian cualquier recurso en la carpeta padre de la entrada actual o cualquier recurso en el proyecto de la entrada actual. En nuesto ejemplo arriba, si se usara el ajuste de filtro "Project", no habría sido mostrada la acometida "Add Project2 to Repository", si no cambia nada en el proyecto de la entrada actual (Project1/f1/file1.txt).

Alternativamente, para ver todos las otras acometidas pertenecientes a un proyecto específico, uno podría cambiar la vista de historia para ese proyecto. Sin embargo, las acciones de menú específicas de archivos no estarían disponibles.

Acciones de Barra de Herramientas

Los primeros cuatro botones de la barra de herramientas de la Vista de Historia son los botones estándar para Refrescar, Enlazar con la Selección, Enclavar e Historia de Navegación.

Encontrar

Si se presiona el botón "Find" de la barra de herramientas, se muestra una barra de búsqueda en la parte inferior de la vista la cual permite buscar acometidas en el log de acometidas. Dependiendo del ajuste en la lista desplegable de la barra de búsqueda se busca el título, comentario, autor, o acometedor de la acometida.

Las coincidencias de la búsqueda encontradas se remarcarán en negrita y los botones ("Siguiente") "Next" y ("Previo") "Previous" permiten saltar a la próxima acometida o a la anterior coincidentes con el criterio de búsqueda:

Configuración de Filtro

Los siquientes cuatro botones conmutadores de la barra de tareas de la vista controlan como las acometidas mostradas se filtran con respecto a la entrada actual:

Los botones están funcionando como botones radiales, p. ej. uno de los cuatro debe estar siempre presionado.

• Si se pulsa el botón ("Repositorio") "Repository", no se filtra el log de acometida y muestra todas las acometidas accesibles desde la rama actualmente verificada (o todas las acometidas, véase abajo acerca de la acción ("Todas las Ramas") "All Branches")

• Si se pulsa el botón ("Proyecto") "Project", se filtra el log de acometida para mostrar todas las acometidas que afecten a cualquiera de los recursos del proyecto que contenga la entrada actual.

• Si se pulsa el botón ("Carpeta") "Folder", se filtra el log de acometida para mostrar todas las acometidas que afecten a cualquiera de los recursos de la carpeta padre de la entrada actual.

• Si se presiona el botón "Recurso" ("Resource"), se filtra el log de acometidas para mostrar solamente las acometidas que afecten a la entrada actual, el ítem Mostrar > Seguir renombres (Show > Follow Renames) del menú de vista permite conmutar si los renombres del recurso seleccionado deberían ser seguidos por este filtro

Note que no todas las combinaciones de ajustes de filtro tienen sentido; por ejemplo, si la entrada actual es un proyecto, la opción "Project" es de hecho lo mismo que la opción "Resource".

Modo de Comparación

El botón siguiente es de nuevo un conmutador, que activa "Compare Mode". Si se presiona, ciertas acciones de doble clic (véase arriba) abrirán un editor de compara en vez de un editor normal.

Todas las Ramas

Este conmutador activa el modo ("Todas las Ramas") "All Branches". Por defecto sólo se muestran en el log de acometidas aquellas que pueden ser alcanzadas desde la acometida actualmente verificada, p. ej. el gráfico de acometidas acaba con la acometida actualmente verificada y las más recientes no se muestran. Si se presiona este botón, todas las acometidas serán mostradas en el log de acometidas. Esto se ilustra en la siguiente imagen de nuestro ejemplo. La rama "beforeSplit" está actualmente verificada; al activar el conmutador las nuevas ramas se harán visibles.

Acciones del Menú de Vista

Configurar la Vista

La mayoría de las acciones de la barra de herramientas están disponibles también en el Menú de Vista. Además, están disponibles los siguientes conmutadores:

y el submenú de Filtro permite configurar los ajustes de filtro

"Additional Refs" conmuta la visibilidad de ciertas Refs creadas durante acciones como extraer, refundar, mezclar, for ejemplo FETCH_HEAD, ORIGIN_HEAD... Esto puede ser útil para dejar más limpia la vista de historia.

("Historia de anotaciones") "Notes History" conmuta el mostrar la rama/ref de notas de revisión de Gerrit en la vista de Historia

("Seguir Renombres") "Follow Renames" conmuta si los renombre del recurso seleccionado deberían ser seguidos en la Vista de Historia, si se utiliza el filtro ("Recurso") "Resource". Esta preferencia también puede ser configurada en el asistente de preferencias (Preferencias > Equipo > Git > Historia > Seguir Renombres) Preferences > Team > Git > History > Follow Renames.

("Comentarios de Revisión") "Revision Comment" conmuta la visibilidad del ártea de comentarios de Revisión.

("Detalles de Revisión") "Revision Details" conmuta la visibilidad del área de Detalles de Revisión.

Si se marca "Relative Dates", se muestran las fechas de acometida como fechas relativas en vez de fechas absolutas.

("Direcciones de E-Mail") "E-mail Adresses" conmuta la muestra de correos de acometedores.

El submenú ("En Comentario de Revisión") "In Revision Comment" abre un submenú con algunos conmutadores más que gobiernan la apariencia del área de Comentarios de Revisión:

("Secuencia de Etiqueta") "Tag sequence" permite mostrar/ocultar un par de ĺíneas que indican la última etiqueta de la lista de ancestros de la acometida dada y la siguiente etiqueta de la lista de sucesores de la acometida dada, p. ej. las etiquetas predecesora/siguiente de la acometida dada.

Los conmutadores ("Plegar Comentarios") "Wrap Comments" y ("Rellenar párrafos") "Fill paragraphs" gobiernan el formateo dentro del área de Comentarios de Revisión.

("Detalles de Revisión") "Revision Details" y ("Comentarios de Revisión") "Revision Comments" están disponibles también haciendo clic derecho en cualquier sitio del área de Gráfico de Acometida.

("Secuencia de Etiqueta") "Tag sequence", ("Plegar Comentarios") "Wrap Comments" y ("Rellenar Párrafos") "Fill paragraphs" están también disponibles haciendo clic derecho en cualquier sitio del área de Revisión de Comentarios.

Acciones de Menú de Contexto

El menú de contexto en el área de Gráfica de Acometidas es ligeramente diferente, dependiendo de si el actual es un archivo o una carpeta/proyecto, respectivamente. Las siguientes entradas de menú siempre están disponibles:

si la entrada actual es un Archivo, hay algunas otras acciones disponibles; si se selecciona exactamente una acometida, hay tres opciones adicionales:

y si se seleccionan exactamente dos acometidas, el menú aparecerá así:

Si se seleccionan más de dos acometidas, solo estarán disponibles la acción ("Abrir") "Open" y el menú "Quickdiff".

Comparar con el árbol de trabajo

Esta acción está sólo disponible si la entrada actual es un fichero y se selecciona una sola acometida. Abrirá un editor de comparar que compare el contenido del archivo de la acometida seleccionada con el contenido del archivo del árbol de trabajo.

Comparar entre sí

Esta acción sólo está disponible si la entrada actual es un archivo y exactamente se seleccionan dos acometidas. Abrirá un editor de comparar que compare el contenido del archivo de las acometidas seleccionadas entre si.

Abrir

Esta acción está sólo disponible si la entrada actual es un archivo. Abrirá un editor por cada acometida seleccionada mostrando el contenido del archivo para cada acometida dada.

Verificar

Esto verifica la acometida actualmente seleccionada. Si existe una rama para esta acometida, la rama se verificará, si existe más de una rama para esta acometida, se mostrará un diálogo preguntando cual rama debería ser verificada. Si no existen ramas para la acometida, la acometida se verificará y la HEAD se convertirá en desenlazada.

Crear Rama...

Crea una rama en la acometida actualmente seleccionada. Se mostrará un diálogo preguntando por el nombre de la rama y si la rama recién creada debería verificarse.

Eliminar Rama

Esta acción será activada si existe una rama activada para la acometida actualmente seleccionada, la cual no está verificada. Si hay una única rama en esta acometida, la cual no está acometida, esta acción borrará esta rama inmediatamente. Si existen múltiples ramas como tales, se mostrará un diálogo preguntando cuales ramas deberían borrarse. Si las acometidas se hacen inalcanzables en ("Borrar Rama") "Delete Branch" se mostrará un diálogo de confirmación para prevenir la inaccesibilidad accidental de las acometidas.

Crear Etiqueta...

Crea una etiqueta rama en la acometida actualmente seleccionada. Se mostrará un diálogo preguntando por un nombre de etiqueta y un mensaje de etiqueta.

Crear Parche...

Esta acción no está disponible en la primera acometida del Repositorio. Creará un parche que contenga los cambios de la acometida actualmente seleccionada comparada con el predecesor de la acometida. Se mostrará un diálogo preguntando si el parche debería ser creado como archivo o en el portapapeles y si utilizar el formato de parche de Git o el formato de parche genérico.

Elección selectiva Cherry Pick

Aplica el cambio introducido por la acometida seleccionada encima de la acometida actualmente verificada.

Revertir Acometida

Revierte los cambios que introduce la acometida seleccionada creando una nueva acometida sobre la acometida actualmente verificada.

Mezclar

Mezcla la acometida seleccionada en la rama actualmente verificada.

Refundar sobre

Refunda la rama actualmente verificada sobre la acometida seleccionada.

Resetear > Soft/Mixed/Hard

Esta acción resetea el Repositorio que contenga la entrada actual a la acometida actualmente seleccionada. Dependiendo de la elección del submenít, se realizará un reseteo blando (soft), mixto (mixed), o duro (hard).

Quickdiff > Resetear la línea base Quickdiff al primer padre de HEAD

Estas dos acciones establecen a HEAD o al padre de HEAD la línea base de quickdiff para el repositorio. Estas acciones están siempre disponibles, incluso si se selecciona más de una acometida.

Quickdiff > Establecer como Linea base

Esta acción está sólo disponible si se selecciona una única acometida; establecerá la linea base quickdiff para el repositorio a la acometida seleccionada.

Copiar

Copia los IDs de la/las acometidas seleccionadas en el portapapeles.

Mostrar Comentarios de Revisión

Conmuta la visibilidad del área de Comentarios de Revisión.

Mostrar Detalles de Revisión

Conmuta la visibilidad del área de Detalles de Revisión.

Plegar Comentarios

Solamente disponible cuando se hace clic derecho en el área de Comentarios de Revisión. Si activo, los comentarios se autoplegarán para rellenar el área mostrada, de otro modo se utilizará el plegado del mensaje de acometida.

Rellenar Párrafos

Solamente disponible cuando se hace clic derecho en el área de Comentarios de Revisión. Si activo, se mostrará el mensaje de acometida sin saltos de ĺinea innecesarios.

Soporte de Arrastrar y Soltar

Puede arrastrar y soltar acometidas desde el gráfico de acometidas bien sobre una Tarea Mylyn o en una carpeta de su disco duro. En ambos casos, EGit creará automáticamente un parche que pueda usted adjuntar a un error o almacenar en disco.

Trabajar con el Área de Detalles de Revisión

El Área de Detalles de Revisión muestra una tabla de archivos que fueron cambiados por la acometida seleccionada. Seleccionar la acción (Mostrar Anotaciones) Show Annotations del menú de contexto en los archivos seleccionados abrirá el archivo en un editor (de solo lectura) y mostrará una regla de anotación con información de acometida y autor para cada línea del archivo. Véase esta sección.

Vista de Sincronizar

Este menú de comando Team > Synchronize Workspace lanzará la Vista de Sincronizar. Esta vista le permite inspeccionar las diferencias entre recursos del espacio de trabajo local y una rama local o de seguimiento remoto. Alternativamente puede comparar una rama local y una de seguimiento remoto. La comparación de dos ramas de seguimiento remoto así como los comandos de menú de Vista de Sincronizar no están aún disponibles en esta versión de Egit y estarán disponibles en una futura versión.

Aquí está como se ve la Vista de Sincronizar de Git:

Estado de Sincronización

La vista de Sincronizar muestra el estado de sincronización de recursos de su espacio de trabajo o una rama local comparada con aquellos en otra rama local o de seguimiento remoto que representan el estado de una rama de un repositorio remoto. Este estado se muestra utilizando iconos y puede ser configurado también para mostrar el estado del estado como texto adjunto al nombre del recurso.

En la tabla inferior se muestra una descripción de los iconos.

Icono	Descripción
	Una suma entrante significa que un recurso ha sido añadido a la rama objetivo.
	Un cambio entrante significa que el archivo ha cambiado en la rama objetivo.
	Una eliminación entrante significa que un recurso se borró de la rama objetivo.
	Una suma saliente significa que el archivo fue añadido a su espacio de trabajo o rama fuente y aún no lo ha sido en la rama objetivo.
	Un cambio saliente significa que el archivo fue cambiado en su espacio de trabajo o rama fuente.
	Una eliminación saliente es un recurso que se borró en su espacio de trabajo o rama fuente.
	Una suma en conflicto significa que el recurso ha sido añadido en su espacio de trabajo o rama fuente y en la rama objetivo.
	Un cambio en conflicto significa que el archivo ha sido cambiado en su espacio de trabajo y en la rama objetivo.. Una mezcla manual o automática es necesaria. También, cualesquier entradas en la vista que contengan hijos que están en conflicto serán decorados con el icono de conflicto. Esto se hace para hacer los conflictos más fáciles de encontrar.
	Una eliminación en conflicto significa que el recurso se borró en su espacio de trabajo o rama fuente y en la rama remota.

Modo

La Vista de Sincronizar puede ser filtrada utilizando modos que usen bien acciones de barras de herramientas o ítems de menú en el menú desplegable de la vista. Los modos pueden ser utilizados para mostrar cambios entrantes, salientes o en conflicto.

Modelos

La vista de sincronizar es capaz de mostrar diferentes representaciones de modelos de los recursos. Cada producto puede contener sus propias representaciones de producto específicas. EL Eclipse SDK viene con tres modelos:

Workspace Model

muestra un modelo basado en recursos. Las opciones de disposición para este modelo se pueden controlar del diálogo de Preferencias en el menú despelgable. Las opciones de disposición para el modelo de espacio de trabajo son

• Flat layout

  disposición plana, muestra todos los recursos no sincronizados como hijos directos de su proyecto.

  Tree layout

  disposición arbórea, muestra la jerarquía de recursos como se muestra en el Explorador de Proyecto.

  Compress Folders

  Carpetas compresas, muestra cambios agrupados por proyecto y luego por carpeta. Esto resulta en una jerarquía que está como mucho a tres niveles de profundidad con rutas de carpeta que se compriman en un simple nivel (similar a paquetes java)

Java Model

modelo java, muestra un modelo basado en java (similar a lo que aparece en el Explorador de Paquetes).

Git Commits

acometidas de Git, muestra un modelo basado en acometidas de git. Este modelo muestra los cambios entrantes agrupados por acometidas lo cual es útil para ver quién liberó qué y porqué. Para los cambios salientes, puede crear acometidas creando acometidas. El formato mostrado de la descripción de acometida de Git puede ser configurada en preferencias bajo Team > Git > Label Decorations en la pestaña Other.

Además de los modelos , también hay una (Presentación plana) Flat Presentation la cual muestra todos los elementos no sincronizados como elementos de nivel superior.

Navegación

La vista de Sincronizacińo o Synchronize view provee en la barra de herramientas de acciones para navegar entre los cambios de la vista. Estas acciones no solo navegan entre archivos sino que también van de un cambio a otro dentro de un archivo.

El árbol en la vista de sinronización puede ser fácilmente expandido y colapsado desde la barra de herramientas.

Vista de comparación del Árbol Git

Esta vista se abrirá por alguna de las acciones (Comparar con) Compare With (véase Comparar Contenido). Cuando se inicie desde un recurso (p. ej. un proyecto o carpeta), se parecerá a los recursos en el espacio de trabajo. Sin embargo, los icono habituales en los archivos serán reemplazados por iconos mostrando el cambio de estado(añadido, borrado, cambiado, o inalterado).

Los cambios pueden ser explorados y un doble clic en un archivo mostrará un editor de comparación para este archivo (esto sólo tiene sentido en archivos "cambiados", en caso de archivos añadidos o eliminados, una parte del comparador quedará vacía, mientras que se mostrará el mismo contenido en ambos lados para archivos inalterados):

Es posible esconder archivos inalterados pinchando en el botón ("Esconder archivos con igual contenido") "Hide files with equal content" de la barra de herramientas.

La Vista de Comparación de Árbol Git puede ser también iniciada sin tener recursos del espacio de trabajo como punto de arranque (por ejemplo comparar dos acometidas en la vista de historia cuando la entrada de la vista de historia es un Repositorio y no un recurso del espacio de trabajo). En este caso, se muestra el contenido completo en el Repositorio In this case y ambos proyectos y carpetas aparecen como simples iconos "carpeta":

Vista de Preparación

Esta vista provee un equivalente para git status que muestra cambios hechos en el árbol de trabajo. Los cambios no preparados que no hayan sido aún transferidos al índice de git se mostrarán en el panel (Cambios No Preparados) Unstaged Changes, los cambios que ya han sido "añadidos" (preparados) al índice Git se muestran en el panel (Cambios Preparados) Staged Changes. Por defecto setos paneles se muestran en una disposición de fila, la cual puede ser cambiada a disposición de columna por la opción Disposición Columna oColumn Layout. Los paneles de cambios preparados o no preparado muestran por defecto la ruta de los archivos. Se pueden configurar mediante la opción (Muestra Primero Nombres de Archivos) Show File Names First para que muestren los nombres de archivos primero, seguidos por el directorio en el que se ubican.

Haga doble clic en archivos modificados para abrir una vista de comparación. Si se lanzó desde el panel de ("no preparado") "unstaged" la vista de comparación mostrará los cambios aún no preparados. Cuando se lanzó desde el panel de "preparado" mostrará los cambios ya preparados. Para abrir un archivo en el editor, utilice la acción (Abrir Versión de Espacio de trabajo) Open Workspace Version en el menú de contexto del archivo.

Para preparar un archivo, arrástrelo desde el panel (Cambios no preparados) Unstaged Changes al panel de (Cambios Preparados) o Staged Pages. Alternativamente, utilice la acción (Añadir al Índice Git) Add to Git Index en el menú de contexto del panel de (Cambios No Preparados) Unstaged Changes. La acción (Reemplazar con Archivo del Índice Git) Replace with File in Git Index reemplazará el archivo seleccionado del árbol de trabajo. Si el archivo no está preparado, se reseteará. Si está preparado, la versión del árbol de trabajo se reemplazará con la versión preparada del índice de Git.

Para despreparar o unstage un archivo, arrástrelo desde el panel (Cambios Preparados) Staged Changes al panel (Cambios no preparados) Unstaged Changes. Alternativamente, utilice la acción (Eliminar del Índice Git) Remove from Git Index en el menú de contexto del archivo.

La acción acometer acometerá solamente los cambios preparados -- similar a lo que git commit hace en el git nativo. Un editor de mensajes integrado permitirá editar el mensaje de acometida para la acometida. En contraste con el diálogo de acometida, la vista de preparación puede mantenerse abierta mientras se hacen cambios. Esto permite la escritura incremental del mensaje de acometida al tiempo que se hacen los cambios. El mensaje de acometida que se edita está asociado con el repositorio, la vista de preparación con la que está enlazada. No se almacena persistentemente y se perderá si la vista de preparación o Eclipse son cerrados.

Para acometer, presione Ctrl+Intro ('Command+Intro en Mac OS X) en el campo de texto del mensaje de acometida , o pinche en el botón (Acometer) Commit o en el botón (Acometer y Empujar) Commit and Push.

El menú de la Vista de Preparación o Staging View permite configurar la Vista de Preparación.

Si está usted trabajando en un gran cambio y se muestran muchos archivos en la Vista de Preparación ustedd puede utilizar el campo de filtrado ("Filtrar Archivos") "Filter Files" el cual filtrará el contenido de la vista de preparación para mostrar solo los archivos coincidentes con el filtro que introdujo.

Preparación Parcial

Algunas veces es útil acometer sólo algunos cambios de un archivo. Un ejemplo es cuando se trabaja en una característica y se percata uno de un error tipográfico o un pequeño fallo, la cual no corresponde a la característica.

Para acometer sólo ciertos cambios, estos cambios tienen que ser preparados primero. Para hacerlo, haga doble clic en el archivo sobre el panel (Cambios no preparados) Unstaged Changes. Esto abrirá el editor de comparación. En la parte izquierda está la versión del espacio de trabajo, en la derecha está la versión del índice (preparada).

Ambos lados del editor de comparación son editables. Cuando se cambia algo en la parte derecha (índice) y se salva, el archivo acabará en el panel de (Cambios preparados) Staged Changes y cuando se acometa, se acometerá exactamente ese contenido.

Para preparan un grupo de líneas cambiadas, se puede utilizar el botón (Copiar cambio Actual de Izquierda a Derecha) Copy Current Change from Left to Right (icono flecha) de la barra de herramientas.

Vista de Reflog Git

La Vista de Reflog muestra el reflog Git para un repositorio seleccionado. Soporta mostrar el reflog para una rama específica mediante la selección del nombre de ref del hiperenlace en la esquina superior derecha de la vista. Hacer doble clic o seleccionar la acción del menú de contexto (Abrir en el Visor de Acometida) Open in Commit Viewer sobre una entrada de reflog abre la acometida correspondiente en el visor de acometidas. La acción (Verificar) Checkout del menú de contexto verificará la acometida seleccionada y la HEAD será desenlazada.

URLs de Git

Las URLs de Git en general consisten en un esquema de protocolo de transporte, dirección de servidor remoto y la ruta de repositorio dentro del servidor remoto y para algunos protocolos de autenticación también el ID de usuario.

EGit soporta los siguientes protocolos

• file - Archivo Acceso directo al sistema de archivos para el repositorio.
• git - El protocolo de git embebido más eficiente (puerto por defecto 9418). Este protocolo no provee autenticación. Típicamente utilizado para acceso en lectura anónimo al repositorio.
• ssh - Git sobre protocolo secure shell (SSH). Típicamente utilizado para autenticar el acceso en escritura al repositorio.
• http - Hypertext Transfer Protocol puede ser tuneleado a través de cortafuegos.
• https - Hypertext Transfer Protocol Secure puede ser tuneleado a través de cortafuegos.
• ftp - Protocolo de transferencia de archivos
• sftp - Protocolo de transferencia de archivos seguro

Las URLs de Git se utilizan al

• clonar repositorios
• extraer cambios desde otro repositorio
• empujar cambios a otro repositorio

Referencias Git

Las referencias de Git se las conoce abreviadamente como Refs.
Se comprenden de

• ramas
• ramas de seguimiento remoto
• etiquetas

Todas ellas nombradas con una ruta que utiliza '/' como separador y comienzan con "refs".

• Las ramas locales comienzan con "refs/heads/"
• Las ramas de seguimiento remoto comienzan con "refs/remotes/". Las Ramas de seguimiento remoto aproximan las ramas locales de un repositorio remoto tal que su estado en el momento de la última operación de transporte pueda ser preguntado también cuando no haya conexión disponible al repositorio (fuera de línea).
• Las etiquetas comienzan con "refs/tags/"

Los nombres de Ref pueden ser abreviados siempre y cuando su forma abreviada sea única.
P. ej.

• "master" es abreviatura de "refs/heads/master"
• "origin/master" es abreviatura de "refs/remotes/origin/master"
• "v1.0.1" es abreviatura de "refs/tags/v1.0.1"

Hay también una cantidad de nombres "reservados" para Refs que son útiles en ciertos escenarios:

Nombre de Ref	Anotación
HEAD	Appunta a la acometida actualmente verificada-	FETCH_HEAD	apunta al resultado de la última operación de extracción o fetch
ORIG_HEAD	Apunta a la acometida que fue verificada antes de que se comenzara una operación de mezcla o refundación

Para una lista completa de nombres de Ref y el orden de precedencia si múltiples referencias tienen la misma forma taquigráfica véase la sección ("Especificar Revisiones") "Specifying Revisions" de git rev-parse.

Refspecs

Una "refspec" se utiliza por operaciones de extracción y empuje para describir el mapeo entre [#Git_References|Ref]] remota y Ref local. Semánticamente definen cómo las ramas locales o etiquetas son mapeadas a ramas o etiquetas de un repositorio remoto. En el git nativo se combinan con dos puntos en el formato <src><dst>, precedido por un signo plus opcional, + para denotar una actualización forzada. En EGit se pueden mostrar y también editar en forma tabular en la Especificación de Ref de Empuje o Push Ref Specification y en la Especificación de Ref de Extracción o Fetch Ref Specification y otros diálogos.

La parte "zurda" de una RefSpec se llama fuente y la diestra se llama destino. Dependiendo de si la RefSpec se utiliza para extraer o para empujar, las semánticas de fuente y destino difieren: para la RefSpec de empuje, la fuente denota una Ref en el repositorio fuente y el destino denota una Ref en el repositorio objetivo.

Refspecs de Empuje

Un ejemplo típico para una RefSpec de Empuje podría ser

HEAD:refs/heads/master

Esto significa que la rama actualmente verificada (como se indica por la referencia HEAD, véase References Git) será empujada en la rama maestra de un repositorio remoto.

Refspecs de Extracción

Un ejemplo típico para una RefSpec de extracción podría ser

refs/heads/*:refs/remotes/origin/*

Esto significa que todas las ramas del repositorio remoto se extraerán a las ramas remotas correspondientes del repositorio local.

Remotas

Las Remotas se utilizan para gestionar los repositorios ("remotos") cuyas ramas usted sigue desde su repositorio.

En EGit las Remotas se definen al

• Clonar un repositorio desde otro repositorio, por convención este repositorio del que el recientemente clonado ha sido creado se llama "origin". Si prefiere un nombre diferente el asistente de clonado le permite especificarlo.
• Definir Remotas en la Vista de Repositorios

Una Remota primero que nada define un nombre para el repositorio cuyas ramas usted sigue, esto es importante puesto que usted puede querer seguir ramas de diferentes repositorios así que el nombre ayuda a comprender con qué repositorio está tratando cierta operación. Además las Refspecs especificadas para un Remoto dado definen un mapeo de ramas y etiquetas de su repositorio local a ramas y etiquetas en el repositorio remoto. Puede que quiera utilizar diferentes mapeos para operaciones entrantes y salientes dado que hay editores para definir Configuraciones de Extracción y de Empuje disponibles en EGit.

Git Ignore

Los archivos .gitignore ubicados en el árbol de trabajo especifican archivos que intencionalmente no deberían ser seguidos por git. Sólo atañen a archivos que no han sido seguidos por git. Para ignorar cambios no acometidos en archivos ya en seguimiento, refiérase a la acción asumir inalterado.

Cada línea de los archivos .gitignore define un patrón. Git verifica los patrones ignorar siguiendo la jerarquía del árbol de trabajo desde lo más alto a lo más bajo. Los patrones definidos en un nivel más alto de archivos .gitignore son invalidados por aquellos definidos en niveles más inferiores. Los archivos que deben ser ignorados para todos los que trabajen en un proyecto dado se incluyen normalmente en el repositorio del proyecto para compartirlos fácilmente con el equipo.

Definición de formato de patrones:

• se ignoran líneas en blanco
• líneas comenzando por # sirven como comentarios
• el prefijo opcional !niega el patrón. Los archivos excluidos por un patrón previo coincidente vienen a ser incluidos de nuevo. Los patrones que acaben con una barra solo coinciden con directorios mas no con archivos o enlaces simbólicos.
• los patrones que no contengan una barra se tratan como patrones globales de línea de comandos cotejados contra la ruta relativa a la ubicación del archivo .gitignore
• git trata patrones como los globales de línea de comandos tal como se define en fnmatch(3)
• Los comodines en los patrones no coinciden con / en nombres de ruta
• una barra al inicio coincide con el inicio de un nombre de ruta

La acción de menú (Ignorar) Ignore añade el recurso seleccionado al archivo .gitignore en el directorio padre del recurso. Para introducir otros patrones a ignorar utilice un editor de texto.

Factoría de Extracción de Git para Construcción PDE

Como parte de las herramientas PDE de EGit, hay una factoría de extracción de PDE Build para Git incluida en el plugin org.eclipse.egit.fetchfactory.

El formato de archivo del mapa de archivos: type@id,[version]=GIT,args

Donde args es una lista de pares clave-valor separados por comas.

Se aceptan los siguientes args:

• tag* - etiqueta Git obligatoria
• repo* - ubicación del repositorio obligatoria
• path - ruta opcional relativa al repositorio al cual apunta el elemento (de otro modo se asume que el elemento está en el repositorio raíz)
• prebuilt - valor booleano opcional indicando que la ruta apunta a un conjunto del repositorio

Extraer se implementa como un proceso de tres pasos:

• El repositorio se clona al disco local. Si ya existe, se asume que fue previamente clonado y justo las nuevas acometidas serán extraídas
• Se verificará la etiqueta específica en el clon local
• Se copiará el contenido de la ruta a la ubicación final de construcción