git - sirve - Estructuración de subpaquetes Go para equipos.

para que sirve un tag en git

Question

Actualmente estamos moviendo parte de nuestro código base a Go y estamos teniendo problemas con una estructura de directorios flexible para múltiples desarrolladores dentro de un equipo. Disculpas si esta es una pregunta de noob, pero he buscado en cualquier otro lugar y no he encontrado una respuesta.

Digamos que tengo un paquete con la siguiente estructura:

package main
import "username/myproject/subpackage"
func main() {
}

y un subpaquete:

package subpackage
func main() {
}

Esto funciona bien y al leer el código de otras personas en Github, parece que esta es la forma aceptada de definir subpaquetes.

Vea la fuente CoreOS como ejemplo: https://github.com/coreos/etcd/blob/master/main.go

Mi problema es que debido a la estructura de directorios de Go, estos paquetes se almacenan dentro de un repositorio de git específico y si alguien más en el equipo verifica este código para trabajar, su estructura de directorios será diferente debido a la bifurcación. El nombre de usuario en las rutas y las instrucciones de importación cambiarán. Esto no ayuda por el hecho de que nos juntamos y empujamos mucho entre nosotros en lugar de usar un repositorio centralizado.

package main
import "otherusername/myproject/subpackage" (This line will have to be changed)
func main() {
}

Todo lo que he leído sobre Go apunta a su facilidad de uso en entornos de equipo, así que me pregunto si estoy entendiendo el sistema de paquetes correctamente.

Idealmente, nos gustaría poder llamar a subpaquetes con rutas relativas. Estamos acostumbrados a trabajar con espacios de nombres y sé que Go no los tiene. es decir:

package main
import "myproject/subpackage"
func main() {
}

Pero Go no puede encontrar el archivo y estoy seguro de que no es la forma correcta de hacerlo, ya que ningún ejemplo en línea utiliza rutas relativas.

Así que un par de preguntas:

1) ¿Deben los paquetes tener un propietario definido y mantener siempre ese nombre de usuario como parte de las rutas de importación?

2) ¿Debería este repositorio de "propietario" ser un repositorio centalizado (por ejemplo, una empresa u organización) desde el cual todo el código es empujado / extraído?

3) ¿Deberían los otros miembros del equipo que trabajan en un fragmento de código usarlo dentro de la carpeta / espacio de nombres de los creadores en lugar de los suyos?

4) ¿Hay una manera de definir rutas relativas en las declaraciones de importación, y si es así, por qué nadie lo hace? ¿Se considera una mala práctica?

5) ¿Cómo se maneja repo forking con subpaquetes Go?

Gracias.

Answer 1

Version corta:

1. El paquete siempre debe ser go gettable (trabaje con go get package ), por lo tanto, el 99% del tiempo, su paquete será github.com/user/reponame y siempre lo mantendrá en todo su proyecto.

2. Sí, este debe ser el repositorio central y el colaborador (empleado interno o comunidad) debe crear una solicitud de extracción para ese repositorio, nunca debe trabajar en él.

3. Sí, deberían usarlo dentro de la carpeta original con su git remoto bifurcado (ver a continuación)

4. No y sí. Puede definir la importación relativa para un paquete que no sea fácil de obtener. Es decir, cuando no estás en tu gopath, puedes import "./subpackage" . Sin embargo, si va a su GOPATH, Go se quejará de que mezcla importaciones locales y remotas. En el caso general, no utilice la importación relativa.

5. El bifurcación del subpaquete se maneja forzando el paquete principal.

Versión larga:

Tomaré como ejemplo un repositorio de Github con varios miembros del equipo.

El repositorio central sería http://github.com/central/repo

Este repositorio tiene sub repositorios como github.com/central/repo/pkg, github.com/central/repo/whatever.

La forma más fácil y, en mi humilde opinión, la mejor es usar git remote.

Digamos que quiero contribuir a un subrepo (o cualquier otra cosa), el proceso es simple: como en cualquier otro idioma, bifurque el repositorio.

Ahora, como mencionó, tiene una copia del repositorio con importación que se dirige al central. No es muy práctico trabajar con él. Esta es la razón por la que (espera para proyectos pequeños y pequeños), nunca go get mi horquilla, go get el depósito central, voy a $GOPATH/src/github.com/central/repo y agrego mi control remoto con el git remote add creack https://github.com/creack/repo

Ahora puedo trabajar en el proyecto, usarlo como si fuera el central y, una vez que termine, empujo mi rama a mi bifurcación y luego creo una solicitud de extracción.

En este caso, la bifurcación es solo un marcador de posición para las fuentes en github y no se utiliza.