Tuve un problema similar. En mi caso, nunca fue un problema volar todo en el repositorio heroku y reemplazarlo con lo que esté en mi subdirectorio. Si este es tu caso, puedes usar el siguiente script bash. Simplemente colócalo en el directorio de tu aplicación Rails.

#!/bin/bash

#change to whichever directory this lives in
cd "$( dirname "$0" )"

#create new git repository and add everything
git init
git add .
git commit -m"init"
git remote add heroku [email protected]:young-rain-5086.git

#pull heroku but then checkback out our current local master and mark everything as merged
git pull heroku master
git checkout --ours .
git add -u
git commit -m"merged"

#push back to heroku, open web browser, and remove git repository
git push heroku master
heroku open
rm -fr .git

#go back to wherever we started.
cd -

Estoy seguro de que hay muchas maneras de mejorar esto - ¡así que siéntete libre de decirme cómo!

Comencé con lo que John Berryman puso, pero en realidad puede ser más simple si no te importa en absoluto la historia de heroku git.

cd bin
git init
git add .
git commit -m"deploy"
git push [email protected]:your-project-name.git -f
rm -fr .git

Supongo que official git subtree es la mejor respuesta, pero tuve problemas para que el subárbol funcione en mi mac.

Después de un largo y duro mes de probar cosas diferentes y ser mordido cada vez que me di cuenta,

Solo porque Heroku usa un repositorio git como mecanismo de implementación, no debe tratarlo como un repositorio git

Podría haber sido rsync igual de bien, fueron por git, no te distraigas por esto

Si lo haces, te abres a todo tipo de daño. Todas las soluciones antes mencionadas fallan miserablemente en alguna parte:

1. it requiere que se haga algo cada vez, o periódicamente, o suceden cosas inesperadas (empujar submódulos, sincronizar subárboles,...)
2. si usas un motor por ejemplo para modularizar tu código, Bundler te comerá vivo, es imposible describir la cantidad de frustración que he tenido con ese proyecto durante la búsqueda de una buena solución para esto
   • intenta agregar el motor como git repo link + bundle deploy - fail, necesita agrupar la actualización cada vez
   • intenta agregar el motor como un :path + bundle deploy - si falla, el equipo de desarrollo considera la opción :path como" no estás usando Bundler con esta opción de gema", por lo que no se agrupará para producción
   • además, cada actualización del motor quiere actualizar tu pila de rails- _ -
3. la única solución que he encontrado es usar el motor como un /vendor enlace simbólico en el desarrollo, y en realidad copiar los archivos para la producción

La solución

La aplicación en cuestión tiene 4 proyectos en git raíz:

1. api-dependiendo del perfil se ejecutará en 2 hosts heroku diferentes - upload y api
2. web-el sitio web
3. web-old-el viejo sitio web, todavía en migración
4. común-los componentes comunes extraídos en un motor

Todos los proyectos tienen un enlace simbólico vendor/common mirando la raíz del motor common. Al compilar el código fuente para su implementación en heroku, necesitamos eliminar el enlace simbólico y rsync para que el código esté físicamente en el proveedor carpeta de cada host separado.

1. acepta una lista de nombres de host como argumentos
2. ejecuta un git push en su repositorio de desarrollo y luego ejecuta un git pull limpio en una carpeta separada, asegurándose de que no se envíen cambios sucios (sin confirmar) a los hosts automáticamente
3. despliega los hosts en paralelo: cada repositorio git de heroku se extrae, el nuevo código se sincroniza en los lugares correctos, se compromete con la información básica de inserción en el comentario de confirmación de git,
4. al final, enviamos un ping con rizo para decirle a los anfitriones hobby para despertar y cola de los registros para ver si todo fue vino
5. juega bien con jenkins también: D (push de código automático para probar servidores después de pruebas exitosas)

Funciona muy muy bien en la naturaleza con mínimo (no?) problemas 6 meses ahora

Aquí está el script https://gist.github.com/bbozo/fafa2bbbf8c7b12d923f

Actualización 1

@AdamBuczynski, nunca es tan sencillo.

1st siempre tendrá un entorno de producción y prueba como mínimo - y un montón de clústeres específicos de función en el peor-de repente 1 carpeta necesita mapear a n proyectos de heroku como un requisito bastante básico y todo necesita ser organizado de alguna manera para que el script "sepa" qué fuente desea implementar donde,

2do querrá compartir código entre proyectos - ahora viene la parte sync_common, los shennanigans con enlaces simbólicos en desarrollo siendo reemplazados por código rsynced real en Heroku porque Heroku requiere una cierta estructura de carpetas y bundler y rubygems realmente realmente realmente hacen las cosas feas muy mal si desea extraer los hilos comunes en una gema

3rd querrá conectar CI y cambiará un poco la forma en que deben organizarse las subcarpetas y el repositorio de git, al final, en el caso de uso más simple posible, terminará con el gist mencionado anteriormente.

En otros proyectos necesito conectar compilaciones Java, al vender software a varios clientes, necesitará filtrar módulos que obtener instalado en función de los requisitos de instalación y demás,

Realmente debería considerar explorar agrupar cosas en un Rakefile o algo así y hacer todo de esa manera...