| Tareas | ||
|---|---|---|
|
|
|
|
| Conceptos | Consulta | |
Al configurar Repositorios Git con EGit, hay dos recomendaciones para la creación de repositorios "productivos" (en lugar de "patio"):
La primera se produce cuando se especifica una carpeta de espacio de trabajo durante la clonación o la creación de un repositorio.
Ambas cosas sucederán cuando se utiliza el asistente de compartición de Git desde un proyecto de Eclipse que ha creado manualmente en el espacio de trabajo sin tomar precauciones (el asistente se ha arreglado en la última versión).
A continuación encontrará alguna motivación para estas recomendaciones.
Los repositorios Git se pueden crear de diferentes formas, por ejemplo, clonando desde un repositorio existente, creando uno a partir de cero o utilizando el asistente de compartición de EGit.
En cualquier caso (a menos que cree un repositorio "básico", pero eso no se discute aquí), el nuevo repositorio es esencialmente una carpeta en el disco duro local que contiene el "directorio de trabajo" y la carpeta de metadatos. La carpeta de metadatos es una carpeta hija dedicada denominada ".git" y a menudo se conoce como ".git-folder". Contiene el repositorio real (es decir, los compromisos, las referencias, los registros, etc.).
La carpeta de metadatos es totalmente transparente para el cliente Git, mientras que el directorio de trabajo se utiliza para exponer el contenido del repositorio reservado actualmente como archivos para herramientas y editores.
Normalmente, si estos archivos se van a utilizar en Eclipse, se deben importar en el espacio de trabajo de Eclipse de una forma u otra. Para ello, la forma más fácil sería incorporar los archivos .project desde los que el asistente "Importar proyectos existentes" puede crear los proyectos fácilmente. Por lo tanto, en la mayoría de los casos, la estructura de un repositorio que contiene proyectos de Eclipse sería similar a la siguiente:
Este último tiene las siguientes implicaciones:
Puede crear primero un proyecto y compartirlo después. El asistente para compartir proyecto da soporte a la creación de repositorios Git (consulte Añadir un proyecto al control de versiones).
También puede crear un nuevo repositorio git vacío desde la vista de repositorios Git (consulte Crear repositorio).
En primer lugar puede crear varios proyectos bajo un directorio común y, a continuación, crear un repositorio común para todos los proyectos de una vez:
Para poder trabajar con el contenido de un repositorio Git en el entorno de trabajo de Eclipse, los archivos y las carpetas incluidos se deben importar como proyectos. En principio, esta importación se puede realizar utilizando los asistentes "Nuevo proyecto" genérico o "Importar ...".", puesto que el directorio de trabajo de un repositorio git es únicamente un directorio normal en el sistema de archivos local. Sin embargo, los proyectos recién creados todavía tendrán que compartirse manualmente con Git. Los asistentes "Importar proyectos desde Git" integran la importación y el uso compartido de proyectos y también ofrecen una comodidad adicional.
Para iniciar el asistente, pulse Importar > Git > Proyectos desde Git
Si ha empezado en un espacio de trabajo limpio, la primera página mostrará una lista vacía:
Para poder continuar, debe añadir uno o varios repositorios Git a la lista. Si ya tiene repositorios en la lista, este paso es opcional.
Hay dos formas de añadir repositorios Git a la lista:
La primera opción se utiliza si empieza con un repositorio remoto. La operación de clonación copiará dicho repositorio en el sistema de archivos local. Para iniciar el asistente de clonación, pulse Clonar .... El asistente de clonación se describe con más detalle en Clonar repositorios remotos. Tras la finalización satisfactoria de la operación de clonación, el repositorio recién clonado aparece en la lista automáticamente.
La segunda opción es útil si ya tiene un repositorio en el sistema de archivos local, por ejemplo, porque lo ha clonado anteriormente, lo ha creado a partir de cero o lo ha copiado de algún otro lugar. Pulse Añadir... y seleccione un directorio en el sistema de archivos local. Pulse Buscar para activar una exploración para los repositorios Git contenido en este directorio. Si se encuentran repositorios Git, se listarán y puede seleccionar repositorios para añadir :
Tras la finalización satisfactoria, la lista de repositorios debe contener algunos repositorios:
Puede seleccionar un repositorio y pulsar Siguiente. En la siguiente página del asistente, decidirá cómo importar proyectos.
Esta página ofrece un grupo con botones de selección que le permiten seleccionar un asistente y un árbol de directorio que, opcionalmente, le permite seleccionar una carpeta en el directorio de trabajo.
Si se marca este botón de selección, el asistente explorará el sistema de archivos local para los archivos .project y mostrará los proyectos encontrados para ser importados. Esta es la solución más cómoda y se debe utilizar si los archivos .project se reservan en el repositorio.
En este caso, el árbol del directorio en la parte inferior está activo. Puede limitar la búsqueda de archivos .project seleccionando una carpeta en este árbol; de lo contrario, se explorará el directorio de trabajo completo del repositorio. En la página siguiente, se mostrará una lista de los proyectos encontrados (si existen). Esto es muy similar al asistente genérico Importar proyectos existentes, pero tiene algunas prestaciones de filtrado adicionales:
Cuando se elige esta opción, se abrirá el asistente "Nuevo proyecto" genérico. Una vez completado el asistente "Nuevo proyecto", el asistente "Importar proyectos desde Git" se reanudará y le ayudará a compartir los proyectos que acaba de crear.
En este caso, el árbol de directorio en la parte inferior está inactivo, ya que la selección no es relevante para el asistente "Nuevo proyecto".
Esta opción puede ser útil cuando no hay ningún archivo .project disponible ni se aplica un asistente "Nuevo proyecto" adecuado al contenido del repositorio Git. Si se selecciona, el asistente generará un archivo .project y apuntará el proyecto a una carpeta del directorio de trabajo del repositorio. El resultado es un "Proyecto general".
De forma predeterminada, el proyecto recién generado apuntará al directorio de trabajo del repositorio. Al seleccionar alguna carpeta del árbol de directorio en la parte inferior, puede tener el proyecto generado para dicha carpeta.
Pulse Siguiente para abrir un diálogo simple para especificar un nombre y un directorio para el nuevo proyecto:
De forma predeterminada, el nombre del proyecto sugerido coincide con el nombre del directorio.
Con el asistente de clonación de Git, puede clonar repositorios remotos utilizando distintos protocolos de transporte.
El asistente se puede iniciar desde el asistente "Importar proyectos desde Git" utilizando
Importar... > Git > Proyectos desde Git > Siguiente > Clonar...
o desde la "Vista de repositorios Git" (descrita en Gestionar repositorios) utilizando el menú de vista o el botón de la barra de herramientas Clonar un repositorio Git.
En la primera página del asistente, especifique la ubicación del repositorio remoto:
Los siguientes protocolos están soportados:
Nota: si está detrás de un cortafuegos, es posible que tenga que configurar los valores del proxy ( Preferencias > General > Conexiones de red). Muchos proxies HTTP se configuran para bloquear los URL que contienen un nombre de usuario (y/o contraseña) como, por ejemplo, http://fred:topsecret@egit.eclipse.org/egit.git, por lo que se recomienda utilizar los campos usuario, contraseña en la parte inferior de la página del asistente, las credenciales se transmitirán como cabeceras HTTP.
En la página siguiente, elija qué ramificaciones se clonarán desde el repositorio remoto:
Si no está seguro de qué ramificaciones necesita, simplemente pulse "Seleccionar todo".
Puede filtrar las ramificaciones por su nombre escribiendo utilizando el control de texto encima de la lista. Tenga en cuenta, sin embargo, que las ramificaciones que se han seleccionado se mostrarán siempre en la lista, es decir, no se filtrarán.
En la página siguiente, defina dónde desea almacenar el repositorio en el sistema de archivos local y defina algunos valores iniciales.
La vía de acceso raíz predeterminada para almacenar repositorios Git se puede configurar en la preferencia Equipo > Git > Carpeta de repositorio predeterminada
Puede pulsar Finalizar en esta página o pulsar Siguiente si está trabajando con Revisión de código de Gerrit y desea configurar su repositorio en consecuencia.
El asistente de clonación de EGit puede ser ampliado por otros plugins para buscar repositorios en programas de fondo específicos que albergan repositorios git. Actualmente tal extensión está disponible para Github y pronto estará disponible para Gerrit. Para ambos, es necesario instalar los respectivos conectores Mylyn. La extensión del conector de Gerrit Mylyn también configurará el repositorio remoto para el trabajo con Gerrit. Esto también se puede realizar o cambiar más adelante desde la vista Repositorios Git: consulte Configuración de Gerrit.
Cuando haya instalado dicha extensión, el asistente de clonación se abrirá con una página de selección en la que podrá elegir entre distintos orígenes del repositorio a clonar:
Si está trabajando con una ramificación local que tiene una llamada "configuración en sentido ascendente", la forma más conveniente para insertar se basa en su configuración en sentido ascendente.
Normalmente, las ramificaciones locales se crean basándose en una ramificación de seguimiento remota. Dado que la ramificación de seguimiento remoto está asociada con un remoto y el remoto contiene la información necesaria para acceder al repositorio remoto correspondiente, es posible crear automáticamente esta configuración en sentido ascendente al crear la ramificación local (consulte Ramificación para obtener más información).
Cuando se inserta en sentido ascendente desde la ramificación local, la inserción no requiere más parámetros y, por lo tanto, se puede realizar sin mostrar otro diálogo basado en la configuración en sentido ascendente almacenada.
Para insertar en sentido ascendente, pulse con el botón derecho del ratón en un proyecto y seleccione Equipo > Insertar en secuencia en sentido ascendente o pulse con el botón derecho del ratón sobre un repositorio en la Vista de repositorios y pulse Insertar en secuencia en sentido ascendente. También hay una acción disponible en el Grupo de mandatos Git.
Entonces la inserción se ejecutará inmediatamente después de seleccionar la acción. Una vez finalizado, se mostrará un diálogo de confirmación que mostrará información sobre los datos insertados y/o los mensajes de error:
La inserción en secuencia en sentido ascendente se puede configurar utilizando el botón "Configurar..." en el diálogo de confirmación (véase más arriba) o pulsando con el botón derecho del ratón en un proyecto y seleccionando Equipo > Remoto > Configurar inserción en secuencia en sentido ascendente.
Se mostrará un diálogo de configuración para la configuración de los URI de inserción y las correspondiente correlaciones de ramificaciones (RefSpecs):
El diálogo se divide en tres secciones principales. En la parte superior, se muestra información sobre el repositorio actual y la ramificación reservada actualmente. El grupo exterior muestra la Configuración de la inserción para el remoto que está asociado con la ramificación actual (en nuestro caso, "origin" tal como se muestra en el texto del grupo).
En este ejemplo específico, hay un mensaje de aviso que indica que hay varias ramificaciones que utilizan el nombre del remoto denominado "origin". Esto significa que los cambios en la configuración de la inserción afectarán a todas estas ramificaciones, no solo a la ramificación mostrada en el campo Ramificación.
El grupo de URI contiene dos controles, un campo de URI y una lista de URI de inserción. Si la lista está vacía, el URI en el campo de URI se utilizará para la inserción, si al menos una entrada está en la lista de URI de inserción, en su lugar se utilizarán los URI de la lista. Se debe tener en cuenta que si la lista de URI de inserción está vacía y el URI se cambia en este diálogo, el nuevo URI también se utilizará para la extracción, por lo que hay que tener cuidado al hacerlo.
El grupo RefMapping permite la especificación de una o varias RefSpecs (consulte Refspecs) para la inserción.
El botón "Añadir" abrirá un pequeño asistente que ayuda en la creación de las especificaciones de referencia (RefSpecs). También puede pegar una RefSpec del portapapeles en la lista.
Al pulsar en el control "Avanzado" se mostrará/ocultará un botón "Editar (Avanzado...)" que permite una edición de RefSpec más compleja parecida al Asistente de inserción que se muestra más abajo.
Los botones de la barra de botones inferior le permiten guardar los cambios y realizar la inserción inmediatamente, guardar los cambios sin la captación, ejecutar un simulacro (insertar sin guardar la configuración), revertir los cambios y Cancelar.
Como alternativa, puede utilizar Soporte de inserción directa en una especificación de inserción de un remoto.
La forma más efectiva (pero también más compleja) es utilizar el asistente de inserción
Equipo > Remoto > Insertar...
Consulte también Refspecs para obtener más explicaciones.
Pulse
Siguiente
Si es la primera vez que se conecta a este repositorio a través de ssh tendrá que aceptar la clave de host del repositorio remoto
Si la clave ssh está protegida por una frase de contraseña (lo cual se recomienda), debe especificarla aquí
Pulse Añadir especificación de todas las ramificaciones
Esta es una forma cómoda de declarar que desea correlacionar los nombres de ramificación locales con los mismos nombres de ramificación en el repositorio en sentido ascendente en el que desea insertar los cambios.
Pulse Añadir especificación de todos los códigos para correlacionar códigos locales 1:1 con códigos en el repositorio en el que desea insertar.
Si desea correlacionar las ramificaciones locales con las del repositorio en sentido ascendente de una forma distinta, puede definir especificaciones de correlación más detalladas del siguiente modo:
Esto transferirá la correlación recién definida a la lista Especificaciones para insertar
Otras especificaciones de inserción comunes:
Para suprimir una referencia en el repositorio de destino, seleccione la referencia que se va a suprimir de la lista desplegable Referencia remota para suprimir y pulse Añadir especificación. Esto creará una entrada correspondiente en la lista Especificaciones para insertar. De forma alternativa, puede escribir la especificación para que se supriman las referencias; esto también puede utilizar comodines. Al enviar Suprimir especificaciones de referencia se suprimirán las referencias coincidentes en el repositorio de destino.
Si añade varias especificaciones de referencia de inserción en conflicto, éstas se marcarán en rojo; puede resolverlo eliminando o editando las especificaciones en conflicto. También es posible editar las especificaciones in situ en la lista Especificaciones para insertar
Pulse Siguiente
Esto abrirá el diálogo Confirmación de inserción que muestra una vista previa de los cambios que se insertarán en el repositorio de destino. Si esto no se ajusta a sus expectativas, pulse Atrás y corrija las especificaciones de inserción en consecuencia.
Pulse Finalizar
Dependiendo de las opciones que ha elegido, se muestra un diálogo de informe de resultados de inserción.
En el recuadro situado en la parte inferior, se muestra el mensaje de confirmación de inserción desde el servidor remoto. En caso de cualquier error, aquí encontrará el mensaje de error del servidor remoto. Para ver el mensaje para una entrada de lista determinada, simplemente selecciónelo en la lista.
Pulse
Aceptar para cerrar el diálogo.
Si está trabajando con una ramificación local que tiene una llamada "configuración en sentido ascendente", la forma más conveniente para captar se basa en su configuración en sentido ascendente.
Normalmente, se crea una ramificación local basada en una ramificación de seguimiento remoto. Dado que la ramificación de seguimiento remoto está asociada con un remoto y este remoto contiene la información necesaria para acceder al repositorio remoto, es posible crear automáticamente esta configuración en sentido ascendente al crear la ramificación local (consulte Ramificación para obtener más información).
Al captar de secuencia en sentido ascendente, esta configuración persistida se puede utilizar para captar automáticamente sin la necesidad de proporcionar más parámetros en un diálogo.
Para poder captar de secuencia en sentido ascendente, pulse Equipo > Captar de secuencia en sentido ascendente en un proyecto o pulse Captar de secuencia en sentido ascendente en un repositorio en la vista de repositorios. También hay una acción disponible en el Grupo de mandatos Git.
La captación se ejecutará inmediatamente después de seleccionar la acción. Una vez finalizada, se mostrará un diálogo de confirmación que muestra información sobre los datos captados y/o mensajes de error:
La captación de secuencia en sentido ascendente se puede configurar utilizando el botón "Configurar..." en el diálogo de confirmación (véase más arriba) o pulsando Equipo > Remoto > Configurar captación de secuencia en sentido ascendente... en un proyecto.
Se mostrará un diálogo de configuración para configurar el URI de captación y las correlaciones de ramificaciones (RefSpecs):
El diálogo se divide en tres secciones principales. En la parte superior, se muestra información sobre el repositorio actual y la ramificación reservada actualmente. El grupo exterior muestra la Configuración de la captación para el remoto que está asociado con la ramificación actual (en nuestro caso, "origin" tal como se muestra en el texto del grupo).
El campo de URI se puede utilizar para añadir/cambiar el URI de captación.
El grupo RefMapping permite la especificación de una o varias RefSpecs (consulte Refspecs) para la captación.
El botón "Añadir" abrirá un pequeño asistente que ayuda en la creación de las especificaciones de referencia (RefSpecs). También puede pegar una RefSpec del portapapeles en la lista.
Al pulsar en el control "Avanzado" se mostrará/ocultará un botón "Editar (Avanzado...)" que permite una edición de RefSpec más compleja parecida al Asistente de captación.
Los botones de la barra de botones inferior le permiten guardar los cambios y realizar la captación inmediatamente, guardar los cambios sin realizar la captación, ejecutar un simulacro (captar sin guardar la configuración), revertir los cambios y Cancelar.
Otra forma de captar es utilizar el Soporte de captación directa en un especificación de captación de un remoto.
La forma más efectiva (pero también más compleja) es utilizar el asistente de captación
Equipo > Captar...
Consulte también Refspecs para obtener más explicaciones.
Pulse
Siguiente
Pulse
Añadir especificación de todas las ramificaciones
Esta es una forma cómoda de declarar que desea correlacionar los nombres de ramificación en el repositorio en sentido ascendente del que desea captar los cambios de 1:1 para los mismos nombres de ramificación locales.
Si desea correlacionar ramificaciones o códigos en el repositorio en sentido ascendente de una forma distinta, puede definir especificaciones de correlación más detalladas del siguiente modo:
Esto transferirá la correlación recién definida a la lista Especificaciones para captar
Pulse Finalizar
Se muestra un diálogo de resultados de captación.
La selección ad hoc de la ramificación en sentido ascendente de la que se va a extraer todavía no está soportada por EGit.
Las alternativas disponibles incluyen:
Si está trabajando con Gerrit ( http://code.google.com/p/gerrit/), EGit le permite captar convenientemente un cambio en el repositorio local para su inspección y/o su modificación.
Pulse con el botón derecho del ratón en un proyecto y seleccione Equipo > Remoto > Captar de Gerrit... o pulse con el botón derecho del ratón en un nodo de repositorio en la vista de repositorios y seleccione Captar de Gerrit...
Aparecerá un diálogo que le permite seleccionar o especificar un URI y un cambio así como algunas opciones adicionales:
En lugar de la tediosa operación de copiar-pegar o la entrada manual del ID de cambio, el diálogo también ofrece una asistencia de contenido para el cambio. Simplemente pulse "Ctrl+Barra espaciadora" para activarlo (consulte la ayuda contextual que aparece al pasar el cursor sobre el pequeño bulb decorador junto el campo Cambiar). Se pondrá en contacto con el servidor Gerrit y se captarán todos los cambios disponibles y se mostrarán en un diálogo de asistencia de contenido:
La lista se filtrará con la entrada en el campo Cambiar. Después de seleccionar el cambio en la asistencia de contenido, el campo Cambiar se rellenará con la información correcta.
Los adornos de etiquetas muestran información específica de Git sobre los recursos bajo el control de versiones Git. Aparecen en todas las vistas que muestran objetos de modelo, como el Explorador de paquetes, Explorador de proyectos, Navegador, Vista de jerarquía.
Los adornos de etiquetas Git se pueden conmutar globalmente en el menú Preferencias ( Ventana > Preferencias) en General > Aspecto > Adornos de etiquetas.
Se pueden realizar valores más detallados en las preferencias bajo Equipo > Git > Adornos de etiquetas.
Hay dos tipos diferentes de adornos de etiquetas: decoraciones de texto y decoraciones de iconos.
Las decoraciones de texto aparecen en el lado izquierdo o derecho de la etiqueta de texto. Se pueden configurar en el diálogo Preferencias bajo Equipo > Git > Adornos de etiquetas en la pestaña Decoraciones de texto. Por ejemplo, el valor predeterminado para un recurso desechable es un > en el lado izquierdo de su nombre.
Estos son los valores predeterminados:
Para archivos y carpetas existen las variables "name", "dirty" y "staged". "Dirty" y "staged" son distintivos; si son true, se visualiza el texto después de los dos puntos.
Para los proyectos hay las variables adicionales "repository" y "branch". La variable "repository" muestra el nombre del repositorio.
La variable "branch" visualiza el nombre de la ramificación reservada actualmente. Si no hay ninguna ramificación reservada, la decoración muestra el nombre abreviado del compromiso (los siete primeros caracteres seguidos de puntos suspensivos). Si los códigos y/o las ramificaciones remotas apuntan a este compromiso, se aplica una heurística de "mejor suposición" para mostrar también esta información: los códigos tienen prioridad sobre las ramificaciones remotas, si se aplican varias códigos, se muestra la más nueva; si hay varios códigos o ramificaciones remotas que no tienen fecha de modificación, se aplica la ordenación alfabética y se muestra la última. Ejemplo: el compromiso reservado
e49f576... hace referencia al código
v.0.7.1 del repositorio
egit:
Las decoraciones de los iconos aparecen en la esquina inferior derecha del icono visualizado delante de la etiqueta. Se pueden configurar en el diálogo Preferencias bajo Equipo > Git > Adornos de etiquetas en la pestaña Decoraciones de iconos.
Estas son las decoraciones predeterminadas:
Se muestra un resumen del estado de todos los archivos con seguimiento modificados en el diálogo de compromiso. Al efectuar una doble pulsación en un archivo, los cambios que se deben comprometer se mostrarán en un diálogo de comparación. Como EGit siempre compromete el contenido del árbol de trabajo (correspondiente al compromiso Git -a en la línea de mandatos), el diálogo de comparación comparará el árbol de trabajo con el último compromiso.
En el trabajo diario, a menudo, deseará ver los cambios entre el último compromiso, el índice y el árbol de trabajo actual. Para ello, seleccione un recurso (proyecto, carpeta o archivo) en el explorador de proyectos o en el navegador y pulse con el botón derecho del ratón sobre una acción en Comparar con.
Para analizar el contenido de un compromiso específico, debe utilizar la Vista de historial que da soporte a esta tarea mucho mejor, consulte la tarea Inspeccionar compromisos.
Si utiliza cualquiera de las acciones de submenú de Comparar con en un solo archivo, se mostrará un editor de comparación, de lo contrario, se abrirá la Vista de comparación de árboles Git que le permite examinar los cambios; si efectúa una doble pulsación en un archivo cambiado en esta vista, se abrirá un editor de comparación para este archivo. Una excepción es la acción de submenú Historial..., que abre la vista de historial.
La diferencia entre un recurso del directorio de trabajo actual y el última compromiso en la ramificación actual se puede ver desde el menú de contexto Comparar con > Revisión de HEAD. Esta característica también está disponible en el diálogo de compromiso. Al efectuar una doble pulsación en una entrada del diálogo de compromiso se abre un diálogo de comparación.
Las diferencias entre el árbol de trabajo actual y el índice (basado en el recurso seleccionado actualmente) se pueden ver desde el menú de contexto Comparar con > Índice Git.
Esta característica aún no se ha implementado.
La diferencia entre el árbol de trabajo (incluidos los cambios no comprometidos) y una ramificación o código puede verse pulsando el menú dinámico Equipo > Sincronizar en un proyecto y seleccionando la Ref con la que desea sincronizar el árbol de trabajo. Si el repositorio Git contiene varios proyectos Eclipse si es suficiente seleccionar un proyecto, la Vista de sincronización también incluirá los demás proyectos.
Si desea sincronizar con una Ref no listada en el menú dinámico, pulse Equipo > Sincronizar > Otro.... A continuación, en el asistente de sincronización pulse la columna de destino del repositorio que desea sincronizar y seleccione la Ref con la que desea compararse.
Al pulsar "Incluir cambios no comprometidos locales en comparación" también local, los cambios todavía no preparados y los cambios ya preparados se mostrarán en la comparación.
También es posible comparar varios repositorios a la vez. En este caso en el asistente de sincronización, seleccione para cada repositorio la referencia con la que desea comparar.
En lugar de utilizar un editor de comparación, puede habilitar el soporte de quickdiff y ver los cambios dentro del editor de texto.
Esta característica se puede habilitar mediante la página de preferencias
General > Editores > Editores de texto > Quick Diff:
La anotación de diferencia se mostrará en el lado izquierdo del editor:
Si mueve el ratón sobre la anotación, verá el contenido de la versión con la que está comparando:
De forma predeterminada, la comparación es con HEAD. Puede determinar la versión con la que está comparando, la llamada línea base de quickdiff, desde el menú contextual de un compromiso en la vista de historial (Mostrar en > Historial). Hay tres entradas de menú:
Para inspeccionar un compromiso dado
La vista de historial muestra la diferencia en el panel izquierdo inferior. La selección de un archivo en el panel derecho inferior se desplaza a la sección de archivo correspondiente de la diferencia.
El comportamiento de una doble pulsación en un archivo en el panel inferior derecho depende del estado del botón de conmutación de modalidad de comparación. Si está activado, se abrirá un editor de comparación que compara el contenido del archivo en el compromiso actual con el contenido del compromiso del ancestro; si está desactivado, se abrirá un editor que muestra el contenido del archivo en el compromiso actual.
Las modificaciones de un proyecto bajo el control de versiones Git persisten en el historial de git a través de los compromisos. A partir del estado reservado del repositorio git, modifique el proyecto hasta que haya alcanzado un estado con el que está satisfecho y, a continuación, confirme todos estos cambios en el repositorio como un solo compromiso. Cada compromiso representa una instantánea bien definida de todos los archivos almacenados en el repositorio.
Para modificar un proyecto que ya se comparte con Git, modifique o suprima archivos dentro de Eclipse o directamente en el sistema de archivos. No hay necesidad de informar a Git por adelantado acerca de estas operaciones. Los archivos nuevos que deben estar controlados por la versión deben colocarse explícitamente bajo el control de versiones Git:
De forma alternativa, puede visualizar archivos sin seguimiento en el diálogo de compromiso y marcar el recuadro de selección Mostrar archivos sin seguimiento para seleccionarlos para incluirlos en el compromiso.
Los decoradores de etiquetas, por ejemplo, en la vista Explorador de paquetes muestran
Para obtener detalles, consulte Adornos de etiquetas.
A continuación se muestra un ejemplo en el Explorador de paquetes de
Para comprometer un cambio, pulse Equipo > Compromiso... en el menú contextual de un recurso en el proyecto.
Git realiza un seguimiento de todos los cambios realizados en todo el repositorio, capturando las modificaciones de todos los archivos con control de versiones en dicho repositorio, no en lo que se refiere a si estos archivos residen en el mismo proyecto de Eclipse o no.
Una vez que ha desencadenado el compromiso, se abrirá el Diálogo de compromiso
En el diálogo de compromiso, especifique el mensaje de compromiso que describe el cambio.
Es una buena práctica empezar el mensaje con una primera línea corta que resuma el cambio seguido de una línea en blanco y, a continuación, el cuerpo del mensaje. Para asegurarse de que también las herramientas de línea de mandatos git puedan dar un buen formato a estos mensajes, las líneas no deben ser demasiado anchas (esto se indica con una línea vertical gris).
El corrector ortográfico de Eclipse comprueba si hay errores en el texto del mensaje de compromiso. El corrector ortográfico se puede configurar a través de Eclipse Preferencias > General > Editores > Editores de texto > Ortografía. Pulse Ctrl+1 para abrir los arreglos rápidos que pueden ayudar a arreglar los errores ortográficos.
El editor de mensajes de compromisos da soporte a la asistencia de contenido para los nombres de archivo que se muestran en la sección Archivos del diálogo de compromiso, que se puede activar pulsando Ctrl-Espacio.
Códigos de pie de página
El último párrafo de mensaje de compromiso puede ir seguido de códigos de 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 estos códigos es específica del proyecto o de la herramienta
Además, este diálogo controla cuál de los cambios se incluirá en el compromiso. Si quita la marca del recuadro de selección que aparece delante de un archivo, los cambios en este archivo no se incluirán en el compromiso. El archivo local del espacio de trabajo de Eclipse seguirá conteniendo las modificaciones que le dan la oportunidad de comprometer estos cambios con un compromiso subsiguiente. Esta característica suele utilizarse para separar las modificaciones realizadas en un conjunto de archivos en diferentes compromisos.
Un ejemplo: suponga que desde el último compromiso ha corregido un error en A.java y ha añadido un nuevo método a B.java. Estas dos modificaciones son lógicamente independientes entre sí, por lo que es posible que desee comprometerlas en dos compromisos independientes. En este caso, iniciará el compromiso, deseleccionará B.java del conjunto de archivos comprometidos y especificará un mensaje de compromiso que describa solo la corrección de errores en A.java. Tras un primer compromiso satisfactorio, solo se vuelve a llamar al compromiso y el diálogo siguiente le presentará los cambios restantes en B. java. Ahora se especifica un mensaje de compromiso que describe la adición del método y finaliza el segunda compromiso.
Los nuevos archivos que ha añadido al proyecto que no se han añadido explícitamente al control de versiones (consulte "Modificación del contenido") se listarán en el diálogo de compromiso si selecciona el recuadro de selección "Mostrar archivos sin seguimiento". Si marca el recuadro de selección que está delante de estos archivos en la lista, se añadirán al repositorio y se comprometerán una vez que pulse el botón de compromiso. Aquí no se mostrarán los archivos excluidos por la lista de omisiones de equipo o un archivo .gitignore o que se derivan (por ejemplo, la carpeta bin en proyectos Java). Si no tiene más cambios en el repositorio que esos archivos sin seguimiento, el recuadro de selección Mostrar archivos sin seguimiento está seleccionado de forma predeterminada.
Si reconoce que ha perdido algo al comprometer un cambio, puede arreglar esto: abra de nuevo el diálogo de compromiso y especifique que el compromiso actual "corregirá" el compromiso anterior en la ramificación actual. El nuevo compromiso reemplazará al anterior. Esta característica suele utilizarse para corregir los compromisos incorrectos antes de que se publiquen en otros repositorios.
Nota: no modifique los compromisos si ya se han publicado en un repositorio compartido ya que esto puede molestar a otros si ya han basado sus cambios en el cambio publicado.
Ejemplo de corrección:
Imagine que ha comprometido un cambio en un archivo que contiene un error tipográfico
Después de comprometer el campo se detecta un error tipográfico. Para corregir este error y el compromiso correspondiente, únicamente arregle el error tipográfico en el archivo de origen
a continuación, vuelva a abrir el diálogo de compromiso y seleccione la opción Corregir compromiso anterior.
El mensaje de compromiso del compromiso anterior (el que desea sustituir) se rellena en el campo "Mensaje de compromiso". Esto le da la oportunidad no solo de corregir los errores en el contenido de los archivos con control de versiones, sino también de corregir los errores (por ejemplo, errores tipográficos) en el mensaje de compromiso que describe su cambio.
Como alternativa a la corrección, podría simplemente comprometer la versión corregida como un compromiso subsiguiente. Pero el primer compromiso que contiene el error tipográfico no es de utilidad para nadie y para no saturar el historial de su proyecto con compromisos no necesarios, puede decidir corregir el compromiso.
Tenga en cuenta que la corrección de compromisos que ya se han publicado en otros repositorios puede provocar problemas. Una vez que haya enviado un compromiso a un repositorio remoto o que el repositorio local haya sido clonado por otra persona, debe tener mucho cuidado con la corrección de compromisos. En este caso, probablemente será una mejor solución publicar un segundo compromiso que corrija el primero. De lo contrario, informe a todos los demás de que ha corregido un compromiso publicado para que puedan reaccionar en consecuencia.
Los cambios que aún no se han comprometido y aún no se han preparado se pueden revertir para un conjunto de archivos seleccionados. Seleccione los archivos en el explorador de paquetes o una vista análoga y pulse Sustituir por > Archivo en índice Git.
Esta característica no está disponible actualmente en el nivel de archivo único. Puede utilizar Restablecer a con la opción completo restablecer a la fuerza todo el árbol de trabajo del repositorio de nuevo al estado del compromiso HEAD (consulte "Restablecer HEAD actual" más abajo). Esta operación revertirá todos los cambios en el árbol de trabajo y el índice. Aún no puede hacerlo en un conjunto seleccionado de archivos utilizando EGit.
La característica quickddiff se puede utilizar para revertir cambios individuales en un archivo. Puede revertir por línea, bloque (el rango de líneas de cambios) o la selección. Seleccione todo el texto y, a continuación, Revertir selección para revertir un archivo completo.
Los cambios introducidos por un compromiso determinado se pueden revertir mediante un nuevo compromiso creado automáticamente en la parte superior del compromiso reservado actualmente. El compromiso que se va a revertir no se tiene que reservar para ello.
Seleccione el compromiso en la vista de historial, abra el menú contextual y seleccione Revertir compromiso. Esto revierte los cambios que el compromiso seleccionado introduce creando un nuevo compromiso en la parte superior del compromiso reservado actualmente.
Git ofrece la posibilidad de restablecer la HEAD de la ramificación actual a cualquier otro compromiso. Opcionalmente, restablece el índice y el árbol de trabajo para que coincidan con dicho compromiso. Tenga en cuenta que esta acción afecta a todos los archivos y carpetas del repositorio completo.
Tiene la opción de realizar un restablecimiento completo, restablecimiento mixto y un restablecimiento parcial.
Seleccione Equipo -> Restablecer... en un proyecto. Se abre un diálogo donde puede seleccionar una ramificación o un código.
Seleccione un compromiso en la vista de historial y abra el menú contextual. Aquí encontrará las entradas Restablecimiento completo, Restablecimiento mixto y Restablecimiento parcial.
Esto se puede hacer como un caso especial de restablecimiento. Si se restablece a la HEAD actual (normalmente el último compromiso en la ramificación) con la opción completo se sobrescribe el árbol de trabajo y el índice con el contenido de HEAD. Puede hacerlo de tres maneras:
Si hay demasiadas ramificaciones, la lista las muestra todas. En este caso
o bien
Esto se siempre se lleva a cabo con el diálogo de creación de ramificación. La ramificación recién creada puede opcionalmente reservarse marcando un recuadro de selección en el diálogo.
Hay varias acciones disponibles para crear una ramificación local. Todas estas acciones utilizan el diálogo de creación de ramificación:
El recuadro combinado en la parte superior permite seleccionar la ramificación o comprometer la nueva ramificación. Normalmente, se trata de una ramificación de seguimiento remoto, pero podría ser cualquier ramificación o compromiso en el repositorio.
El grupo "Estrategia de extracción" permite sustituir la configuración predeterminada para la "configuración en sentido ascendente" que resulta útil cuando se capta y se inserta, pero sobre todo cuando se extrae. En función de la opción seleccionada se puede elegir la configuración siguiente:
Puede ver y editar la configuración en sentido ascendente en la configuración del repositorio.
EGit también da soporte al parámetro de configuración de git branch.autosetuprebase, establézcalo en always si desea utilizar de forma predeterminada la estrategia de extracción de reorganización. Si establece esto en la configuración del repositorio que se utiliza para todas las ramificaciones creadas basadas en una ramificación de seguimiento remoto en este repositorio, si la establece en la configuración de usuario se utilizará para todos los repositorios.
En la parte inferior, puede decidir si la nueva ramificación se va a reservar inmediatamente.
Una fusión incorpora cambios de compromisos con nombre (desde el momento en que sus historiales se separan de la ramificación actual) en la ramificación actual.
Tiene dos lugares en los que se puede desencadenar la fusión:
En el explorador de paquetes o el navegador, abra el menú contextual en un nodo de proyecto. Seleccione Equipo > Fusionar...
Ahora se abre el diálogo de fusión:
En el diálogo, seleccione una ramificación o un código que desee fusionar con la ramificación actual.
Puede desencadenar una fusión desde cualquier nodo de ramificación y de código y desde el nodo de repositorio si ha reservado una ramificación local. Consulte Fusionar una ramificación o un código para obtener más detalles.
Después de pulsar el botón Fusionar, se pueden producir los siguientes escenarios:
El resultado de una fusión se resume en un diálogo:
En la primera línea verá el resultado de la fusión. Los posibles resultados son "Ya actualizado", "Avance rápido", "Fusionado", "En conflicto" o "Anómalo". Una posible razón para "Anómalo" puede ser que haya cambios en conflicto en el directorio de trabajo.
En la segunda línea, verá el nuevo compromiso de HEAD en caso de una fusión satisfactoria (Ya actualizado, Avance rápido o Fusionado).
En la tabla, verá los compromisos que se han fusionado.
Una fusión puede producir conflictos que requieren una acción de usuario. Este es el caso cuando el contenido de los archivos no se puede fusionar automáticamente. Estos conflictos se marcan con una decoración de etiqueta en el árbol de navegación. Los conflictos de fusión en el contenido de los archivos se presentan con marcadores de conflicto textuales (consulte http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented para obtener más detalles).
Para resolver un conflicto, debe realizar los pasos siguientes:
Un repositorio que contiene archivos en conflicto tiene el decorador de etiqueta textual "|Conflictos" adjunto al nombre del repositorio. Los recursos y carpetas en conflicto que contienen estos recursos en conflicto obtienen una decoración de etiqueta de conflicto.
En el contenido del archivo, el área donde se ha producido un par de cambios en conflicto se marca con marcadores <<<<<<<, =======, y >>>>>>>. La parte anterior a ======= es normalmente su lado y la parte posterior es normalmente el lado de ellos (consulte http://www.kernel.org/pub/software/scm/git/docs/git-merge.html#_how_conflicts_are_presented para obtener más detalles).
Abra el archivo en un editor, edite el contenido y guarde el editor.
Tenga en cuenta que este paso no es obligatorio. EGit no comprueba el contenido para decidir si se ha resuelto un conflicto. El siguiente paso es el más importante.
Cuando haya terminado de editar un archivo, seleccione Equipo > Añadir para añadir la resolución del conflicto al índice git. Puede hacerlo en una carpeta o en todo el proyecto para resolver todos los conflictos a la vez.
Cuando haya resuelto todos los conflictos, la decoración de etiqueta del repositorio textual cambia a "Fusionado". Ya no hay marcadores de conflicto.
Cuando el repositorio está en estado "Fusionado" (como se indica con el decorador de etiqueta textual "|Conflictos" adjunto al nombre de repositorio) la fusión se puede al fin comprometer-
Seleccione Equipo > Comprometer... en cualquier lugar del árbol de navegación. El diálogo de compromiso se abre con un aspecto ligeramente diferente en comparación con un compromiso normal:
Después de pulsar el botón "Comprometer", se completa la fusión.
Si una fusión ha provocado conflictos, puede cancelar la fusión con la ramificación actual. Esto se puede hacer en estado "Conflictos" y en estado "Fusionado", es decir antes y después de haber resuelto los conflictos.
El restablecimiento completo se puede realizar desde el menú de equipo, la vista de repositorios Git o la vista de historial. Consulte Revertir todos los cambios locales y preparados para obtener más detalles.
La reorganización aplica una cadena de compromisos en un compromiso dado. Un escenario típico es el desarrollo de alguna característica en una ramificación "topic" que se ha creado a partir de una ramificación "master" en algún momento. Cuando "master" se actualiza con cambios, por ejemplo, de otros desarrolladores mientras "topic" aún está bajo desarrollo, puede que sea necesario incorporar estos cambios en "topic".
Supongamos que se inicia el desarrollo en "topic" creando la ramificación "topic" a partir de master. En este punto, tanto "master" como "topic" apuntan al compromiso "E". Cuando el primer compromiso ("A") se añade a "topic", el historial de compromisos del repositorio tiene el aspecto siguiente:
A topic
/
D---E master
Ahora, supongamos que había algunos compromisos más sobre "topic" y algunos compromisos más sobre "master" (por ejemplo, "master" puede hacer el seguimiento de algún repositorio remoto y hubo algunos cambios en ese repositorio remoto que se han extraído en "master"):
A---B---C topic
/
D---E---F---G master
Ahora, con el fin de incorporar los cambios de "master" en "topic", una reorganización de "topic" en "master" produciría
A'--B'--C' topic
/
D---E---F---G master
Técnicamente, la secuencia de compromisos que están contenidos en "topic" pero no en "master" se aplican (es decir, se entresacan) en la parte superior de "master" uno por uno.
Tenga en cuenta que los compromisos A, B, C no se pierden ni se cambian, en lugar de ello se creará una nueva cadena de compromisos A ', B', C' con los mismos cambios y mensajes de compromiso que los compromisos originales (pero distintos ID de compromiso). Los compromisos antiguos A, B, C siguen estando en la base de datos de objetos pero ya no son visibles porque no se pueden alcanzar desde ninguna ramificación. A', B', C' son distintos de los antiguos ya que ahora también contienen los cambios F y G.
Veamos un ejemplo sencillo: tenemos un archivo de texto "FamousWords.txt" que inicialmente podría tener un contenido como
Chapter 1 Once upon a time... Chapter 2 To be or not to be
Ahora, en "topic", se crean dos compromisos, el primero añadiendo una traducción al francés al capítulo 2, y otro añadiendo una traducción al alemán:
Después del primer cambio en "topic":
Chapter 1 Once upon a time... Chapter 2 To be or not to be Être ou ne pas être
Después del segundo cambio en "topic":
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 ha cambiado en "master" al añadir dos compromisos que añaden las traducciones al francés y al alemán al Capítulo 1:
Chapter 1 Once upon a time... Il était une fois Es war einmal Chapter 2 To be or not to be
El historial de compromisos tiene el aspecto siguiente:
Ahora, si "topic" se reorganiza en "master", los dos cambios en topic se aplican en la misma secuencia que se aplicaron durante la evolución de "topic".
El resultado es una versión fusionada 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 un historial de compromisos con el historial de compromisos de "topic" en la parte superior de "master" actual:
Hasta ahora, hemos asumidos que los cambios en "topic" se pueden fusionar automáticamente en "master". Sin embargo, en el mundo real puede suceder que encuentren conflictos durante la reorganización. Ahora, si un compromiso que se va a entresacar contiene cambios que están en conflicto con cambios en "master", la operación de reorganización se interrumpe después de aplicar el cambio en conflicto; los conflictos se visualizan de la forma habitual (con marcadores en conflicto) y el usuario tiene la oportunidad de decidir si desea
Si se elige Resolver conflictos y los conflictos se han resuelto manualmente, los cambios se deben "Añadir" y, a continuación, se puede reanudar la reorganización, es decir, se aplicará el siguiente compromiso en la cadena.
Si se ha elegido Saltar, los cambios en conflicto se revertirán y se aplicará el siguiente compromiso en la cadena.
Si se ha elegido Cancelar, la operación de reorganización se retrotraerá completamente, devolviendo el repositorio a su estado original antes de que se iniciara la reorganización. Este proceso se repite hasta que el último compromiso se aplica o se omite. Por último, la ramificación "topic" se cambiará para que apunte al último compromiso.
Para entender mejor "Saltar, volvamos a la introducción anterior. Si asumimos que el compromiso "B" provoca algunos conflictos con el "master" actual, el usuario podría decidir simplemente omitir "B"; el nuevo historial de compromisos después de la reorganización tendría el siguiente aspecto:
A'--C' topic
/
D---E---F---G master
La reorganización está disponible en la vista de repositorios Git. En los nodos de repositorio, Reorganizar... abre un diálogo que solicita al usuario que seleccione una ramificación que no esté reservada; la ramificación reservada actualmente se reorganizará en la ramificación seleccionada. En los nodos "Ramificación" (tanto las ramificaciones de seguimiento local como remotas, pero no en la ramificación reservada actualmente), Reorganizar reorganizará inmediatamente la ramificación reservada actualmente en la ramificación seleccionada:
Si la reorganización se ha realizado correctamente, se mostrará un diálogo de confirmación; este diálogo se puede suprimir marcando un recuadro de selección; una preferencia de la página de preferencias de Git permite que diálogos vuelvan a aparecer. Si se suprime el diálogo, en su lugar aparece un mensaje "Información" en el registro de Eclipse.
Si se produce un conflicto durante una reorganización se muestra un diálogo que proporciona información sobre la confirmación que ha provocado el conflicto. Marcando un botón de selección, puede decidir si desea
A menos que se haya elegido "Saltar" o "Cancelar" en el diálogo, los conflictos se deben resolver manualmente editando los archivos en conflicto. Cuando ha terminado la edición, los archivos se deben declarar como resueltos "Añadiéndolos" al índice.
Una vez resueltos todos los conflictos, se puede reanudar la reorganización pulsando con el botón derecho del ratón sobre el nodo de repositorio en la Vista de repositorios Git y seleccionando Reorganizar > Continuar.
Las opciones "Saltar" y "Cancelar" también están disponibles en la Vista de repositorios Git pulsando con el botón derecho del ratón en el nodo de repositorio y seleccionando Reorganizar > Saltar y reorganizar > Cancelar, respectivamente.
La herramienta de fusión también se puede iniciar desde la entrada correspondiente en el menú de equipo
Siempre que el repositorio esté en estado "Reorganizando", el usuario siempre puede terminar anormalmente la reorganización en la vista de repositorios Git utilizando la acción de menú "Reorganización > Cancelar" que está disponible en el nodo Repositorio.
La implementación de la reorganización de Egit actual todavía no puede manejar todos los gráficos de versión posibles. Si el gráfico es demasiado complicado la reorganización se cancelará con un mensaje de error. Como solución temporal hasta que estos gráficos más complejos también estén soportados por la reorganización de EGit, en su lugar utilice git nativo desde la línea de mandatos.
Un compromiso dado C en la ramificación stable-1.0 contiene un conjunto de cambios que desea integrar en el desarrollo actual en la ramificación master.
A--B--C--D stable-1.0
/
D---E---F---G master HEAD
Entresaque el compromiso C para crear un nuevo compromiso C' '' encima del compromiso de cabecera de la ramificación reservada actualmente ''master. C' '' contendrá los cambios realizados en ''C aplicados en HEAD de la ramificación reservada actualmente master.
A--B--C--D stable-1.0
/
D---E---F---G--C' master HEAD
Actualmente está trabajando en la ramificación "feature2" (HEAD). Hay un compromiso "feature 1" en otra ramificación.
Desea integrar los cambios realizados por el compromiso "feature 1" en el desarrollo actual en la ramificación "feature 2".
Los códigos también se pueden crear en la vista de historial: seleccione un compromiso y ejecute Crear código... en el menú contextual. El código se creará en el compromiso seleccionado:
¿Qué hacer si ha codificado el compromiso erróneo o tiene algún tipo de error tipográfico?
Por lo tanto, si el código antiguo aún no se ha insertado, puede corregirlo de la siguiente manera:
Para suprimir un código, seleccione el código que se va a suprimir y pulse Suprimir código.
Nota: es una mala práctica suprimir códigos que ya se han publicado en un servidor público, algunos servidores Git incluso no permiten la supresión de códigos para garantizar la rastreabilidad para releases que normalmente están codificados. Además, consulte la sección "On re-tagging" en la documentación de consulta de Git del mandato tag.
Los códigos ligeros se muestran en la vista de repositorios así como en el diálogo Crear código, pero no se pueden editar. Los códigos se muestran con un icono azul en la vista de repositorios, los códigos anotados están decorados con una persona amarilla.
En la vista de historial, los códigos se muestran como etiquetas amarillas.
Los códigos firmados aún no están soportados por EGit; en su lugar utilice la línea de mandatos git tag o git tag -s.
"Un parche es un fragmento de software diseñado para arreglar problemas, actualizar un programa informático o sus datos de soporte" (wikipedia). Un archivo de parche contiene una descripción de los cambios de un conjunto de recursos que se pueden aplicar automáticamente a otro espacio de trabajo de Eclipse o al repositorio git.
Los formatos de parche utilizados por Eclipse ( Equipo > Aplicar parche) y por git ( git apply o git am en la línea de mandatos) son distintos. Es posible crear los dos tipos de parche en EGit.
Este es el caso de uso más común para un sistema de creación de versiones distribuido. Un desarrollador compromete un cambio en una característica local o una ramificación de corrección de errores y desea exportar este cambio a un archivo de parche.
Puede llevarse a cabo desde la vista de historial:
El archivo de parche contendrá la diferencia entre el compromiso y su padre en la vista de historial. Tenga en cuenta que el filtro de la vista de historial se aplica también para la creación de parches.
El asistente consta de dos páginas. La página 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 compromiso.
En la segunda página puede cambiar el formato del parche.
Actualmente hay un recuadro de selección: Exportar en formato de parche git.
Las diferencias binarias no se producen actualmente.
Actualmente, EGit no puede aplicar parches en formato git. Es posible aplicar parches utilizando el formato estándar de Eclipse (diferencias unificadas) utilizando el Equipo > Aplicar parche.... Los parches Git pueden contener extensiones no estándar para la redenominación y las diferencias binarias. La versión actual de EGit no genera estas extensiones.
La "Vista de repositorios Git" es el elemento de la IU primario para facilitar el trabajo con varios repositorios simultáneamente (es decir, dentro de un espacio de trabajo de Eclipse).
Esta vista se puede abrir utilizando la vía de acceso del menú
Ventanas> Mostrar vista > Otro... > Git > Repositorios Git
También forma parte de la perspectiva "Exploración de repositorio Git" disponible utilizando la vía de acceso del menú
Ventana > Abrir perspectiva > Otro... > Exploración de repositorio Git
Si ya tiene proyectos en el espacio de trabajo que se comparten con un repositorio Git, puede utilizar
Equipo > Mostrar en vista de repositorios
en cualquier recurso para abrir la vista.
Al principio, la vista de repositorios Git está vacía. Para poder añadir repositorios a la misma, hay varias opciones:
Puede añadir un repositorio desde el sistema de archivos local a la vista de repositorios Git sin clonarlo. Esto puede ser útil si está configurando un nuevo espacio de trabajo de Eclipse y desea volver a utilizar los repositorios Git. Utilice el botón Añadir un repositorio Git existente desde la barra de herramientas de la vista:
Aparecerá un diálogo que le solicitará un directorio del sistema de archivos local. Después de seleccionar el directorio correcto, puede pulsar el botón Buscar para ver una lista de repositorios Git en este directorio. A continuación, puede seleccionar algunos o todos los repositorios encontrados y añadirlos a la vista utilizando Aceptar:
Para clonar un repositorio, consulte Clonar repositorios remotos. Después de una operación de clonación satisfactoria, el repositorio recién clonado debe aparecer automáticamente en la vista de repositorios Git.
También puede utilizar el botón Clonar un repositorio Git desde la barra de herramientas de la vista para iniciar el asistente de clonación:
Consulte Clonar repositorios remotos sobre cómo utilizar el asistente.
Puede crear un nuevo repositorio vacío en el sistema de archivos local. Esto es útil si más adelante desea crear uno o más proyectos nuevos debajo de este repositorio. Otro caso práctico es crear un nuevo repositorio vacío en el que puede insertar. Utilice el botón Crear un nuevo repositorio Git en la barra de herramientas de la vista:
Aparecerá un diálogo que le permite elegir un directorio:
Si marca el recuadro de selección Crear como repositorio vacío el nuevo repositorio no tendrá un directorio de trabajo. Entonces solo podrá añadir contenido insertando los cambios desde otro repositorio.
Como atajo, también es posible pegar a esta vista la vía de acceso del sistema de archivos local de un repositorio Git desde el portapapeles. Para ello, copie la vía de acceso de un repositorio Git (la vía de acceso completa de su carpeta .git ) en el portapapeles y, a continuación, abra el menú contextual en el panel de la vista:
o pulse Editar > Pegar en el menú principal (o el atajo de teclado correspondiente). Si el contenido del portapapeles no es adecuado, se mostrará una ventana emergente de error, de lo contrario, el repositorio añadido debe aparecer automáticamente.
Después de que la vista se haya rellenado con algunos repositorios, debe tener el aspecto siguiente:
Para eliminar un repositorio de la vista de repositorios, seleccione un repositorio y pulse "Eliminar repositorio"
Para suprimir un repositorio, selecciónelo en la vista de repositorios y pulse "Suprimir repositorio".
A continuación, confirme que desea suprimir el repositorio
y decida si desea suprimir los proyectos contenidos en el repositorio del espacio de trabajo de Eclipse.
La siguiente captura de pantalla muestra los dos niveles superiores de la vista de repositorios Git:
El nodo raíz representa el propio repositorio. El texto del nodo indica el nombre del repositorio y su ubicación en el sistema de archivos local. Los nodos "Branches" (Ramificaciones) y "Tags" (Códigos) permiten la navegación y la manipulación de códigos y ramificaciones. El nodo "References" (Referencias) lista otras referencias que no son ramificaciones o códigos, especialmente las referencias simbólicas "HEAD" y "FETCH_HEAD" (consulte Referencias Git).
El nodo "Working Directory" (Directorio de trabajo) visualiza la ubicación y la estructura del directorio de trabajo en el sistema de archivos local (solo en caso de un desarrollo, o un repositorio no vacío, para los repositorios vacíos, este nodo es siempre una hoja).
Por último, el nodo "Remotes" (Remotos) permite examinar y manipular las configuraciones remotas utilizadas para la captación y la inserción.
Para poder trabajar con el contenido de un repositorio Git, sus archivos y carpetas se deben importar en el espacio de trabajo de Eclipse en forma de proyectos. Mientras que el asistente de clonación de Git permite realizar dichas importaciones directamente después de la clonación, la vista de repositorios Git permite desencadenar importaciones de proyectos independientemente de la operación de clonación.
El menú de contexto "Importar proyectos..." está disponible en el nodo "Repositorio" así como en cualquier nodo "Carpeta" dentro del nodo "Directorio de trabajo" y el propio nodo "Directorio de trabajo":
La razón fundamental para ofrecer la acción Importar proyectos ... en varios nodos es que algunos de los asistentes que se utilizan para importar proyectos pueden incluir el directorio del sistema de archivos, por ejemplo, el asistente Importar proyectos existentes. Si la importación se inicia desde el nodo "Repositorio" o el nodo "Directorio de trabajo", el directorio de trabajo del repositorio se establece como contexto, de lo contrario, el directorio correspondiente al nodo "Carpeta" seleccionado actualmente.
Los detalles de la importación de proyectos se describen en Utilizar el asistente de nuevos proyectos.
El nodo "Ramificaciones" permite crear, examinar, reservar y suprimir ramificaciones locales y remotas. El nodo "Códigos" permite examinar y reservar códigos. Tanto el nodo "Ramificaciones" como el nodo "Códigos" permiten fusionar la ramificación o el código en la ramificación reservada actualmente y también para sincronizar con la ramificación reservada actualmente.
Para una mejor lectura, las ramificación se organizan en dos subnodos para ramificaciones locales y remotas, respectivamente, y solo se muestran los nombres abreviados, por ejemplo, en lugar de "refs/heads/master", encontrará una entrada "master" bajo el nodo "Ramificaciones locales", en lugar de "refs/remotes/origin/master" el nombre abreviado "origin/master" se muestra bajo el nodo "Ramificaciones remotas". De forma similar, los nombres de código se acortan al omitir el prefijo "refs/tags/":
Las ramificaciones y los códigos se pueden reservar mediante una doble pulsación en el nodo respectivo o seleccionando la entrada de menú contextual correspondiente.
Las ramificaciones locales se pueden crear utilizando el Diálogo de creación de ramificación. El asistente se abre pulsando con el botón derecho del ratón sobre el nodo "Ramificaciones", "Ramificaciones locales" en cualquier nodo "Ramificación" y "Código").
La supresión de ramificación se realiza utilizando la entrada de menú contextual correspondiente.
Puede desencadenar la reorganización de la ramificación reservada actualmente en otra ramificación pulsando con el botón derecho del ratón en Reorganizar en cualquier nodo de ramificación (de seguimiento local o remoto).
Puede desencadenar una fusión desde cualquier nodo de ramificación y de código y desde el nodo de repositorio si ha reservado una ramificación local. Consulte Fusión para obtener más detalles de las características de fusión.
Puede realizar una comparación de los cambios en HEAD con los cambios realizados en cualquier otra ramificación o código. Pulse con el botón derecho del ratón y seleccione Sincronizar... en cualquier ramificación o código. A continuación, se abre la vista de sincronización de Eclipse que contiene una representación de los cambios contenidos en HEAD pero no en la otra ramificación o código (cambio saliente) o viceversa (cambio entrante). Consulte la documentación de la característica de sincronización para obtener más detalles.
Hay dos formas de determinar qué ramificación o código se reserva actualmente: el nodo de ramificación/código reservado está decorado con una marca de selección pequeña y la entrada "HEAD" bajo el nodo "Referencias simbólicas" muestra el nombre (completo) de la ramificación reservada:
Pulse con el botón derecho del ratón y seleccione Restablecer ... en cualquier ramificación o código. Se abre un diálogo que le permite decidir sobre el tipo de restablecimiento. Consulte Restablecer el HEAD actual para obtener más detalles.
Si HEAD está "desconectado", es decir, no está apuntando a la punta de una ramificación local sino a un compromiso o código, entonces ninguno o varios marcadores "reservados" pueden aparecer en el árbol, ya que cualquier número de códigos o ramificaciones remotas pueden apuntar al compromiso reservado actualmente. El estado en el que se encuentra mientras HEAD está desconectado no se registra por ninguna ramificación (que es natural --- no está en ninguna ramificación).
El nodo Referencias muestra algunas referencias que no son ramificaciones y códigos (la lista es dinámica y depende del estado actual del repositorio):
Si la referencia es simbólica, es decir, apunta a otra referencia, se muestra el nombre de la referencia de destino, seguido por el ID de objeto del destino de la referencia. Si la referencia no es simbólica, solo se muestra el ID de objeto.
En el ejemplo anterior, HEAD es una referencia simbólica que apunta a la ramificación "refs/heads/master" (es decir, la ramificación "master" se reserva", mientras que FETCH_HEAD apunta directamente al compromiso 226a7f ....
Las acciones siguientes están disponibles al pulsar con el botón derecho del ratón sobre una referencia: Reservar ' (a menos que la referencia se haya reservado) y 'Crear ramificación ... .
El nodo "Directorio de trabajo" visualiza la estructura del sistema de archivos local del repositorio Git. También es posible abrir un editor de texto en los archivos:
De forma alternativa, los archivos se pueden abrir arrastrándolos desde el directorio de trabajo al área del editor.
Además, en todos los nodos de archivo y carpeta, así como en el nodo "Repositorio", se ofrece una opción para copiar la vía de acceso (específica del sistema de archivos) en el portapapeles. Esto a veces resulta útil cuando se necesita la vía de acceso, por ejemplo, para abrir un directorio utilizando un navegador de archivos o para copiar y pegar repositorios entre instancias de la vista (consulte la sección anterior sobre cómo añadir repositorios a la vista). La acción Copiar en portapapeles también está disponible utilizando Editar > Copiar (o el atajo de teclado correspondiente).
La integración con la vista "Propiedades" genérica en Eclipse permite ver y editar la configuración de Git (configuración global y específica del repositorio). Si la vista "Propiedades" está abierta, se actualiza automáticamente cuando se selecciona un nodo "Repositorio". Con un recuadro desplegable (recuadro rojo izquierdo en la captura de pantalla), puede conmutar entre la visualización de la configuración de repositorio, la configuración global y una vista que agrega las dos. Si la vista muestra la Configuración de repositorio o la Configuración global, puede abrir un diálogo de editor con el botón Editar (recuadro rojo derecho en la captura de pantalla). El diálogo del editor tiene la misma funcionalidad que la página de preferencias Equipo > Git > Configuración.
En la vista de repositorios Git, hay una acción Propiedades en el menú contextual, que abrirá un diálogo de configuración que permite editar la configuración del repositorio. Aquí, los pares de clave-valor se pueden añadir, cambiar o suprimir. El botón Abrir permite abrir el archivo de configuración de repositorio en un editor de texto.
El nodo "Remotos" para examinar y editar configuraciones remotos. Cada configuración remota tiene un nombre y una especificación de inserción, una especificación de captación, o ambas. Si se selecciona un nodo "Configuración remota" o cualquiera de sus hijos, la vista Propiedades mostrará un resumen de la configuración remota. En este ejemplo, hay una configuración remota denominada "origin" que solo tiene una especificación de captación, pero no hay ninguna especificación de inserción:
Se proporcionan acciones de menú para añadir, configurar y eliminar configuraciones remotas y especificaciones de captación e inserción.
Es posible ejecutar directamente la captación y la inserción (es decir, sin un asistente) en los nodos "Captar" e "Insertar" respectivos:
Tenga en cuenta que la operación de captación o inserción se ejecutará inmediatamente en un trabajo asíncrono; al finalizar obtendrá una ventana emergente de confirmación que muestra el resultado de la captación.
El nodo "Captar" contiene una llamada especificación de captación y el nodo "Insertar" contiene una llamada especificación de inserción.
Se crea una especificación de captación predeterminada cuando se clona el repositorio. Puede editar la especificación de captación con la entrada de menú Configurar captación.... Se abre un asistente. En la primera página puede editar el URI de captación. En la segunda página que puede determinar las especificaciones de referencia de captación, consulte Especificaciones de referencia de captación.
Puede crear o editar una especificación de inserción con la entrada de menú Configurar inserción.... Se abre un asistente. En la primera página puede editar los URI de inserción. Si se especifica una captación, el URI de captación se incluye automáticamente en la especificación de inserción y no se necesita ningún URI de inserción adicional. En la segunda página puede determinar las especificaciones de referencia de inserción, consulte Especificaciones de referencia de inserción.
Esto se lleva a cabo utilizando una acción de menú contextual en el nodo "Remotos". Se inicia un asistente para solicitar el nombre de la nueva configuración y si se debe configurar la captación, la inserción, o ambas:
Si se ha seleccionado el recuadro de selección Configurar captación, la siguiente página del asistente solicitará el URI del repositorio del que captar:
Pulse Cambiar... para abrir un diálogo que le permite seleccionar un URI. El siguiente paso es definir la especificación remota para el URI de captación. Consulte Especificaciones de referencia de captación para obtener los detalles.
Si se ha seleccionado el recuadro de selección Configurar inserción, la siguiente página del asistente solicitará los URI de los repositorios en los que insertar. Esto es realmente una lista, ya que se puede insertar a varios repositorios a la vez. Pulse Añadir.... para añadir los URI a la lista utilizando el mismo diálogo que más arriba. Puede eliminar los URI marcándolos en la lista y pulsando Eliminar. Este paso es completamente opcional si ya se ha definido un URI de captación. En este caso, el URI de captación también se utilizará para la inserción. Si se define al menos un URI de inserción en este paso, se alterará temporalmente el URI de captación. En este ejemplo, ya hay un URI de captación, por lo que el botón Siguiente está habilitado, aunque no hay ningún URI de inserción en la lista:
El paso siguiente es definir la especificación remota para los URI de inserción. Consulte Especificaciones de referencia de inserción para obtener los detalles.
Al finalizar, la nueva configuración remota será visible:
También es posible añadir, eliminar o cambiar especificaciones de captación/inserción para una configuración remota existente utilizando el menú contextual.
Si trabaja con Revisión de código de Gerrit como servidor de repositorio remoto, puede
Seleccionar Configuración de Gerrit... en el menú contextual de un remoto. Se abre un asistente con una página:
La vista se actualiza automáticamente de forma periódica. El botón Renovar de la barra de herramientas permite desencadenar una renovación inmediata:
Si el conmutador Enlazar con selección está habilitado, el archivo o la carpeta correspondiente a la selección del entorno de trabajo actual se visualizará automáticamente:
Si el conmutador Enlazar con editor está habilitado, el archivo o la carpeta correspondiente al editor activo actualmente se visualizará automáticamente:
Si el conmutador Diseño de ramificación jerárquica está habilitado, las ramificaciones se mostrarán en un diseño jerárquico utilizando la barra inclinada (/) como separador de jerarquías:
Esto puede ser útil para organizar un gran número de ramificaciones.
Los repositorios Git "vacíos" (en contraposición a los repositorios "de desarrollo" o "estándar") no tienen ningún directorio de trabajo por definición, por lo que todas las acciones relacionadas con el directorio de trabajo (reservar, importación de proyecto, examen del directorio de trabajo) no están disponibles para dichos repositorios. La calidad de vacío de un repositorio se visualiza en un nodo "Directorio de trabajo", que siempre es una hoja:
Los repositorios vacíos solo se cambian pulsando los cambios en ellos.
Se ofrece como una acción de menú en el nodo "Repositorio". Tenga en cuenta que esto no suprime el repositorio, sin que solo elimina el nodo de la vista. Si hay proyectos en el espacio de trabajo que se encuentran en el directorio de trabajo del repositorio, se solicitará al usuario que confirme la supresión de estos proyectos del espacio de trabajo de Eclipse.
El mandato Mostrar en > Historial abrirá la Vista de historial que muestra todos los cambios en el repositorio seleccionado.
El mandato Mostrar en > Reflog abrirá la Vista de registro reflog de Git que muestra el registro reflog de Git del repositorio seleccionado.
El mandato Mostrar en > Propiedades abrirá la Vista de propiedades que muestra las propiedades del repositorio seleccionado.
A partir de EGit 0.11 está disponible una primera integración con Mylyn para dar soporte a trabajar con repositorios de tareas.
Es necesario instalar la característica "EGit Mylyn" para utilizar la integración de EGit Mylyn. Esto requiere que también se deba instalar Mylyn.
Consulte la Guía del usuario de Mylyn para obtener más información sobre cómo trabajar con tareas.
El visor de compromisos de Egit permite que se abran los compromisos en el área del editor de Eclipse.
El visor de compromiso de EGit visualiza la siguiente información de compromiso:
Esto reserva el compromiso que se muestra en el visor de compromisos. El compromiso se reservará y HEAD se desconectará.
Aplica el cambio introducido por el compromiso que se visualiza en el visor de compromisos en la parte superior del compromiso o ramificación reservados actualmente.
El visor de compromiso se puede abrir desde los lugares siguientes:
EGit da soporte a la búsqueda de compromisos.
Los compromisos se pueden buscar en la pestaña Búsqueda de Git en el diálogo de búsqueda de Eclipse estándar.
Este diálogo da soporte a la búsqueda de texto o patrones presentes en los distintos campos de un compromiso de Git tales como el mensaje, la línea de autor, la línea de responsable del compromiso y los ID de SHA-1 del compromiso, sus padres y el árbol asociado al mismo.
Los resultados de la búsqueda de compromisos se muestran en la vista de búsqueda de Eclipse estándar. Los resultados se agrupan por repositorio cuando se está en la modalidad de árbol. Al efectuar una doble pulsación en un compromiso de la vista Buscar éste se abrirá en el visor de compromisos.
La página de búsqueda de Git se puede abrir seleccionando la opción de búsqueda de Git en el desplegable Buscar en la barra de herramientas de Eclipse.
EGit 1.0 tiene un diálogo Abrir compromiso Git parecido a los diálogos Abrir tarea y '''Abrir recurso''' principales de Mylyn. El diálogo busca en cada repositorio Git configurado la ramificación, el código o el compromiso SHA-1 especificados en el recuadro de filtro y muestra los compromisos coincidentes.
El diálogo se puede abrir seleccionando el botón Abrir compromiso de Git en la barra de herramientas de navegación de Eclipse.
EGit 1.0 da soporte a mostrar información de git blame dentro de la regla del editor.
Al seleccionar la acción Equipo > Mostrar anotaciones en las selecciones de archivos se abrirá el editor y visualizará una regla de anotación con un compromiso e información de autor para cada línea en un archivo. Al pasar el ratón sobre la regla se mostrará una ventana emergente que muestra el ID de compromiso, el autor, el responsable del compromiso y el mensaje del compromiso.
El aspecto de la regla del editor de anotaciones blame se puede configurar desde el submenú Revisiones disponible en el menú contextual de la regla.
Al seleccionar el hiperenlace SHA-1 en la ventana emergente se abrirá el compromiso en el visor de compromisos.
El soporte de submódulos en EGit/JGit se ha añadido en el release 1.3 que formaba parte de Indigo SR2 en febrero de 2011.
Puede leer más sobre los submódulos Git y cómo funcionan en este capítulo del libro de comunidad de Git.
Los submódulos son repositorios anidados dentro de un repositorio padre. Por lo tanto, al realizar un clon de un repositorio padre es necesario clonar los repositorios de submódulos para que los archivos/carpetas estén disponibles en el directorio de trabajo del repositorio padre.
Al seleccionar el botón Clonar submódulos en el asistente de Clonación de Git clonará todos los repositorios de submódulos después de que finalice la clonación del repositorio padre.
Hay un nodo Submódulos visualizados en la vista Repositorios Git para los repositorios que contienen submódulos.
Todos los submódulos del repositorio padre dado se muestran bajo este nodo, así como información sobre qué compromiso se ha reservado actualmente.
Puede añadir un nuevo submódulo a un repositorio seleccionando un repositorio en la vista Repositorios Git y seleccionando la opción de menú contextual Añadir submódulo.
El asistente solicitará la vía de acceso y el URL del submódulo que se añade. La vía de acceso especificada será relativa al directorio de trabajo del repositorio padre y el URL se utilizará para clonar el repositorio localmente.
Una vez completado el asistente, el submódulo se clonará, se añadirá al índice y el submódulo se registrará en el archivo .gitmodulos así como en el archivo .git/config del repositorio padre.
Hay dos acciones que se pueden utilizar para actualizar submódulos, Actualizar submódulo y Sincronizar submódulo.
Al seleccionar la acción Actualizar submódulo en un submódulo se reservará el compromiso al que se hace referencia en el índice del repositorio padre para dicho submódulo. Este mandato también realizará una fusión o reorganización si se ha configurado en el campo actualizar para la sección de configuración del submódulo seleccionado en el archivo .git/config del repositorio padre.
Al seleccionar la acción Sincronizar submódulo en un submódulo se actualizará el URL remoto utilizado por el submódulo del valor actual del archivo .gitmodulos en la raíz del directorio de trabajo del repositorio padre.
|
|
|
|
| Conceptos | Consulta |