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.
2. Crear rama de características
Cree una rama con un nombre claro y descriptivo:
Convenciones para nombrar ramas
fix-issue-123para corregir erroresadd-feature-xyzpara nuevas funcionesupdate-docs-trainingpara 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:
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:
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:
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 | 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:
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
mainantes de crear ramas - Rebase en
mainantes de la presentación final - Eliminar ramas tras la fusión
Informar de errores 🐞
Informe de errores a través de GitHub Issues:
- Compruebe primero los problemas existentes
- Proporcionar un ejemplo mínimo reproducible
- Describir el entorno: Sistema operativo, versión de Python , versiones de bibliotecas, hardware (utilice
yolo checkspara diagnóstico) - 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 📚
- Guía oficial para contribuir - Directrices completas para contribuir
- CI/Testing - Detalles de la integración continua
- Documentación - Redacción y mantenimiento de documentos
- Código de conducta - Normas comunitarias
- Ultralytics Blog - Últimas actualizaciones y tutoriales
- Eventos comunitarios - Seminarios web y conferencias