[Duda] ¿Como hacéis los comentarios en Git?


  • 0

    Me explico:

    Me tiro una tarde perpetrando código. Toco varios archivos, a veces sólo para hacer una pequeña prueba o incluso para dar formato a alguno de ellos.(quitar un espacio o un salto de línea)

    Acabada la jornada hago un commit y me pide obligatoriamente un comentario, así que pongo las cuatro cosas reales en las que he estado trabajando.

    Pero tooodos los archivos que he tocado, incluso para eliminar un cambio de línea, aparecen afectados por ese comentario, y entiendo que eso lleva a error.

    La pregunta es...¿cómo hacen los exodianos? Sólo se me ocurre hacer commits cada vez que se tocan 4 líneas , pero eso no debe ser así.



  • 1

    Pues haz dos commits, uno cuando tocas tonterías y otro cuando te vas a poner con algo serio en concreto :nusenuse:



  • 2

    @Pixel dijo en [Duda] ¿Como hacéis los comentarios en Git?:

    Pues haz dos commits, uno cuando tocas tonterías y otro cuando te vas a poner con algo serio en concreto :nusenuse:

    Ya. Eso digo en mi comentario. Pero eso me obligaría a hacer commits prácticamente cada vez que quito un espacio :aidiomio:



  • 3


  • 4

    si no es algo tuyo y quieres hacer un PR pues un commit por cada cambio global que quieras hacer
    quiero arreglar esto, commit, quiero arreglar esto otro, commit
    el commit puede afectar a varios archivos eso da =



  • 5

    La forma correcta es hacer un commit por cada cosa que quieras hacer. ¿Es un coñazo hacer tantos commits? Si, lo es. Pero todo queda mucho mejor organizado y mucho más claro al mirar que para añadir X cosa has hecho Y cambios. Y para eliminar cualquier cambio que no funcione bien o de algún problema, puedes verlo fácilmente. Git vale para eso, para llevar el control de los cambios que haces.



  • 6

    Yo suelo hacer varios commits, incluso antes de haber terminado 100% o sin comprobar si hay errores (y luego commit otra vez para arreglarlo). Quiero pensar que nadie me juzga por ser como soy :nono3:



  • 7

    Yo no lo utilizo nada, pero trabajo aparte :roto2: así se me queda de limpio: https://github.com/Pixelatedbug/Botmensajes-NodeBB/commits/master :campeon2: :campeon2: :campeon2: :campeon2:



  • 8

    Supongo que no he pillado la filosofía de Git
    En realidad, lo uso para subir mi programa a github, desde que tuve mi último percance con mi ordenador y perdí bastantes cosas. Así que lo uso más bien como un backup que como una forma de trabajo.



  • 9

    @kNN Exacto
    No debe darte pudor hacer commits, es más, cuanto más lo tengas segmentado, mejor lo tendrás estructurado todos los cambios.
    Generalmente yo he trabajado con tickets de bugs o develops, por los cuales iba generando commits según iba aplicando funcionalidades o quitando bugs...
    Diria que cada rama tendría sus 10-15 commits perfectamente, algunas más.



  • 10

    si no puedes explicar lo que has hecho en un comentario de una línea o dos, es que el commit es demasiado grande.

    de todas formas cuando para hacer cambios pequeños tienes que tocar muchos archivos, la cosa huele mal. ¿por qué dices que tocas muchos archivos? es simplemente porque modificas el "formato" del código (poniendo espacios que faltaban, corrigiendo la tabulación y cosas así)? o los cambios afectan al comportamiento del programa?

    • si es por formato deberías usar una herramienta que te obligue a usar un formato constante, y hacer un commit que arregle todo el formato del proyecto, para no desperdigar esos cambios en cientos de commits, porque eso es RUIDO.

    • en cambio si tocas muchos archivos cambiando el comportamiento observable del programa: o bien estás haciendo algo mal o bien el código es difícil de mantener.



  • 11

    @TheBronx dijo en [Duda] ¿Como hacéis los comentarios en Git?:

    si no puedes explicar lo que has hecho en un comentario de una línea o dos, es que el commit es demasiado grande.

    de todas formas cuando para hacer cambios pequeños tienes que tocar muchos archivos, la cosa huele mal. ¿por qué dices que tocas muchos archivos? es simplemente porque modificas el "formato" del código (poniendo espacios que faltaban, corrigiendo la tabulación y cosas así)? o los cambios afectan al comportamiento del programa?

    • si es por formato deberías usar una herramienta que te obligue a usar un formato constante, y hacer un commit que arregle todo el formato del proyecto, para no desperdigar esos cambios en cientos de commits, porque eso es RUIDO.

    • en cambio si tocas muchos archivos cambiando el comportamiento observable del programa: o bien estás haciendo algo mal o bien el código es difícil de mantener.

    Pues definitivamente se han juntado varias cosas:
    1.- No estoy usando git para tener controlados los cambios, sino realmente para poder usar github como copia de respaldo.
    2.- Sobre lo de tocar muchos archivos cuando cambio una funcionalidad es en muchos casos cierto. Y muchas veces se deben a una mala estructuración del programa, y otras porque estoy migrando mi programa a Qt (bueno, no lo estoy migrando, sino que hice una versión "consola" que era funcional, pero a base de menús de consola y eso, y a la hora de ponerle una interfaz gráfica hay muchas cosas que han perdido sentido en la versión consola, así como el cambio de tipos (me he negado de primeras, pero poco a poco estoy cambiando todas los tipos std::string a QString en todas las clases. Eso implica que cuando tengo que tocar una función que toca a un objeto de una clase que usa std::string aprovecho para cambiar el tipo en la clase)
    Por otro lado, estoy aprovechando el paso a interfaz gráfica para ordenar código, separar funciones, redefinir clases...vamos, que lo llevo todo para adelante de forma caótica, aunque poco a poco (creo) que estoy consiguiendo algo legible y mantenible.



  • 12

    Bueno, las migraciones es lo que tienen. Y no es malo, de hecho justo lo contrario, mejorar el código cuando pasas por una clase que crees que se puede mejorar. Lo que se llama la regla del Boy Scout: "Always leave the campground cleaner than you found it" y que es una de las máximas del Clean Code.

    Sabiendo esto pues procura limitar los cambios en cada commit, haciendo tareas lo más unitarias posibles para que el refactor y la migración no conviertan el commit en un monstruo de decenas de ficheros modificados dentro de lo posible.

    Ya le irás sacando más partido al git, es una herramienta brutal.





Has perdido la conexión. Reconectando a Éxodo.