Pregunta Mejores prácticas para repositorios git en proyectos de código abierto


Estoy contribuyendo a un proyecto de código abierto bastante pequeño alojado en Github. Para que otras personas puedan aprovechar mi trabajo, he creado mi propio tenedor en Github. A pesar de la elección de la terminología de Github, no deseo desviarme totalmente del proyecto principal. Sin embargo, no espero ni deseo que todo mi trabajo sea aceptado en el repositorio principal. Algunos de ellos, sin embargo, ya se han fusionado en el repositorio principal y espero que esto continúe. El problema al que me estoy enfrentando es la mejor manera de mantener nuestros dos árboles en un estado donde el código se pueda compartir fácilmente entre ellos.

Algunas situaciones que tengo o encontraré incluyen:

  • Confirmo código que luego se acepta en el repositorio principal. Cuando tire de este repositorio en el futuro, mi compromiso está duplicado en mi repositorio.
  • Cito código que nunca se acepta en el repositorio principal. Cuando salga de este repositorio en el futuro, los dos árboles se han separado y arreglarlo es difícil.
  • Otra persona aparece y basa su trabajo en mi repositorio. Por lo tanto, debería, si es posible, evitar cambiar los commits que he presionado, por ejemplo, usando git rebase.
  • Deseo enviar el código al repositorio principal. Idealmente, mis cambios deberían poder transformarse fácilmente en parches (idealmente usando git format-patch) que puedan aplicarse directa y limpiamente al repositorio principal.

Hasta donde puedo decir hay dos o posiblemente tres formas de manejar esto, ninguna de las cuales funciona particularmente bien:

  • Ejecuto git rebase frecuentemente para mantener mis cambios basados ​​en el encabezado del repositorio de subida. De esta forma puedo eliminar compromisos duplicados pero a menudo tengo que reescribir la historia, causando problemas a las personas que quieren derivar su trabajo del mío.
  • Combine con frecuencia los cambios del repositorio aguas arriba en el mío. Esto funciona bien por mi parte, pero no parece que sea fácil enviar mi código al repositorio de subida.
  • Usa alguna combinación de estos y posiblemente git cherry-pick para mantener las cosas en orden.

¿Qué han hecho otras personas en esta situación? Sé que mi situación es análoga a la relación entre varios colaboradores del kernel y el repositorio principal de Linus, así que espero que haya buenas maneras de manejar esto. Sin embargo, soy bastante nuevo en git, así que no he dominado todos sus matices. Finalmente, especialmente debido a Github, mi terminología puede no ser del todo coherente o correcta. Sientase libre de corregirme.


32
2017-09-05 03:22


origen


Respuestas:


Algunos consejos que aprendí de una situación similar:

  • Tener una sucursal de seguimiento remoto para el trabajo del autor aguas arriba.
  • Extraiga los cambios de esta rama de seguimiento en su rama principal de vez en cuando.
  • Crea una nueva rama para cada uno de los temas en los que estás trabajando. Estas ramas generalmente deben ser locales solamente. Cuando obtiene cambios desde el nivel anterior al maestro, modifique las ramas de tema para reflejar estos cambios.
  • Cuando hayas terminado con algún tema de trabajo, únete al maestro. De esta forma, las personas que están obteniendo trabajo de los suyos no verán demasiado historial reescrito, ya que el rebase se produjo en las ramas de tema locales.
  • Presentación de cambios: su rama principal será básicamente una serie de confirmaciones, algunas de las cuales son iguales a las anteriores, el resto son suyas. Este último se puede enviar como parches si lo desea.

Por supuesto, tu elección de nombres de sucursales y controles remotos es tuya. No estoy seguro de que estos sean exhaustivos para el escenario, pero cubren la mayoría de mis obstáculos.


17
2017-09-05 03:53