Mi media center - Foro

Si exactamente ese ea el ejemplo..

Entonces a menos que nuestro dios particular de git diga lo contrario xDDD, yo creo que a ti no te afectaría.

SeiTaN escribió:Entonces a menos que nuestro dios particular de git diga lo contrario xDDD, yo creo que a ti no te afectaría.

Dios no lo se pero un servidor si q tiene dudas de no te vaya a afectar.

¿Que son los conflictos y cuando se producen?
Un conflicto en git es la inconsistencia de un fichero por haber sido modificado simultaneamente desde dos puntos distintos del historial.

Caso 1:
Siguiendo el ejemplo de Seitan en el punto 3 dice q Jesus realiza cambios q integra en develop despues de q tu comenzaras a desarrollar en tu rama "media-server" (punto 2). Si alguno de los ficheros q tu modificas en esa rama ha sido tb modificado por Jesus, en el momento de crear la PR (punto 4) te informara d q hay un conflicto y d q no se pueden mergear las ramas.
Resolucion Caso 1 En este caso lo q deberias de hacer tu es:

• Traerte a tu develop local los ultimos cambios de la rama develop de Jesus (comando fetch+merge+push)
• Situarte en tu rama "media-server" (comando checkout)
• Intentar mergear con la rama develop. En este momento los conflictos estaran en tu local y no podras mergear. Es hora de resolver los conflictos (mas abajo indico como)
• Una vez solucionados los conflictos y mergeadas las ramas ya podras hacer la PR.

Caso 2:
Supongamos un proyecto que avanza con varias ramas en paralelo (como pelisalacarta ahora mismo). Tenemos la rama develop donde Jesus va incorporando los cambios y 2 colaboradores (Pedro y Pablo) han hecho sendas PR que modifican ambas un fichero en comun. Cuando Pedro hace su PR no hay conflictos (bien!!!) por q Jesus no ha tocado nada desde el punto en el que Pedro comenzo su desarrollo (al contrario q en el caso anterior). Dos dias despues Pablo tb hace una PR y tampoco hay conflictos, ya que Jesus aun no ha aceptado (merge) la PR de Pedro aun.
Jesus esta encantado con la propuesta de Pablo y acepta su PR (mergea sin problemas). Tb le gusta los cambios propuestos por Pedro, pero cuando va a mergearlo se encuentra de que ahora si hay un conflicto. ¿Como es posible si cuando Pedro hizo su PR no lo habia? Sencillo, recordar q ambas PR modificaban un fichero en comun. Por lo tanto el fichero q ahora hay en develop no es el q Pedro tenia como origen cuando comenzo a trabajar.
Resolucion Caso 2 En este caso Jesus avisara a Pedro de q ahora hay un conflicto q Pedro ha de solucionar:

• Traerse a su develop local los ultimos cambios de la rama develop de Jesus (comando fetch+merge+push)
• Situarse en la rama donde este su desarrollo (comando checkout)
• Intentar mergear con la rama develop. En este momento los conflictos estaran en su local y no podra mergear. Es hora de resolver los conflictos (mas abajo indico como)
• Una vez solucionados los conflictos y mergeadas las ramas, al hacer commit se actualizara la PR y Jesus podra aceptarla.

Lo que quiero q entendais es q siempre la persona q envia la PR es la resposable de solucionar los conflictos. Por otro lado es logico, si mi codigo entra en conflicto quien lo va a entender mejor q yo para solucionarlo

La teoria es muy bonita, pero como los resuelvo
Como ya he dicho un conflicto es cuando un archivo tiene dos modificaciones y git no sabe con cual quedarse. Personalmente, como ya he comentado otras veces, utilizo Sourcetree, y aunque incluye un gestor de conflictos prefiero utilizar Kdiff3 que se integra perfectamente. Es un proyecto open source y aunq este algo parado, he probado otros y es el q mejor me funciona.
Similar a un editor, cuando lo abres ves las dos versiones en conflicto y solo has de navegar por las diferencias e ir seleccionando con cual te quedas.

Mas alla de los conflictos
Habria un tercer caso aunque no es un realmente un conflicto y git no lo va a indicar tampoco. Supongamos nuevamente el caso 2. Ya hemos solucionado los conflictos y por fin Pedro avisa a Jesus de q ya no hay conflictos. Pero Pedro no ha vuelto a comprobar que su codigo funcione y resulta que los cambios introducidos por Pablo han eliminado (o modificado) un archivo con el q Pedro contaba (un import por ejemplo). En este caso Pedro, Pablo y Jesus deberan debatir si volver a incorporar el archivo borrado o hay otra manera de q el codigo de Pedro funcione. Pero nuevamente deberia ser Pedro el q modificara el codigo incluido en el PR

PD: Espero no haberle causado a nadie un conflicto por la longitud del post

Muchas gracias "Git God", veo que estaba equivocado

Me has resuelto las dudas, esto es como las copas, el último paga lo que falta de la cuenta xDD.

He actualizado sourcetree y la opción de "fetch", solo está disponible si pulso botón derecho sobre "servidor remoto" y no directamente sobre la rama.

Tengo que mirar que usar, me mola winmerge pero solo sirve como comparador, no vale como merge tool.

Saludos.

Seitan prueba kdiff3 verás q es muy sencillo y efectivo.

Oftopic:
A mi la última actualización de sourcetree no me gustaba y volví a la versión anterior (no recuerdo el número). Utilizó gitflow y con la versión nueva no me funcionaba correctamente.

Yo uso gitflow con SourceTree y la verdad es que me va muy bien... pero hay muchos conceptos de GIT que todavía no tengo muy claros... espero poco a poco ir aclarándome mas...

Yo trabajo de la siguiente forma:

• 1. Antes de empezar una modificación actualizo mi rama develop a la oficial
  2. Uso GitFlow para crear una nueva rama partiendo de develop ("feature/lo que sea")
  3. Hago los cambios oportunos, y creo un commit a la nueva rama
  4. Creo el Pull Request

Pero a veces, me encuentro que cuando voy ha hacer el Pull Request, la rama develop ha sido actualizada (nuevos commits) y hay conflictos, y a partir de aquí no se cual es la manera mas correcta de actuar, yo hago lo siguiente (que me ha funcionado)

• 1. Creo un patch.diff de mi commit
  2. Elimino mi commit
  3. Actualizo la rama "feature/lo que sea" con los últimos commits
  4. Intento aplicar el patch.diff creado corrigiendo los conflictos para que me deje aplicarlo
  5. creo de nuevo el commit
  6. Creo el Pull Request

Mi duda:
Hay alguna forma mas automática de actualizar mi rama "feature/lo que sea" quedando mi commit arriba del todo para después corregir los conflictos?

Porque si yo actualizo la rama con los últimos commits (encima del mio), modifico los conflictos y creo un nuevo commit, también funciona, pero luego al crear el pull request, salen todos los commits como si se tratase de modificaciones mías, cuando no lo son...

No se si me he explicado bien...

divadr escribió:Porque si yo actualizo la rama con los últimos commits (encima del mio), modifico los conflictos y creo un nuevo commit, también funciona, pero luego al crear el pull request, salen todos los commits como si se tratase de modificaciones mías, cuando no lo son...

No acabo de entenderte.
Te adjunto un doc con capturas reproduciendo el caso 1.
Miratelo y lo comentamos

como te lo has currado!!!

creo que ahora ya lo tengo mas claro!

Pues yo reconozco que como robalo, a menudo me mareo con todo esto

Pero sí que es verdad que después de asimilar la documentación que me pasó super_berny, especialmente este vídeo que me lo he visto un montón de veces, tengo el hábito de abrir SourceTree y crear un repositorio de git antes de empezar un nuevo proyecto.

https://www.youtube.com/watch?v=QnkiKrruJiE

Sólo subo a un repositorio remoto aquellos que lo requieren (como los de github o los proyectos donde el cliente me pone un servidor de git donde quiere las entregas), y el resto se quedan en un git local.

Lo del Gitflow sin embargo no lo veo, creo que sólo tiene sentido para cierto tipo de proyectos.

Recuperando el hilo original, he estado probando la versión mediaserver de divadr y yo creo que se puede hacer el merge con el master.

Si hay algo que no funciona, en la propia versión HTML o en las otras, lo arreglamos. Pero así podríamos incluirlo ya en la próxima versión

A partir de ese punto me gustaría que me indicaras por dónde ves mejor integrar los otros frontales (rss, wiimc, ¿json?) y especialmente empezar a hincarle el diente a esa versión UPNP que hace tiempo que tengo en la cabeza y me gustaría sacarme.

Hasta donde yo se, el UPNP no es más que un protocolo HTTP con un formato bizarro... seguro que hay liberías que nos lo dan hecho.