¿Desarrollarse en eclipse sin usar ningún plugin de git eclipse?

He estado usando SVN y Eclipse para el desarrollo por un time, y amo la fuerte integración entre los dos. Sin embargo, ahora estoy cambiando a git, y entiendo que mientras los plugins de git Eclipse como EGit han mejorado, todavía no son tan buenos como los plugins de SVN para Eclipse. (Por ejemplo, todavía no hay soporte de submodules, y planeo usar submodules extensivamente).

Me pregunto, ¿hay alguno de ustedes que usa Eclipse para el desarrollo en un proyecto de git pero no usa el plugin de Eclipse? Es decir, o bien utilizas otro cliente de GUI de git (estoy en Linux) o hago todo desde la línea de command. Si es así, ¿cómo funciona esto para usted?

¿Es un gran dolor no poder ver directamente en Eclipse qué files no están sincronizados con el repository, etc., o eso no es tan importante? ¿O aún puedo usar EGit solo para ver qué files han cambiado, pero realizar todas las confirmaciones y hacer todas las operaciones desde la command-line u otro cliente GUI? De ser así, cualquiera que lo haga puede describir cómo se vería ese flujo de trabajo.

¿Hay algún riesgo o problema relacionado con el acceso a un repository de múltiples clientes, como la command-line, EGit y múltiples clientes de la interfaz gráfica de usuario de git, como podría causar daños en el repository porque todos podrían cambiar los metadatos al mismo time? ¿O es perfectamente seguro?

Con SVN todo fue simple: nunca necesité la línea de command u otro cliente de GUI para nada. Todo fue posible dentro de Eclipse. Pero ahora me preocupa qué esperar, porque realmente no sé cómo esto cambiará mi estilo de desarrollo o si es factible. Ciertamente, con git siendo un popular VCS y Eclipse como IDE tan popular, hay muchos que usan ambos juntos y que pueden describirme cómo lo usan.

EGit jugará bastante bien con la herramienta git de línea de command. Yo uso ambos en Linux. Vale la pena instalar EGit, creo, y al less ver el estado de sus proyectos.

A veces tiene que usar F5-Refresh para actualizar la vista de EGit de su repository, pero EGit ya trabaja para actualizar el espacio de trabajo con los cambios de files locales, por lo que no aparece con tanta frecuencia.

La única otra sugerencia que tengo es que no querría que varios espacios de trabajo apuntaran al mismo repository git. Eso puede causar confusión.

No puedo hablar específicamente para git, pero solía hacer algo muy similar con SVN, y no puedo ver ningún problema al hacer esto. Además, al less con SVN y Subclipse, Subclipse trabajó con la copy de trabajo de SVN como lo haría cualquier otro cliente de SVN. Hay varias operaciones que todavía uso la herramienta de command-line svn para los mismos proyectos en los que estoy trabajando en Eclipse. Esto incluye cosas como "estado de svn", así como realizar actualizaciones por lotes de properties SVN a través de files (algo que Subclipse no admite en la actualidad). Aparte de necesitar usar F5 en Eclipse para realizar una actualización ocasional, nunca he tenido ningún problema con esto.

He hecho cosas muy similares con muchos otros sistemas de control de fuente, y nunca tuve ningún problema. Especialmente si solo usa un cliente externo y no se preocupa por la integración del control de código fuente en Eclipse para git, no veo que tenga ningún problema, ya que Eclipse no intentará compartir ninguna preocupación con esto. También recomendaría probar EGit, ya que supongo que funcionará de manera muy similar a Subclipse y no causará problemas importantes. (Espero hacerlo pronto).

En términos del flujo de trabajo, en muchos casos, al less para un desarrollador experimentado, esto debería funcionar mejor en algunos casos. En Eclipse, a menudo me encuentro cambiando entre las vistas de Explorador de packages y Navegador para ver todos los files que Eclipse oculta o traduce por defecto en la vista del Explorador de packages. El cambio entre Eclipse y otro cliente realmente no funciona de manera diferente.