¿Es mejor mantener el repositorio de Git dentro o fuera del área de trabajo de Eclipse?

Question

Soy un usuario típico de Eclipse/Subversion que comienza la migración a Git. Investigué los conceptos básicos de git y decidí atenerme a un enfoque de proyecto por repositorio inicialmente para mantener las cosas simples. Todavía estoy teniendo problemas, sin embargo, decidir dónde colocar el repositorio para cada proyecto.

He pasado mucho tiempo revisando las respuestas al this question, aunque creo que el autor de esa pregunta asumió que solo puede usar Eclipse para administrar el repositorio si el repositorio está ubicado dentro del área de trabajo de Eclipse, que es por supuesto, no es cierto. Sin embargo, lo que más me llamó la atención fue el hecho de que todas las respuestas menos una (incluyendo la aceptada) sugerían mantener el repositorio dentro del área de trabajo de Eclipse, mientras que solo una respuesta indicaba que EGit User Guide exactamente lo contrario.

Sin embargo, en la práctica parecería que hay una serie de enfoques implementados por Eclipse/EGit, algunos de los cuales parecen contradecir las recomendaciones de EGit.

Por ejemplo, si utiliza el Asistente de proyecto nuevo para crear un nuevo Proyecto de PHP desde Git y el repositorio es remoto, Eclipse/EGit creará una carpeta de proyecto en el área de trabajo de Eclipse y colocará el repositorio (.git) la carpeta del proyecto. Este es el resultado final que realmente quiero, ya que mantiene todo encapsulado dentro del espacio de trabajo de Eclipse.

Sin embargo, si usa el Asistente para proyectos nuevos y selecciona un repositorio de Git que sea local, Eclipse/EGit no clona el repositorio como lo hace para los repositorios remotos. En su lugar, utiliza la copia de trabajo de ese repositorio como ubicación del proyecto, crea su .project y otras meta cosas en esa ubicación y también crea una nueva carpeta (aparentemente innecesaria) dentro de esa copia de trabajo con el mismo nombre que su proyecto (para que termine arriba con, por ejemplo, ~/git/blah/blah). Si elimina esa carpeta superflua, termina con una estructura idéntica al primer ejemplo, la única diferencia es que la carpeta del proyecto no es una subcarpeta de su carpeta de espacio de trabajo Eclipse, sino que está en otro lugar de su sistema de archivos (por ejemplo, ~/git/blah). Lo único positivo que parece tener este enfoque es que se adhiere a las recomendaciones de la Guía del usuario de EGit, pero desde una perspectiva técnica, es difícil ver cómo esto es realmente tan diferente al primer ejemplo.

Dadas estas observaciones desconcertantes, me pregunto qué tipo de experiencias han tenido las personas al usar cada uno de estos enfoques y cuáles podrían ser las dificultades si se ignoran las recomendaciones de la Guía del usuario de EGit.

Answer 1

Las implicaciones de ambas soluciones se enumeran directamente en la guía del usuario que ha vinculado. Puedo decir que la parte

Esto puede dar lugar a problemas de rendimiento

es por desgracia muy cierto. Entonces, si tiene un directorio git con una gran cantidad de archivos dentro de su área de trabajo, muchas operaciones git comenzarán con un diálogo "contando objetos ..." que bloquea su IDE porque escanea todos los archivos en el área de trabajo. Para mis archivos 20000 actuales, esto significa esperar de 10 a 20 segundos para cada confirmación, cada cambio, ...

En actividades de tiempo libre, donde afortunadamente puedo usar la otra alternativa (teniendo el directorio de trabajo git fuera del área de trabajo) todo se siente mucho más ágil y es divertido fusionarse y cambiar.

Así que si va para proyectos grandes, considere el directorio git fuera del área de trabajo como primera opción.

Answer 2

que estoy haciendo la misma migración como el cartel original y han encontrado otro hilo donde las mismas dudas se expresan en la recomendación Egit: Should I store git repository in Home or Eclipse Workspace?

@JamesG Así que este es su diseño?

~/projectA/workspace/.metadata 
~/projectA/workspace/subproj1/.project 
~/projectA/workspace/subproj2/.project 
~/projectA/subproj1/.git 
~/projectA/subproj1/file1 
~/projectA/subproj2/.git 
~/projectA/subproj1/file2 

Answer 3

¿Por qué no simplemente permite las 2 posibilidades.

Estoy bien para el caso de un gran proyecto que genera muchos archivos en la carpeta .metadata. Incluso si es bastante simple poner la línea .metadata en .gitignore para mejorar las actuaciones.

Pero en mi caso (desarrollo de Android), tengo alrededor de 35 proyectos diferentes que contienen solo 50 archivos.

Todos estos proyectos están en diferentes espacios de trabajo que contienen el proyecto de aplicación y los proyectos de bibliotecas para esta aplicación. (Un depósito de cartuchos por aplicación)

• Tengo que sólo tienen un espacio de trabajo con todos mis proyectos dentro (pasar tiempo a/proyectos de cierre/apertura de desplazamiento en el explorador de paquetes)?

• Debo gestionar 2 carpetas base diferentes (Proyectos y Espacios de Trabajo) y la última contiene solo las carpetas .metadatas de todos mis proyectos?

Para mí esto no tiene sentido.

mensaje al equipo EGit:

Por qué cambiar la forma en que los desarrolladores suelen organizar sus proyectos de carpetas:

---- Worspace

---- Worspace/.metada

----- Worspace/.git

----- Worspace/Project1

----- Worspace/LibraryProject1

----- Worspace/LibraryProject2

entiendo la razón por la actuación, pero tan sólo el 5% de los desarrolladores con proyectos muy grandes (generando gran .metadata) que acaba de no nos permite estructurar nuestros proyectos como Eclipse nos dice que hagamos desde hace años.

Podría justo, incluso si un mensaje nos advierte que es no es recomendable, no bloquee el proceso de clonación a la carpeta worspace ("C: \ Worspaces \ no es un directorio vacío")

EGit es una gran herramienta, pero realmente estoy pensando en usar el modo Bash debido a esta limitación
.

Gracias por su respuesta

PS: Hay muchos casos diferentes de Desarrollos bajo Eclipse. Si solo se trata de un problema de rendimiento y si no bloquea el EGit, avísenos al respecto, pero no nos bloquee en el caso de proyectos pequeños.