Eclipse + Java sobre repositorio Git
De vez en cuando me da por practicar mi oxidado Java. Voy a hacer un pequeño programa para monitorizar los equipos de mi red casera utilizando Java y snmp. Me gusta guardar mis proyectos de desarrollo en mi servidor git privado (basado en gitea
). En este apunte describo el proceso de creación de un repositorio git, un Proyecto Java con Eclipse y cómo los conecto entre sí. Si usas GitHub el proceso es idéntico, aunque visualmente las opciones cambien un poco respecto a gitea.
Encontrarás un par de apuntes sobre GIT en este blog, si quieres profundizar y entender git de verdad, te recomiendo GIT en detalle y la Chuleta sobre GIT. Si te interesa como montar Gitea en tu red casera, aquí y aquí también te dejo un par de apuntes. |
Preparar SSH en tu ordenador
Antes de nada, con mi servidor gitea
uso SSH para clonar los repositorios, así que es importante tenerlo bien configurado. Si usas GitHub te recomiendo hacer exáctamente lo mismo.
- Ya lo tenía hecho, pero explico cómo creé mis claves público/privada. Nota: en mi caso las salvé con el nombre
id_gitea
- La contraseña que nos pide vamos a necesitarla más adelante al hacer el clonado y/o conexión con el servidor
gitea
.luis@idefix ~ $ ssh-keygen -t rsa -b 2048 :
- Se crearon dos ficheros, uno con la clave privada (
id_gitea
) y otro con la clave pública (id_gitea.pub
), que es la que se puede compartir. Nunca compartas la privada.➜ ~ ls -1 .ssh/id_gitea* .ssh/id_gitea <== NO COMPARTIR NUNCA .ssh/id_gitea.pub <== Compartible en github, gitea...
- Por último, en mi usuario de gitea copio/pego el contenido del fichero
id_gitea.pub
como una clave nueva en el servidor gitea.
Nota: Si quieres trabajar con ssh con github tiene que hacer lo mismo en github.com, añadir tu clave publica como una de las claves aceptadas para trabajar vía ssh, lo encontrarás en Logo de tu usuario > Settings > SSH and GPG keys |
Preparar .gitconfig
en tu ordenador.
- Tanto si vas a hacer clonados desde la línea de comandos como desde aplicaciones (por ejemplo Eclipse), es conveniente que prepares el fichero
.gitconfig
en la raiz del carpeta del usuario. Al menos debería tener los camposname
yemail
configurados$ cat $HOME/.gitconfig [user] name = Luis Palacios email = mi.correo.electrónico@dominio.com
Lo puedes hacer en Eclipse desde Preferences > Version control > Git > Configuration
Eclipse
Antes de nada, unos conceptos para entender mejor dónde se guardan los proyectos con Eclipse y qué cambia cuando usamos Git. Hay muchas maneras de organizar los proyectos y los flujos de trabajo, y Eclipse es lo suficientemente flexible a la hora de organizar o ubicar las cosas.
- Workspace de Eclipse: Básicamente, un “Workspace” es una “colección de proyectos y configuraciones”. Al crearlo estamos creando una carpeta en el disco que contiene una única sub-carpeta llamada
.metadata
(almacena la configuración del workspace y la lista de proyectos vinculados). Es algo así como unpuntero a una lista de proyectos
. - Projecto Eclipse: Para poder realizar un programa es necesario crear un proyecto. Un Proyecto agrupa a un conjunto de recursos relacionados entre sí (código fuente, diagramas de clases, binario, documentación). Nota: con el plugin adecuado puedes crear proyectos en Ada, ABAP, C, C++, C#, Clojure, COBOL, D, Erlang, Fortran, Groovy, Haskell, JavaScript, Julia, Lasso, Lua, NATURAL, Perl, PHP, Prolog, Python, R, Ruby (Ruby on Rails), Rust, Scala, y Scheme.
- Repositorio Git: Eclipse sabe de Git. Permite crear un repositorio, clonar/conectar con uno remoto (github, gitlab, gitea) y por supuesto ejecutar cualquier comando git.
- Un repositorio Git no es un proyecto Eclipse en sí pero sí que puedes crear/mover un Proyecto Eclipse dentro del repositorio Git (de su carpeta).
- Antes hay que crear el repositorio Git y se puede hacer de varias formas.
- Creando una carpeta en el disco en cualquier sitio e inicializandola (por ejemplo con
git init
desde la línea de comandos). - Desde Eclipse con
File > New > Other > Git > Git Repository
que crea la carpeta y la inicializa como repositorio. - Pero el que recomiendo usar siempre es al contrario: Crear un repositorio desde github, gitlab o gitea y clonarlo en nuestro ordenador. El motivo es que tenemos el repositorio remoto, el respositorio local (clon) y han quedado vinculados.
- Creando una carpeta en el disco en cualquier sitio e inicializandola (por ejemplo con
- Proyecto Eclipse “dentro” de Repositorio Git: Es el proceso de vincular ambos. En realidad consiste en mover la carpeta del Proyecto Eclipse dentro de la carpeta del repositorio git.
Preparar Eclipse para Git
- Primero configuro GIT en Eclipse. Entro en sus
Preferences > Git
. Aquí hay dos puntos importantes. El primero es indicar cual es la carpeta raíz a partir de la cual voy a dejar mis proyectos clonados desde el servidor git. El segundo es pedirle a Eclipse que salve las contraseñas que me vaya pidiendo.
Tendremos dos carpetas importantes:
- Workspace principal de Eclipse:
/Users/luis/eclipse-workspace
- Carpeta para repositorios Git (clones):
/Users/luis/0_priv/prog/gitea-luispa/palas
La Carpeta para repositorios Git (clones) es una carpeta cualquier que dedicas en tu ordenador a tener tus proyectos de desarrollo, no tiene nada que ver con Eclipse, en mi caso uso siempre la misma independiente del IDE que emplee.
Proyecto Eclipse “dentro” de repositorio Git
Veamos el proceso de meter un Proyecto Eclipse dentro de la carpeta de un Repositorio git.
- Crear un repositorio en github, gitlab, o en mi caso en
gitea
(lo llamaréquidomi
). - Hacer un clonado en mi ordenador (en la carpeta donde tengo todos mis programas “clonados”)
/Users/luis/0_priv/prog/gitea-luispa/palas/quidomi
- Crear un Proyecto Eclipse en el workspace. Lo llamaré
QuiDomi
./Users/luis/eclipse-workspace/QuiDomi
- Vicular el Proyecto con el Repositorio Git.
1. Crear el repositorio quidomi
en gitea
Lo primero es crear el repositorio para mi pequeño proyecto en Java. Accedo a mi servidor gitea
y sigo los pasos para su creación.
Defino los parámetros necesarios
Una vez creado ya tengo acceso a la URL que usaremos más adelante para hacer el clonado.
- Recuerda la URL para poder hacer el clonado. Selecciono
SSH
. El usuario (la parte a la izquiera de la@
) siempre debe sergit
.
git@git.parchis.org:palas/quidomi.git
2. Hacer un clonado de quidomi
- Muestro la ventana de trabajo con GIT desde
Window > Show View > Other > Git Repositories
y pulso enClone a Git repository
- Pongo la URL de mi repositorio y dejo el resto de opciones sin cambiar.
- Introduzco la contraseña que use al crear mis claves pública/privada SSH.
- Este paso es opcional, decide qué hacer en tu caso
- No cambio nada, me interesa descargar la rama principal (
main
)
- No cambio nada, pero verifico que efectivamente va a crear un sub-carpeta en el sitio correcto. Recuerda que cambié mis preferencias para que todos los proyectos que clone desde un servidor git residan bajo
.../palas
- Ya tenemos nuestro proyecto, repositorio git, activo en el IDE de Eclipse.
3. Crear el Proyecto Eclipse QuiDomi
.
Nota: Este proyecto se va a ubicar en una sub-carpeta en el workspace. Cuando lo vinculemos al repositorio Git se moverá. |
- Ya puedes empezar a trabajar con tu Proyecto, pero se quedará todo en local, hasta que lo vincules / muevas debajo de la carpeta del repositorio Git local (clonado). En este ejemplo he creado un simple “Hola, mundo!”.
4. Vincular el Proyecto con el Repositorio Git.
En el Proyecto Eclipse QuiDomi
me voy a “Team > Share Project” y selecciono el repositorio Git quidomi
que creé en el paso 1. Lo que va a ocurrir es:
- El Proyecto se “mueve” (la carpeta entera del proyecto) debajo de la carpeta del repositorio.
- En el workspace seguimos teniendo el puntero al proyecto (aunque físicamente se ha movido su contenido)
- A partir de este momento ya podemos trabajar desde Eclipse en “modo git” con este proyecto/programa, hacer commits, etc..
- Una vez que pulsas en Finish ocurren un par de cosas, la primera es que la carpeta del Proyecto,
QuiDomi
que estaba en el workspace, se mueve debajo de la carpeta del repositorio:
+---- /Users/luis/eclipse-workspace/QuiDomi
|
+----> /Users/luis/0_priv/prog/gitea-luispa/palas/quidomi/QuiDomi
➜ palas> ls -al quidomi
total 24
drwxr-xr-x@ 7 luis staff 224 29 nov 17:05 .
drwxr-xr-x@ 20 luis staff 640 29 nov 17:05 ..
drwxr-xr-x@ 11 luis staff 352 29 nov 16:46 .git
-rw-r--r-- 1 luis staff 303 29 nov 16:46 .gitignore
-rw-r--r-- 1 luis staff 1078 29 nov 16:46 LICENSE
drwxr-xr-x@ 8 luis staff 256 29 nov 17:05 QuiDomi <=== !!!
-rw-r--r-- 1 luis staff 176 29 nov 16:46 README.md
➜ palas> tree quidomi
quidomi
├── LICENSE
├── QuiDomi <=== !!!
│ ├── bin
│ │ ├── QuiDomi
│ │ │ └── QuiDomi.class
│ │ └── module-info.class
│ └── src
│ ├── QuiDomi
│ │ └── QuiDomi.java
│ └── module-info.java
└── README.md
5 directories, 6 files
Lo segundo que ocurre es que empiezas a tener feedback visual. Observa cómo aparecen unas pequeñas “mochilas” indicativas en los iconos de las carpetas, son símbolos que nos indican el estado dentro del repositorio git
Trabajar en el proyecto y hacer stage/commits/push
- Hacemos modificaciones, compilamos, verificamos que funciona
- Decidimos que queremos subir los cambios al servidor git.
- Iniciamos el proceso de
commit
- Primero paso las modificaciones al área de preparación (
staging area
) - en local - A continuación ejecuto el
commit
- seguimos en local - Por último hacemos un
push
- enviamos a remoto (servidor gitea).
- Primero paso las modificaciones al área de preparación (
Empiezo haciendo una modificación simple, compilando y comprobando…
Decido iniciar el proceso de commit (mediante la opción Team > Commit
)
Reviso los “Unstaged Changes”. Es decir, qué ficheros todavía no están en el area de intercambio (staging area).
Solicito que se muevan esos ficheros a la Staging area
Escribo el mensaje de commit y pulso en Commit & Push.
Compruebo en mi servidor gitea
que se han recibido los cambios.
Nomenclatura GIT
Os dejo aquí una pequeña chuleta sobre la nomenclatura git. Recuerda que tengo por aquí un par de apuntes más sobre GIT en detalle y la Chuleta sobre GIT. |
Inglés | Español | Descripción |
---|---|---|
staging area | área de preparación | Es una zona intermedia (dentro de la sub-carpeta .git dentro de la carpeta del repositorio). Es el sitio donde se van preparando archivos a la espera del ser usados en el siguiente commit |
index | índice | Es la lista de todos los archivos que se consideran ya preparandos a los que hacemos seguimiento y están en la staging área (entre tu working copy y el futuro commit). |
working copy | directorio de trabajo | Es el directorio completo de tu proyecto, la parte no controlada por git, es decir, todos los ficheros y directorios que están fuera del subdirectorio .git |
commit | confirmar, comprometer | Consiste en dar por bueno lo que tenemos en el Staging Area y pasarlo a un estado de “confirmado”, identificándolo con un puntero numérico (hash del commit). Junto con sus antepasados conforman una instantánea o versión de tu proyecto. |
branch | rama | Es un nombre que actúa como puntero a un commit concreto dentro de tu repositorio .git |
clone | clonar, copiar | Consiste en traerme a local un repositorio remoto completo, creando un duplicado del mismo para poder trabajar en él. |
fetch | traer | Pedimos la última información de un remote, sin transferencia de archivos. Sirve para comprobar si hay algún cambio disponible. |
merge | fusión | Comando que realiza una fusión a tres bandas entre las dos últimas instantáneas de cada branch y el ancestro común a ambas, creando un nuevo commit con los cambios mezclados |
pull | tirar | Comando que para extraer y descargar contenido desde un repositorio remoto y actualizar al instante el repositorio local para reflejarlo. En realidad no es más que un git fetch segido de un git merge |
push | empujar | Se usa para cargar contenido desde mi repositorio local hacia un repositorio remoto. El envío es la forma de transferir commits desde tu repositorio local a un repositorio remoto |