java - oxygen - git pull eclipse

¿Debo almacenar el repositorio git en Home o Eclipse Workspace?

Question

Me estoy moviendo de svn a git, y estoy dispuesto a sentar algunas buenas bases.

Por defecto, Eclipse quiere almacenar mi repositorio local de clones en ~ / git. Me siento más cómodo manteniendo todos los datos para una tarea en el mismo espacio de trabajo, por lo que me inclino a mantenerlos en mi espacio de trabajo

¿Hay algunos pros / contras importantes que deba considerar?

No tengo la intención de hacer muchas bifurcaciones; realmente voy por la ruta de DVD principalmente para superar algunos problemas poco confiables de comunicaciones de Internet

Answer 1

Creo que es una buena idea almacenar el árbol de la versión git fuera del área de trabajo. De esta manera es posible separar proyectos de diferentes repositorios, pero aún así manejarlos en el mismo espacio de trabajo.

Además, si coloca el código fuera del área de trabajo, puede organizar sus proyectos jerárquicamente fuera del área de trabajo (en la copia de trabajo), pero aún ver la representación plana en Eclipse.

Answer 2

El .git debe estar donde está su árbol de trabajo (es decir, los archivos que representan la CABEZA actual de la rama actual en la que está trabajando)

Recuerde que con Git, las sucursales no son directorios (a diferencia de SVN), por lo que su árbol de trabajo representará directamente un contenido de sucursal, no varios directorios (para sus distintas sucursales), seguido de un contenido por sucursal.

Por lo general, me gusta mantener las fuentes de mi proyecto separadas de mi espacio de trabajo de Eclipse, pero eso es una cuestión de preferencia.

Answer 3

Estoy cambiando demasiado a Git en Eclipse y leyendo sobre este tema. Parece que la sabiduría actual (aunque no todos están de acuerdo) es:

• Acostúmbrate a NO tener tus proyectos debajo del directorio del área de trabajo.

• Tenga un repositorio de git para cada grupo de proyectos de eclipse relacionados (y quizás más archivos, por supuesto). El concepto de "proyectos relacionados" depende de su conveniencia [*]

• Para cada repositorio, un directorio de primer nivel para cada proyecto Java. Esto implica que tendrá un directorio .git/ y, en el mismo nivel, los directorios del proyecto.

Ejemplo: suponga que, "antes de GIT", tenía un espacio de trabajo de eclipse con varios proyectos:

/wk/workspace/.metadata/  
/wk/workspace/projXXX/  
/wk/workspace/projXXXtest/  (related with the previous)
/wk/workspace/projYYY1/     |
/wk/workspace/projYYY2/      >  three related projects
/wk/workspace/projYYY3/     |
/wk/workspace/projZ/        (a project you are not going to version in git)

Luego, creará dos directorios vacíos, uno para cada repositorio, por ejemplo:

~/repositories/XXX/ 
~/repositories/YYY/ 

y luego, con el nuevo diseño de GIT, tendrás:

/wk/workspace/.metadata/  
/wk/workspace/projZ/ 

~/repositories/XXX/.git/   (XXX related repository - non-bare)
~/repositories/XXX/projXXX/
~/repositories/XXX/projXXXtest/

~/repositories/YYY/.git/   (YYY related repository - non-bare)
~/repositories/YYY/projYYY1/
~/repositories/YYY/projYYY2/
~/repositories/YYY/projYYY3/

Eclipse (EGit) hace todo esto por usted cuando hace clic en Equipo-> Compartir sobre un proyecto existente y especifica (en el ejemplo) ~/repositories/XXX/.git/ como repositorio, ( ~/repositories/XXX/ como "Directorio de trabajo " , deje " Ruta dentro del repositorio "en blanco).

[*] Ten en cuenta que aquí, cada grupo de proyectos es, desde el punto de vista de Git, solo un conjunto de directorios dentro de un repositorio. Algunas implicaciones relevantes: en el ejemplo anterior, nunca tendrá en el espacio de trabajo de Eclipse dos ramas / versiones diferentes de proyectos projYYY1 - projYYY2 simultáneamente; y, por ejemplo, cuando etiqueta un compromiso de proyecto, en realidad está etiquetando el compromiso de repositorio completo (grupo de proyectos).