Hola buenas,
creo que tengo la cabeza de mi repositorio desacoplada, el caso es que voy haciendo commits pero ese indicativo de master no ha variado desde hace tiempo ¿como lo puedo solucionar?
Es decir, tengo en ¿master? hasta ese commit, pero los otros donde han ido a parar??
No se si será ese el problema, y en caso de que sea así que problematicas podria ocurrirme en caso de que esto continuase así?
Soy novatillo en esto de Git, gracias!
https://stackoverflow.com/questions/2432579/git-your-branch-is-ahead-by-x-commits
PD: Cuidado que se ve tu nombre completo.
Pues obviamente los commits no están en master, si no estabas trabajando en ninguna rama (detached head), crea una, y luego haces merge a master.
Cuando trabajes con git lo mejor que puedes hacer es meterte algo para que el prompt te indique siempre en que rama estás, te ahorra muchos líos como este
No creo que le importe mucho cuando su nick son prácticamente sus apellidos
Git a pelo, no hace falta nada más.
Una vez cada X meses he llegado a utilizar Sourcetree ya que agiliza la limpieza (ramas y stash). En el día a día línea de comandos y gitk que viene por defecto.
sinceramente, ninguna.
git es un lío de cojones, y antes o después te vas a encontrar con algún problema, y la gente que por lo que sea no quiere aprenderlo y prefiero intentar usar alguna herramienta, al final lo que acaba haciendo es guardar el código, borrar el repositorio crear uno nuevo y pegar el código para empezar de 0 por que no tienen ni idea de que hacer a la mínima que algo no va bien.
Si vas a trabajar con git lo mejor es pasar por el aro y entender como funciona. Otra cosa es usar alias o scripts para facilitar alguna cosa, como el que te he comentado para que te muestra la rama actual en la que estás en el propio terminal
#4 Yo estoy trabajando en un equipo de 8 personas y usamos GitKraken y GitFlow.
Tenemos nuestra rama master (produccion) y la rama develop (desarollo), los desarrolladores trabajamos sobre la rama develop, sacamos una rama para hacer una feature, hacemos commits con el progreso que vayamos haciendo y, cuando acabamos la feature hacemos un pull-request, y cuando el pull-request los sniior se hace un merge de nuestra rama feature a la develop.
Cuando se comprueba que en la rama develop todo funciona bien, se copia a la rama master y se sube a produccion.
La verdad que al principio es lioso pero una vez te acostumbras a trabajar aso,
GitFlow y a pastar. Todos los miembros del equipo trabajando sobre [ feature / fix / hotfix ] y a mergear las ramas develop | release | master
https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow
git es sencillo para el que trabaja solo en su propio repositorio en una aplicación que según se hacen las cosas se suben.
Cuando tienes a varios desarrolladores trabajando por separado en distintas funcionalidades a la vez, tienes una rama con lo que hay en producción, otra con lo que está en pruebas para subirlo cuando esté ok, otra con la que está terminado pero todavía no se va a subir, y empiezan las historias de que tienes que juntar lo que ha hecho X con la que ha hecho Z pero sin lo que está haciendo W, pero luego todo tiene que acabar junto, al final siempre acaba habiendo problemas.
Pero claro si te dedicas a hacer commit tras commit y luego merge, y eso es todo lo que has tenido que hacer en git, pues sí, es sencillo.
#10 es sencillo también cuando se trabaja en equipo eh? Estás trolleando?
La rama develop tiene que estar estable, que para eso es la rama desde la que se abren las features. De ahí, cuando X programadores suben código a develop, se supone que está estable a falta de realizar pruebas, a develop no se mergea cualquier mierda.
Se testea develop y de ahí se abre una release, se vuelve a testear la release. Si hay algún fallo, se abre fix desde la release (NO desde develop). Se arregla el fallo, se mergea a la release y en ese momento se baja a develop.
La release se mergea a master.
Sin fallo.
#8 Así es como trabajaba yo .
El problema es cuando por ejemplo dos personas tocan la misma clase (por ejemplo?), eso tiene solución?
#13 como si tocas exactamente la misma línea. Al segundo que haga pull / push le va a dar conflicto, lo soluciona y lo pushea.
#14 No se, donde curraba estabamos dos equipos en dos edificios diferentes y los que subian de develop a master a veces se comían cambios que en historial se veía claramente que la rama había sido sacada de develop y luego mergeada a la misma.
A veces la gente la liaba no se como
