Ir al contenido

Flujo de trabajo de desarrollo 💻

Esta guía cubre el proceso de desarrollo para contribuir a Ultralytics incluyendo YOLO11 y repositorios relacionados.

Código de conducta 🤝

Todos los colaboradores deben cumplir nuestro Código de conducta. El respeto, la amabilidad y la profesionalidad están en el corazón de nuestra comunidad. Para más información, consulte la Guía oficial de contribución.

Proceso de solicitud de extracción 🔄

flowchart TD
    A[Fork Repository] --> B[Create Feature Branch]
    B --> C[Make Changes]
    C --> D[Run Tests Locally]
    D --> E[Commit Changes]
    E --> F[Create Pull Request]
    F --> G[Sign CLA]
    G --> H{Review}
    H -->|Changes Requested| I[Address Feedback]
    I --> H
    H -->|Approved| J[Merge!]

    style A fill:#e1f5ff
    style J fill:#d4edda
    style G fill:#fff3cd

1. Crear el repositorio

Abre el repositorio de Ultralytics correspondiente (por ejemplo, ultralytics) en tu cuenta de GitHub.

# Clone your fork
git clone https://github.com/YOUR_USERNAME/ultralytics.git
cd ultralytics

2. Crear rama de características

Cree una rama con un nombre claro y descriptivo:

git checkout -b fix-issue-123

Convenciones para nombrar ramas

  • fix-issue-123 para corregir errores
  • add-feature-xyz para nuevas funciones
  • update-docs-training para la documentación

3. Haga sus cambios

  • Siga las directrices


    Cumplir las directrices de estilo del proyecto

  • Evitar errores


    No introduzca nuevas advertencias

  • Manténgase centrado


    Los cambios deben ser mínimos y selectivos

4. Pruebe sus cambios

Pruebas requeridas

Pruébelo localmente antes de enviarlo:

pytest tests/

Añada pruebas a las nuevas funciones para evitar regresiones.

Más información: Comprobación de requisitos, validación de modelos, flujos de trabajo de CI

5. Confirme los cambios

Comprométase con mensajes concisos y descriptivos:

git commit -m "Fix #123: Corrected calculation error"

Mejores prácticas para los mensajes de compromiso

  • Utilizar el presente ("Añadir función" no "Añadida función")
  • Números de emisión de referencia cuando proceda
  • El asunto debe tener menos de 72 caracteres

6. Crear solicitud de extracción

Enviar RP de su sucursal a main:

  • Título claro que describa el cambio
  • Descripción detallada de la finalidad y el ámbito de aplicación
  • Cuestiones relacionadas con los enlaces
  • Incluir capturas de pantalla de los cambios en la interfaz de usuario
  • Pruebas superadas localmente

7. Firmar el CLA

Obligatorio antes de la fusión

Debe firmar nuestro Acuerdo de Licencia para Colaboradores (CLA) para asegurarse de que las contribuciones están debidamente licenciadas bajo la licenciaAGPL-3.0 .

Después de enviar tu RP, añade este comentario:

I have read the CLA Document and I sign the CLA

El bot CLA le guiará a través del proceso. Para más información sobre licencias, consulte nuestra guía de contribución.

8. Abordar la retroalimentación de la revisión

Responda a los comentarios de los revisores y publique actualizaciones.

Docstrings Google 📝

Todas las funciones y clases requieren docstringsGoogle con los tipos entre paréntesis.

Función estándar

def example_function(arg1, arg2=4):
    """Example function demonstrating Google-style docstrings.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        (bool): True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(4, 4)  # True
        >>> example_function(1, 2)  # False
    """
    return arg1 == arg2

Devoluciones nominativas

def example_function(arg1, arg2=4):
    """Example function with named return.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        equals (bool): True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(4, 4)  # True
    """
    equals = arg1 == arg2
    return equals

Devoluciones múltiples

def example_function(arg1, arg2=4):
    """Example function with multiple returns.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        equals (bool): True if arguments are equal, False otherwise.
        added (int): Sum of both input arguments.

    Examples:
        >>> equals, added = example_function(2, 2)  # True, 4
    """
    equals = arg1 == arg2
    added = arg1 + arg2
    return equals, added

Importante: Documente cada valor de retorno por separado, no como una tupla.

Bien:

Returns:
    (np.ndarray): Predicted masks with shape HxWxN.
    (list): Confidence scores for each instance.

Malo:

Returns:
    (tuple): Tuple containing:
        - (np.ndarray): Predicted masks with shape HxWxN.
        - (list): Confidence scores for each instance.

Con sugerencias tipográficas

def example_function(arg1: int, arg2: int = 4) -> bool:
    """Example function with type hints.

    Args:
        arg1: The first argument.
        arg2: The second argument.

    Returns:
        True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(1, 1)  # True
    """
    return arg1 == arg2

Documentos de una sola línea

def example_small_function(arg1: int, arg2: int = 4) -> bool:
    """Example function with a single-line docstring."""
    return arg1 == arg2

Normas de codificación 📐

Estilo Python

Estándar Requisito Ejemplo
Anchura de línea 120 caracteres como máximo Líneas legibles y escaneables
Docstrings Google Tipos entre paréntesis
Importaciones pathlib en os Caminos modernos y multiplataforma
Sugerencias de tipo Utilizar cuando sea beneficioso Mejora la compatibilidad con IDE
Funciones <50 lines ideally Mantenerse centrado y comprobable

Código Calidad

Lista de control de calidad

  • Sin importaciones ni variables no utilizadas
  • Nombres coherentes (lowercase_with_underscores)
  • Nombres de variables claros (evite las letras sueltas, excepto en los contadores de bucle)
  • Utilizar cadenas f para formatear cadenas
  • Comentarios sólo para lógica compleja
  • Formateador Ruff por coherencia

Buenas prácticas

  • Evitar la duplicación


    Reutilización del código existente - Principio DRY

  • Cambios menores


    Modificaciones focalizadas > cambios a gran escala

  • Simplifique


    Busque oportunidades de simplificación

  • Compatibilidad


    Evitar romper el código existente

  • Añadir pruebas


    Incluir pruebas para las nuevas funciones

  • Formato coherente


    Utilizar el formateador Ruff

Requisitos de las pruebas ✅

Todos los RP deben superar las pruebas de IC:

# Run tests locally
pytest tests/

# With coverage
pytest --cov=ultralytics tests/

Consulte CI/Pruebas para obtener más información sobre CI.

Directrices para la revisión de código 👀

Para los colaboradores

  • Mantener las relaciones públicas centradas en una única función o solución
  • Responder rápidamente a los comentarios
  • No se tome los comentarios como algo personal
  • Actualizar la descripción del RP si cambia el alcance

Para los revisores

  • Revisión en 1-2 días laborables
  • Comprobación de las pruebas unitarias de las nuevas funciones
  • Revisar las actualizaciones de la documentación
  • Evaluar el impacto en el rendimiento
  • Verificar que las pruebas de CI se superan
  • Proporcionar comentarios constructivos y específicos
  • Reconocer el esfuerzo del autor

Buenas prácticas de Git 🌳

Compromete

  • Presente: "Añadir función" no "Añadida función".
  • Mensajes claros y descriptivos
  • Compromisos centrados y lógicos

Oficinas

  • Tirar último main antes de crear ramas
  • Rebase en main antes de la presentación final
  • Eliminar ramas tras la fusión

Informar de errores 🐞

Informe de errores a través de GitHub Issues:

  1. Compruebe primero los problemas existentes
  2. Proporcionar un ejemplo mínimo reproducible
  3. Describir el entorno: Sistema operativo, versión de Python , versiones de bibliotecas, hardware (utilice yolo checks para diagnóstico)
  4. Explicar el comportamiento esperado frente al real con mensajes de error

Para conocer los problemas más comunes y sus soluciones, consulta nuestra guía de solución de problemas.

Licencia 📜

Ultralytics utiliza AGPL-3.0. Si utiliza el código Ultralytics en su proyecto, todo el proyecto debe ser de código abierto bajo AGPL-3.0. Si prefiere no utilizar código abierto, obtenga una licencia Enterprise.

Recursos 📚



Creado hace 4 días ✏️ Actualizado hace 4 días