Contribuir a LinuxCNC

El repositorio oficial git de LinuxCNC está en https://github.com/linuxcnc/linuxcnc/

Cualquiera puede obtener una copia de solo lectura del árbol fuente LinuxCNC a través de git:

git clone https://github.com/linuxcnc/linuxcnc linuxcnc-dev

Si usted es un desarrollador con acceso push, entonces siga las instrucciones de github para configurar un repositorio desde el que pueda hacer push.

Tenga en cuenta que el comando clone coloca el repositorio local de LinuxCNC en un directorio llamado linuxcnc-dev, en lugar del predeterminado` linuxcnc`. Esto se debe a que el software LinuxCNC por defecto espera configuraciones y Programas de código G en un directorio llamado $ HOME / linuxcnc, y tener el repositorio git en el mismo sitio es confuso.

Los problemas y las solicitudes pull son bienvenidos en github: https://github.com/LinuxCNC/linuxcnc/issues https://github.com/LinuxCNC/linuxcnc/pulls

Utilizamos los flujos de trabajo git "merging upwards" y "topic branches" descritos aquí:

https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html

Tenemos una rama de desarrollo llamada master, y una o más ramas estables con nombres como 2.6 o 2.7 que indican el número de versión de los lanzamientos que hacemos.

Las correcciones de errores van en la rama estable aplicable más antigua, y esa rama se fusiona con la siguiente rama estable más nueva, y así sucesivamente hasta master. El committer, o confirmador de la corrección de error, puede hacer las fusiones por sí mismo, o dejarlas a otra persona.

Las nuevas características generalmente van en la rama master, pero algunos tipos de características (específicamente controladores de dispositivo y documentación bien aislados) pueden (a discreción de los gerentes de ramas estables) entrar en una rama estable y fusionarse como lo hacen las correcciones de errores.

Hay muchos tutoriales gratuitos excelentes de git en Internet.

El primer lugar para buscar es probablemente la página de manual "gittutorial". Se puede acceder a esta página de manual ejecutando "man gittutorial" en un terminal (si tiene instaladas las páginas de manual de git). gittutorial y su documentación de seguimiento también está disponible en línea aquí:

Para una documentación más completa de git, vea el libro "Pro Git": http://git-scm.com/book donde hay versiones en varios idiomas, incluido Español.

Otro tutorial en línea que se ha recomendado es "Git for the Lazy": http://wiki.spheredev.org/Git_for_the_lazy

Mantenga sus commits pequeños y directos. Cada commit debe aportar un cambio lógico al repositorio.

Mantenga los mensajes de commits alrededor de 72 columnas de ancho (de modo que en un tamaño predeterminado de ventana de terminal, no se partan cuando se muestren con git log).

Use la primera línea como un resumen de la intención del cambio (casi como la línea de asunto de un correo electrónico). Sígalo con una línea en blanco, y luego un mensaje más largo explicando el cambio. Ejemplo:

Las correcciones de errores deben ir en la rama aplicable más antigua. Las nuevas funciones deberían ir a la rama maestra. Si no está seguro de dónde pertenece un cambio, pregunte en el irc o en la lista de correo.

Cuando sea apropiado, organice sus cambios en una rama (una serie de commits) donde cada commit es un paso lógico hacia su objetivo máximo. Por ejemplo, primero factorice un código complejo en una nueva función. Luego, en un segundo commit, corrija algún error subyacente. Después, en un tercer commit, agregue una nueva característica que sea fácil para la refactorización y que no hubiera funcionado sin arreglar aquel error.

Esto es útil para los revisores, porque es más fácil ver que el paso "factorizar el código en una nueva función" era correcto, sin otras ediciones mezcladas; es más fácil ver que el error se corrige cuando el cambio que lo arregla es independiente de la nueva característica; y así sucesivamente.

Haga un esfuerzo por seguir el estilo de sangría predominante en el código. En particular, los cambios en los espacios en blanco hacen que sea más difícil para otros desarrolladores rastrear cambios a lo largo del tiempo. Cuando se debe reformatear código, hágalo como un commit separado de cualquier cambio semántico.

Con git, es posible grabar cada edición y falso comienzo como un commit separado. Esto es muy conveniente como una forma de crear puntos de control durante el desarrollo, pero a menudo no se quiere compartir estos falsos comienzos con otros.

Git proporciona dos formas principales de limpiar el historial, las cuales se pueden hacer libremente antes de compartir el cambio:

git commit --amend le permite hacer cambios adicionales a su último commit, modificando opcionalmente también el mensaje del mismo. Utilizar esto si se dio cuenta de inmediato de que dejó algo fuera del commit o para reescribir el mensaje.

git rebase --interactive upstream-branch le permite volver a través de cada commit realizado desde que bifurco su rama de características desde la rama superior, posiblemente editando, descartando o comprimiendo (combinando) commits con otros. Rebase también se puede usar para dividir commits individuales en múltiples commits nuevos.

Si su cambio consta de varios parches, git rebase -i puede usarse para reordenarlos en una secuencia de commits que establezca más claramente los pasos de su trabajo. Una consecuencia potencial de reordenar parches es que podrían aparecer dependencias incorrectas, por ejemplo, introducir el uso de una variable y, en un parche posterior, la declaración de esa variable.

Si bien la rama HEAD se construirá, no todos los commits podrán compilarse en tal caso. Eso rompe git bisect, algo que se podría usar más tarde para encontrar el commit que introdujo un error. Así que más allá de asegurarse que su rama compila es importante asegurar que cada commit compila también.

Hay una forma automática de verificar una rama para que con cada commit siga siendo compilable. - ver http://dustin.sallings.org/2010/03/28/git-test-sequence.html y el código en https://github.com/dustin/bindir/blob/master/git-test-sequence. Úselo de la siguiente manera (en este caso probando cada confirmación desde origen/maestro a HEAD, incluida la ejecución de pruebas de regresión):

Esto informará Todo bien o Se rompió en <commit>

Utilice la capacidad de cambiar el nombre de los archivos con mucho cuidado. Al igual que correr sangría en archivos individuales, los cambios de nombre hacen que sea más difícil de seguir cambios en el tiempo. Como mínimo, debe buscar consenso en IRC o La lista de correo de que el cambio de nombre es una mejora.

Utilice git pull --rebase en lugar de` git pull` para mantener un buen historial lineal. Con rebase, siempre se retiene el trabajo como revisiones delante de origen/maestro, para que pueda hacer cosas como git format-patch para compartir con otros sin push al repositorio central.