Solo tengo curiosidad por saber qué diferencia hay entre Add a Single Commenty Start a Review, al dejar comentarios en la changed filespestaña en un archivo pull request.
Por ejemplo, si refactorizo una pequeña parte del código para limpiarlo, ¿es a commento a code review?
Gracias
Esa es una buena característica en GitHub. Cuando agrega un solo comentario, los revisores del PR son notificados inmediatamente. Yo no uso eso. Comienzo una revisión, hago todos mis comentarios y termino mi revisión. Al hacer eso, los revisores reciben una notificación de todos mis comentarios a la vez.
Si incluso cambia un solo carácter en el código, no es ni un comentario ni una revisión del código; es otro compromiso y tiene que ver con otro PR.
No hay una respuesta correcta aquí en particular; principalmente depende de cómo su equipo acuerde usar los PR de GitHub.
Si "Inicia una revisión", además de guardar todos los comentarios y notificar al usuario una vez, como mencionó Nezih, GitHub también le pedirá que elija "Aprobar", "Solicitar cambios" o "Comentar". Si fue un revisor solicitado, se indicará que ha enviado una revisión (independientemente de lo que elija). Dejar un solo comentario no hace eso.
Debido a que guarda todo para notificar a la persona solo una vez cuando haya terminado, ocasionalmente me ha pasado que cuando termino mi revisión, el código ya ha cambiado nuevamente ya que el autor ha respondido a otras solicitudes de cambio. Eso es confuso y molesto, y a veces me influye para dejar comentarios individuales en su lugar. Por otro lado, si voy a hacer muchos comentarios , creo que es más amable con el autor agruparlos en el modo "Iniciar una revisión". Esto es especialmente cierto si mis comentarios se van a referir entre sí.
Si está publicando un fragmento de código refactorizado como sugerencia, puede usar cualquiera de las opciones. Si no cree que el RP deba fusionarse sin su sugerencia, elija "Iniciar una revisión" y seleccione "Solicitar cambios".
Si su equipo acordó que los compañeros de equipo pueden modificar el código de los demás para cosas como esa (lo cual es inusual, pero hay situaciones en las que funciona bien), entonces estaría revisando la rama y presionando su propio compromiso. Pero primero asegúrese de entender las normas del equipo: en mi equipo, no hacemos eso sin preguntar primero al autor para evitar posibles golpes en el trabajo en curso.