OK, entonces tengo un proyecto de Django. Me preguntaba si debía poner cada aplicación en su propio repositorio git, o si es mejor simplemente poner todo el proyecto en un repositorio git, o si debería tener un repositorio git para cada aplicación y también un repo de git para ¿el proyecto?¿Tiene usted control de versión de las aplicaciones normales o de todo el proyecto o de ambos?
Gracias.
Realmente depende de si esas aplicaciones reutilizables se van a reutilizar fuera del proyecto o no?
La única razón por la que podría necesitarlo en un repositorio diferente es si otros proyectos con repositorios separados podrían necesitar usarlo. Pero siempre puedes dividirlo más tarde. Hacer un repositorio git es barato, así que es una de esas cosas que puedes hacer más adelante si es necesario. Hacer las cosas complicadas por adelantado simplemente te frustrará más tarde, así que no dudes en esperar hasta que sepas que es necesario
YAGNI es más que solo código.
No soy un experto en git, pero no creo que la estrategia adecuada sea diferente de una para hg, o incluso, en este caso, svn, así que voy a dar mi valor de 2 centavos de todas formas;-).
Un repositorio por aplicación solo tiene sentido si un número sustancial de personas podría estar interesado en retirar (o ver cambios) aplicaciones separadas; En teoría, este podría ser el caso, pero nunca lo he observado en la vida real; la mayoría de las personas que están interesadas en el proyecto están interesadas en él en su conjunto. Por lo tanto, evitaría complicaciones y convertiría todo el proyecto en un repositorio.
Alex, la razón por la que pregunto es porque Django parece enfatizar la noción de aplicaciones reutilizables. Estoy intrigado por su declaración, "este podría ser el caso teóricamente, pero nunca lo he observado en la vida real". ¿Diría que la idea de las aplicaciones reutilizables en Django es más un tipo de cosas "agradables en teoría"? – rick
@rick, o tienes razón, es simplemente "agradable en teoría", O simplemente no tengo suficiente experiencia en Django en la vida real - después de todo, para mí, Django es solo uno de los muchos (¡bien y apreciado!) flechas en mis carcajs, ¡no es la única forma en que alguna vez desarrollé aplicaciones! -) –
Casi siempre es más fácil tener un repositorio por equipo de desarrollo, sin importar cuántos productos tenga. Eventualmente querrá compartir código entre proyectos (¡incluso varios sitios web de DJango separados!) Y es mucho más fácil hacerlo con un solo repositorio.
Establezca una bonita estructura de carpetas DENTRO de ese repositorio. Sin embargo, un único pago de git (probablemente de una subcarpeta) debería darle todos los archivos que necesita para su sitio web de prueba (python, templates, css, jpegs ...), y luego simplemente copie httpd.conf y así sucesivamente para completa la instalación.
¿Estas aplicaciones individuales utilizan código compartido y bibliotecas? Si es así, realmente pertenecen al mismo repositorio ... lo que le permite ver el impacto de los nuevos cambios cuando se ejecuta un conjunto de pruebas único.
Si están completamente separados y agnósticos, realmente no importa. Solo por la cordura, la facilidad de construcción y la facilidad de empaquetado, prefiero mantener todo un proyecto en un repositorio combinado. Sin embargo, normalmente trabajamos en equipos muy pequeños. Entonces, si no se trata de un código compartido, realmente solo se trata de cuál es el método más conveniente y eficiente para todos los interesados.
me gusta Tom's o Alex's respuestas, excepto que les falta razón real detrás de ellas
("más fácil tener un repositorio por el equipo de desarrollo"?
"un número considerable de personas que podrían estar interesados en extraer (o viendo cambios a aplicaciones por separado)"
por qué?)
en primer lugar, uno o varios repositorios es una decisiónadministración de servidor (en términos de recursos del servidor).
SVN configura fácilmente varios repositorios detrás de un servidor, mientras que ClearCase tendrá su propio proceso "vob_server" por VOB, lo que significa que no desea más de cien VOB por servidor (Unix) (o más de 20-30 en un servidor de Windows).
Git es particular: configurar un repositorio es barato, teniendo acceso a puede ser fácil (a través de una ruta compartida simple), o puede implicar un proceso (un daemon git). La última solución significa: "no demasiados repositorios accedieron al directamente desde el exterior". (Que se puede acceder indirectamente a través de submódulos referenciados por un super-proyecto)
Luego está la administración del lado del cliente: cómo complejo tendrá la configuración de un espacio de trabajo ser, cuando se trata de uno o varios repositorios. ¿Cómo puede el cliente hacer referencia a la configuración correcta? (lista de etiquetas necesarias para hacer referencia a los archivos correctos).
SVN utilizaría external, git "submódulos", y en ambos casos, eso agrega complejidad.
Es por eso que Tom's answer puede ser correcto. Por último, está el configuration management aspect (referenciado en Alex's answer). ¿Puedes etiquetar parte de un repo de no?
Si puede (como en SVN donde realmente hace una copia svn de parte de un repositorio), eso significa que puede tener un componente enfoque, donde varios grupos de archivos tienen su propio ciclo de vida y sus propias etiquetas (establecido a su propio ritmo individual).
Pero en Git, eso no es posible: una etiqueta hace referencia a una confirmación que siempre se refiere al repositorio all.
Esto significa un enfoque "basado en el sistema", donde solo desea el proyecto de todos modos (a diferencia de "ver aplicaciones separadas - Nunca lo he visto en la vida real" desde Alex's answer). Si ese es el caso (si quieres el sistema de todos modos), eso no es importante.
Pero para aquellos de nosotros que piensan en términos de "grupos independientes de archivos", eso significa que un repositorio git representa un grupo de archivos individuales (con su propio ritmo en términos de evolución y etiquetado), con un potencial -proyecto haciendo referencia a esos repositorios como submódulos.
Esa no es su configuración diaria, por lo que para proyectos independientes, recomendaría solo unos pocos o un repo de Git.
Pero para más complejo interdependiente conjunto de proyectos ... debe tener en cuenta que, por la misma forma en que se concibió a Git, un "repositorio" representa un conjunto coherente de archivos que se supone evolucionan al mismo ritmo que un todo. Y no "todo" siempre puede caber en un conjunto de archivos (si "todo" es lo suficientemente complejo). Por lo tanto, se necesitarían varios repositorios en este caso.
Y en la vida real también ocurre un complejo conjunto de proyectos interdependientes;)
Si tiene aplicaciones reutilizables, colóquelas en un repositorio independiente.
Si usted está preocupado por el número de repositorios privados echar un vistazo a bitbucket (si decide hacerlos código abierto, aconsejo github)
No es una buena manera de incluir sus propias aplicaciones en la proyecto, incluso haciendo uso de etiquetas de versión:
Recientemente encontré una forma de hacerlo con las etiquetas buildout y git (utilicé svn: externals para incluir una aplicación, pero pasé de svn a git recientemente).
me trataron mr.developer primera, pero mientras no conseguir que esto funcione He encontrado una alternativa para mr.developer:
descubrí gp.vcsdevlop es muy fácil de usar para este propósito.
ver https://pypi.python.org/pypi/gp.vcsdevelop
terminé, poner esto en mi archivo buildout y tengo trabajo a la vez (he tenido que añadir un requirements.txt pip a mi aplicación para que funcione, pero eso es una buena cosa después de todo):
vcs-update = True
extensions =
gp.vcsdevelop
buildout-versions
develop-dir=./local_checkouts
[email protected]:<my bitbucket username>/<the app I want to include>[email protected]#egg=<the appname in django>
develop = .
en este caso chacks a cabo mi aplicación y clonar a la versión 0.1.38 etiqueta para el proyecto en el subdit ./local_checkouts/ y lo desarrolla cuando se ejecuta bin/buildout
Edición: comentario 26 de agosto de 2013
Al usar esta solución y edición en esta comprobación local de la aplicación utilizada en un proyecto. Descubrí esto:
obtendrá esta advertencia al intentar el comando normal 'git push origin master':
To prevent you from losing history, non-fast-forward updates were rejected
Merge the remote changes before pushing again. See the 'Note about
fast-forwards' section of 'git push --help' for details.
EDITAR 28 de augusta 2013
sobre el trabajo en las local_checkouts para aplicaciones compartidas incluidos por gp.vcsdesarrollar:
(y manejar la advertencia discutida en el remakr anterior)
git push origin + maestro parece arruinar cometer la historia para el código compartido
Así que la forma de trabajar en el directorio local_checkout es así:
ir a la caja local (después de un bin/buildout por lo que la salida es el maestro):
cd localcheckouts/<shared appname>
Crear una nueva rama y swith para de esta manera:
uso git checkout -b 'issue_nr1' (por ejemplo,el nombre de la sucursal está aquí el nombre de la cuestión que se está trabajando)
y después de que haya terminado de trabajar en este Branche, utilice: (después del GIT lo habitual añadir y git commit)
git push origin issue_nr1
cuando probado y completado la fusión rama de nuevo en el maestro:
primer pago y envío al maestro:
git checkout master
actualización (probablemente sólo cuando neede otra confirmación en la media hora)
git pull
y combinar con el maestro (dónde se encuentra en este momento):
git merge issue_nr1
y finaly empujar esta fusión:
git push origin master
(con gracias sepcial a esta guía simplificada git: http://rogerdudler.github.io/git-guide/) y después de un tiempo, para limpiar las ramas, es posible que desee eliminar esta rama
git branch -d issue_nr1
Mantenga las aplicaciones en un repositorio por ahora, especialmente si tiene un solo proyecto. Mientras mantenga sus aplicaciones pequeñas y enfocadas, generalmente es sencillo generalizarlas lo suficiente como para trabajar con otro proyecto. Como dijo Jeremy, este esfuerzo no vale la pena hasta que lo necesites. – jds