-
Notifications
You must be signed in to change notification settings - Fork 4
HOME
Instalar extensión "Open Terminal Here" explicado en este documento https://goo.gl/O0k6IU para ahorrar tiempo en escribir la localización donde queremos que trabaje nuestro terminal.
Si quieres evitar que aparezca usuario como autor de tus subidas de código al repositorio, configura tu nombre y dirección de correo electrónicos
git config user.name "profeIAP"
git config user.email correoProfeIAP@correo.es
Si quieres comprobar tu configuración, lanza el siguiente comando para listar todas las propiedades que Git ha configurado
git config --list
EJEMPLO
$ git config --list
user.name=profeIAP
user.email=correoProfeIAP@correo.es
color.status=auto
Puedes comprobar qué valor tiene Git para una clave específica
git config {clave}
EJEMPLO
$ git config user.name
profeIAP
###¿Cómo corregir el usuario que ha realizado un commit?
Corregimos el nombre de usuario (y su correo electrónico) siguiendo los pasos que tenemos en el apartado de arriba.
Una vez hecho, lanzamos el siguiente comando
git commit --amend --author="carmen456 <carmen456@gmail.com>"
Donde:
- carmen456 es el usuario de github
- <carmen456@gmail.com> es la dirección de correo electrónico
NOTA: No olvides poner la dirección de correo electrónico entre los signos de mayor y menor.
Si alguna vez necesitas ayuda usando Git, hay tres formas de ver la página del manual para cualquier comando de Git
git help {comando}
git {comando} --help
man git-{comando}
EJEMPLO
$ git help commit
$ git add --help
$ man git-status
CUIDADO: cambia la dirección http por la de tu proyecto
git clone -b NOMBRE_RAMA https://github.com/profeIAP/panelDeControl
Donde NOMBRE_RAMA es la rama del servidor que deseas descargarte.
Si quieres probar cómo funcionaba el proyecto en alguna de las versiones anteriores deberás lanzar un
git checkout HASH_VERSION
Donde HASH_VERSION es el ID del commit (p.e. el 723420 de uno de los commits de nuestro repositorio) al que quieres "viajar" en el tiempo.
Los distintos HASH_VERSION puedes consultarlos directamente en el apdo. commits de nuestro GitHub (o lanzando un git log desde la terminal)
Para volver al "presente" (última versión existente del proyecto) deberás lanzar un
git checkout master
La forma más sencilla es lanzar
git pull
pues actualiza automáticamente los cambios sin necesidad de lanzar varios comandos. No siempre funciona: requiere que tus compañeros no hayan modificado el mismo fichero que tú (conflicto que debe ser resuelto manualmente)
Si no funciona el comando anterior deberás recurrir a:
git fetch # Pregunta si hay cambios en el servidor
git status # No necesario (es para ver qué ha cambiado)
git merge origin # Se trae los cambios (hasta que no lo hagas tienes tu código)
Ahora debes editar los ficheros que te indique GIT que tiene algún conflicto (ábrelos con el editor y busca las anotaciones que ha metido GIT)
git add .
git commit -m "Un comentario explicatorio de lo que hemos hecho"
git push origin master
Fusionar (merge) ficheros de texto no suele se complicado pero, cuando hablamos de ficheros binarios (como la base de datos o alguna imagen) da más problemas.
Ante una colisión de este tipo debemos plantearnos ¿qué fichero debemos dejar?
Si decides que el tuyo es el "bueno", lanza un:
git checkout --ours -- path/to/file.txt
Si el bueno es el subido por otro compañero, lanza un
git checkout --theirs -- path/to/file.txt
Donde path/to/file.txt es la ruta al fichero en conflicto.
Ejemplo: supongamos (será más habitual de lo que deseas) que
- insertas alumnos y/o partes desde la aplicación web. Dicha información se almacena en la BD (y por tanto, cambia el binario)
- Otro compañero crea una tabla nueva para guardar nuevos datos (tu base de datos no contendrá dicha tabla hasta que te actualices)
¿Qué "checkout" debes lanzar?
Parece claro que es más importante tener la nueva tabla a que se pierdan los datos que has introducido ¿no te parece?
En dicho caso, lanzaremos un git checkout --theirs -- model/dictados.db porque:
- Es más importante su fichero (--theirs)
- El fichero que ha colisionado es model/dictados.db (donde model es la carpeta donde tenemos la base de datos y dictados.db es el fichero que la contiene)
De utilidad (entre otros) cuando
- tengas código en tu equipo que no has clonado del repositorio "oficial" de tu grupo o
- quieras comparar vuestro trabajo con los ejemplos del profesor.
git remote add repoProfe https://github.com/USUARIO_GIT/NOMBRE_REPOSITORIO.git
Donde:
- repoProfe puede ser cualquier nombre que te ayude a identificar el repositorio u origin si se trata del repositorio de tu grupo de trabajo
- debes cambiar https://github.com/USUARIO_GIT/NOMBRE_REPOSITORIO.git por la url del repositorio que quieras referenciar
Imagina que quieres saber qué diferencias hay entre lo que está en tu equipo y algún repositorio (el de tu grupo de trabajo y/o el del profesor)
git diff master origin/master
Compara tu rama master (local) contra la rama master del repositorio de tu grupo de trabajo.
Para subir nuestro código a una rama del repositorio compartido usaremos un
git push origin NOMBRE_DE_TU_RAMA
Para descargar el código de una rama del servidor lanzaremos un
git checkout -t origin/NOMBRE_DE_TU_RAMA
Si nos hemos equivocado haciendo un commit (detectamos que hemos olvidado añadir y/o eliminar algún fichero, se ha introducido algún fallo, ...) y nos damos cuenta antes de hacer el push, podemos eliminar dicho commit sin perder los cambios que se hayan hecho en los ficheros lanzando un
git reset HEAD~1