En una entrada anterior del blog, le presentamos Git (un sistema de control de versiones) y Github (un servicio de alojamiento basado en la nube) y cómo puede compartir su código 4D con otros desarrolladores. En esta entrada de blog, iremos un poco más allá explorando algunos escenarios que un desarrollador puede encontrar, como clonar un repositorio remoto, ignorar archivos ya confirmados y resolver conflictos de fusión.
Requisitos previos
Antes de continuar, asumimos que sabes cómo crear una base de datos de proyectos o convertir una base de datos binaria en un proyecto. Es obligatorio tener Git instalado en tu máquina y una cuenta en Github. Si aún no los tienes, consulta esta entrada del blog para saber cómo proceder.
Clonar un repositorio remoto
Es hora de retomar el trabajo en nuestra aplicación. Pero por alguna razón, no tienes en tu máquina el proyecto en el que trabajamos la última vez. ¿Qué hacer?
Como hemos creado un repositorio en GitHub(entrada anterior del blog), existe como repositorio remoto. Ahora tenemos que crear una copia local en nuestra máquina y sincronizar entre las dos ubicaciones. ¿Cómo proceder?
- Conéctate a tu cuenta de Github,
- Navega a la página principal del repositorio,
- Haz clic en el botón«Clonar o descargar«, y luego haz clic en el icono del portapapeles (como se muestra en la imagen de abajo):
- Abre un terminal e indica la ubicación donde quieres clonar el directorio
- Escribe git clone y pega la URL que has copiado en el paso 3.
¡Enhorabuena! Has creado una copia local en tu máquina.
gitignore
No quiero que git rastree un archivo o carpeta en particular
A veces, tenemos archivos o directorios en nuestro proyecto que no queremos que sean rastreados. Ahí es donde un archivo .gitignore resulta útil. Como su nombre indica, indica a Git qué archivos, directorios o patrones debe ignorar en el repositorio.
En nuestro caso, queremos que Git ignore la carpeta Data (que contiene el diario, las preferencias, .4dd y la carpeta DerivedData ).
- Crear .gitignore
- Configurar los archivos/carpetas ignorados
.gitignore utiliza patrones globbing para comparar los nombres de los archivos. Puedes construir tus patrones usando varios símbolos. Por ejemplo, para ignorar una carpeta, añadimos una barra al final del nombre de la carpeta. Puede consultar este artículo para aprender más sobre los patrones .gitignore.
Ignorar archivos que ya han sido confirmados en el repositorio
Tenga en cuenta que cuando crea un nuevo repositorio, también debería crear un archivo . gitignore para cualquier patrón de archivo que quiera ignorar. Sin embargo, hay ocasiones en las que se cuelan archivos que luego quiere ignorar.
Que no cunda el pánico. En unos pocos y sencillos pasos, puede limpiar su repositorio y asegurarse de que estos elementos son ignorados:
- Prepara los archivos para su eliminación, pero déjalos en el lugar: git rm -r –cached
- Inspecciona todo el directorio de trabajo en busca de archivos nuevos, borrados o modificados y añádelos al índice: git add
- Enviar los archivos del área de preparación al repositorio local: git commit -m «Clean up ignored files»
- Enviar los cambios al repositorio remoto: git push
Ya está. ¡Puedes verificar en el repositorio remoto y que los archivos no están allí!
Nota importante: Los archivos ignorados permanecen en el historial del repositorio. Por eso, al crear nuevos repositorios, debes crear también archivos .gitignore indicando todos los archivos, carpetas o patrones que quieras ignorar. De lo contrario, si no quieres que ciertos archivos se mantengan en el historial, tendrás que eliminar el repositorio de Github y empujarlo de nuevo.
Cómo resolver los conflictos de fusión
En primer lugar, ¡mantenga la calma!
Cuando varios desarrolladores trabajan en el mismo sistema de control de versiones, la gestión de posibles conflictos se convierte en una tarea cotidiana. Hay varias opciones disponibles. El conflicto puede resolverse fácilmente usando el editor 4D, pero como todos los archivos están ahora basados en texto, también podría usar un editor de texto para resolver los conflictos manualmente. Además, hay muchas herramientas de fusión disponibles que pueden integrarse en GIT. En el ejemplo siguiente, estamos utilizando el editor 4D para resolver los conflictos.
Echemos un vistazo a un conflicto utilizando el método 4D. Para ello, es necesario simular un usuario secundario / repositorio git local duplicando la carpeta de la base de datos y asegurándose de que tiene al menos un método de proyecto. Ahora hay dos carpetas de base de datos: my4DApplication y my4DApplication2. A continuación, abre las dos aplicaciones.
-
- Abre el método de proyecto en la primera aplicación, y añade algún contenido (un comentario, por ejemplo).
- Si ejecutas git status, se detectarán los cambios en el método. Confirma y empuja los nuevos cambios.
- Escenario: otra persona modifica el mismo método, al mismo tiempo . Simulemos esto abriendo el mismo método en la segunda aplicación y modificándolo con un comentario diferente.
- Confirmar y empujar los nuevos cambios. Como puedes ver, el push es rechazado y se sugiere un pull en su lugar:
- Ejecutar el git pull sugerido no ayuda:
- Abre el método de proyecto en la primera aplicación, y añade algún contenido (un comentario, por ejemplo).
¿Y ahora qué?
Abre el método con el conflicto. La línea con Head indica los cambios locales y la línea en rojo indica el número del commit hecho por el otro usuario.
Resolver el conflicto es fácil, simplemente selecciona las partes correctas del código y empuja los cambios. En este caso, mantengo los dos mensajes de ALERT con diferentes comentarios:
Una vez hecho esto, el otro usuario puede ejecutar git pull para obtener los nuevos cambios. Ambos usuarios tienen ahora el mismo contenido en el método.
Para evitar conflictos en primer lugar
No hay una forma segura de evitar conflictos todo el tiempo, pero ejecutar git fetch puede ahorrarte un montón de dolores de cabeza por la fusión. Comprueba si el repositorio remoto tiene nuevos commits. No hacerlo antes de intentar empujar causó el error [Rechazado].
Para concluir
En este post, hemos discutido diferentes escenarios que un desarrollador puede encontrar cuando trabaja con Git. En un próximo post, nos alejaremos de la línea de comandos y mostraremos cómo utilizar un cliente de interfaz gráfica para trabajar con Git.