metadatos y espacio de trabajo
I que está Nunca comparto la carpeta .metadata. De hecho, a menos que tenga un motivo en particular, ni siquiera compartiría la carpeta del espacio de trabajo, sino que compartiría cada proyecto por separado con git. De esa manera la carpeta .metadata siempre estará en la carpeta principal de su repositorio Git y usted no tiene que pensar si lo que necesita hacer caso omiso de todos modos:
|-- workspace/
| \-- .metadata/
| |-- yourProjectOne/
| | \-- .git/
| | |-- .project
| | |-- src/
| | |-- ...
| |-- yourProjectTwo/
| | \-- .git/
| | |-- .project/
| | |-- src/
| | |-- ...
proyecto específico
probablemente debería siempre comparta el archivo .project y nunca .settings/. El .classpath puede depender de su entorno pero tampoco le sugiero que lo comparta, ya que puede causar conflictos (por ejemplo, si un usuario usa openjdk y el otro usa sun-jdk.El .settings contiene preferencias y configuraciones para eclipse y cambia mucho, por lo tanto, no se debe compartir. Si importa correctamente el proyecto después de haberlo clonado desde git, tampoco tendrá ningún problema.
Los eclipse documentation indica lo siguiente acerca del archivo .project:
La finalidad de este fichero es hacer que el proyecto de auto-descripción, por lo que un proyecto que se subió la cremallera o se libera a un servidor puede ser correctamente recreado en otro espacio de trabajo.
y:
Si se crea un nuevo proyecto en una ubicación que contiene un archivo de descripción proyecto existente, el contenido de ese archivo de descripción se ser honrados como la descripción del proyecto. Una excepción es que el nombre del proyecto en el archivo se ignorará si no coincide con el nombre del proyecto que se está creando. Si el archivo de descripción en el disco es inválido, la creación del proyecto fallará.
También se sugiere utilizar Maven ya que esto le ahorrará un montón de problemas con la gestión de la dependencia y .classpath
Maven
La principal diferencia con un proyecto Maven es que pueda importar el proyecto como Maven -> "Proyectos Maven existentes" y, por lo tanto, solo es necesario compartir el archivo pom.xml y .project en git. Eclipse creará automáticamente los archivos .classpath, .settings/ automáticamente. Por lo tanto, obviamente no necesitas compartirlos. Si algo cambia en pom.xml, simplemente ejecuta Maven -> "Actualizar configuración del proyecto" y Maven -> "Actualizar dependencias".
Sin Maven
Usted debe compartir el archivo .project y no la carpeta .settings/. Puede considerar compartir .classpath, pero puede generar conflictos tal como se explicó anteriormente. Yo sugeriría no compartirlo tampoco. Utilice el método siguiente para importar el proyecto:
Después de haber clonado el repositorio git puede simplemente usar Importación -> Eclipse "Proyecto existente de espacios de trabajo" honrará el archivo .project pero recrea los archivos .classpath y .settings/. Después de la importación, deberá configurar el classpath a mano desde Eclipse (y cada vez que su equipo quiera usar otra biblioteca).
Si no comparte el archivo .project, no es posible importar el proyecto con Eclipse. Primero tendrá que crear un nuevo proyecto con el asistente del proyecto, y luego puede elegir importar "General-> Sistema de archivos", esto copiará todos los archivos en su espacio de trabajo. Esto probablemente no es lo que quieres, porque significa que no puedes clonar el repositorio de git en el espacio de trabajo, debes clonarlo en otro lugar y luego importarlo desde allí. Por lo tanto, siempre debe compartir el archivo .project.
Por favor, deje un comentario si tiene sugerencias para esta explicación o si no está de acuerdo con ella. Espero que esto ayude a uno u otro.
¿Tengo entendido que está almacenando todo el espacio de trabajo de Eclipse en un único depósito de Mercurial? ¿Ha considerado almacenar cada proyecto en un repositorio, y luego agrupándolos como subrepositorios de un repositorio paraguas para que pueda versionarlos juntos (aunque no sé si Eclipse tiene algún soporte para eso)? –
Es un producto basado en complementos, y cada uno de los proyectos define el complemento. Todos son necesarios juntos o el producto en general. Entonces, los proyectos individuales son solo una parte del todo, y es por eso que deseamos almacenar todo el espacio de trabajo de Eclipse en un único repositorio. –