Utilizamos cookies para que las interacciones con nuestros sitios web y servicios sean fáciles y significativas,

para comprender mejor cómo se usan y para adaptar la publicidad. Puede leer más
(https://www.salesforce.com/company/privacy/full_privacy.jsp#nav_info) y hacer sus elecciones de
cookies aquí (https://www.salesforce.com/company/privacy/full_privacy.jsp#nav_info) . Al continuar
usando este sitio, nos está dando su consentimiento para hacerlo.

Despliegue (/categories/deployment) › Implementando con Git (/categories/deploying-with-git) › Implementa

Implementando con Git

D Última actualización 18 de octubre de 2019

G Tabla de contenido
Requisitos previos: instale Git y la CLI de Heroku

Seguimiento de su aplicación en Git

Crear un control remoto Heroku

Código de implementación

Separarse del proceso de construcción

Resolver despliegues simultáneos

Autenticación HTTP Git

SSH Git transport

Múltiples controles remotos y entornos.

Construir caché

Tamaño del repositorio

Otros limites

Usar subversión u otros sistemas de control de revisión

Recursos adicionales

Heroku administra las implementaciones de aplicaciones con Git (https://git-scm.com/) , el popular sistema de control de versiones.
Definitivamente no necesita ser un experto en Git para implementar código en Heroku, pero es útil aprender los conceptos básicos.

Requisitos previos: instale Git y la CLI de Heroku

Instrucciones de instalación Git (https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)

Instrucciones de instalación de Heroku CLI (https://devcenter.heroku.com/articles/heroku-cli#download-and-install)

Seguimiento de su aplicación en Git

i Si su aplicación ya está rastreada en un repositorio Git, proceda a Crear un control remoto Heroku .

Antes de que pueda implementar su aplicación en Heroku, debe inicializar un repositorio local de Git y confirmar el código de su
aplicación.

El siguiente ejemplo muestra la inicialización de un repositorio Git para una aplicación que vive en el myapp directorio:
 $ cd myapp
$ git init
Initialized empty Git repository in .git/
$ git add .
$ git commit -m "My first commit"
Created initial commit 5df2d09: My first commit
44 files changed, 8393 insertions(+), 0 deletions(-)
create mode 100644 README
create mode 100644 Procfile
create mode 100644 app/controllers/source_file
...

t Asegúrese de inicializar el repositorio de Git en el directorio raíz de su aplicación. Si su aplicación está en un subdirectorio de su
repositorio, no se ejecutará cuando se envíe a Heroku.

El código de su aplicación ahora se rastrea en un repositorio local de Git. Todavía no se ha enviado a ningún servidor remoto.

Crear un control remoto Heroku

Los controles remotos (http://git-scm.com/book/en/Git-Basics-Working-with-Remotes) Git son versiones de su repositorio que viven
en otros servidores. Implementa su aplicación insertando su código en un control remoto especial alojado en Heroku que está
asociado con su aplicación.

Para una nueva aplicación Heroku

El heroku create comando CLI crea una nueva aplicación vacía en Heroku, junto con un repositorio Git vacío asociado. Si ejecuta este
comando desde el directorio raíz de su aplicación, el repositorio vacío Heroku Git se configura automáticamente como remoto para su
repositorio local.

$ heroku create
Creating app... done, thawing-inlet-61413
https://thawing-inlet-61413.herokuapp.com/ | https://git.heroku.com/thawing-inlet-61413.git

Puede usar el git remote comando para confirmar que heroku se haya configurado un control remoto con nombre para su aplicación:

$ git remote -v
heroku https://git.heroku.com/thawing-inlet-61413.git (fetch)
heroku https://git.heroku.com/thawing-inlet-61413.git (push)

Para una aplicación Heroku existente

Si ya ha creado su aplicación Heroku, puede agregar fácilmente un control remoto a su repositorio local con el heroku
git:remote comando. Todo lo que necesitas es el nombre de tu aplicación Heroku:

$ heroku git:remote -a thawing-inlet-61413

set git remote heroku to https://git.heroku.com/thawing-inlet-61413.git

Renombrar controles remotos

Por defecto, la CLI de Heroku nombra todos los controles remotos de Heroku que crea para su aplicación heroku . Puede cambiar el
nombre de sus controles remotos con el git remote rename comando:

$ git remote rename heroku heroku-staging

Cambiar el nombre de su control remoto Heroku puede ser útil si tiene varias aplicaciones Heroku que usan la misma base de código
(por ejemplo, las versiones de preparación y producción de una aplicación). En este caso, cada aplicación Heroku tiene su propio
control remoto en su repositorio local.

El resto de este artículo asume que su aplicación tiene un único control remoto Heroku con nombre heroku .

Código de implementación
Para implementar su aplicación en Heroku, generalmente usa el git push comando para enviar el código desde la master rama de su
repositorio local a su heroku control remoto, de esta manera:

$ git push heroku master

Initializing repository, done.
updating 'refs/heads/master'
...

Use este mismo comando cuando quiera implementar la última versión confirmada de su código en Heroku.

Tenga en cuenta que Heroku solo implementa el código que inserta en la master rama del heroku control remoto. Empujar el código a
otra rama del control remoto no tiene ningún efecto.

Despliegue desde una rama además del maestro

Si desea implementar código en Heroku desde una master sucursal no perteneciente a su repositorio local (por ejemplo testbranch ),
use la siguiente sintaxis para asegurarse de que se envíe a la master sucursal del control remoto :

$ git push heroku testbranch:master

i Las aplicaciones que dependen de submódulos Git son compatibles, además de muchas otras estrategias de resolución de
dependencias (https://devcenter.heroku.com/articles/git-submodules) .

r git lfs (https://git-lfs.github.com/) no es compatible, y su uso puede hacer que los empujes fallen.

Separarse del proceso de construcción

Después de iniciar una implementación de Heroku con git push , puede desconectarse del proceso de compilación resultante
presionando Ctrl + C. Esto no cancela la compilación o la implementación. La compilación continuará en segundo plano y creará una
nueva versión (https://devcenter.heroku.com/articles/releases) tan pronto como se complete.

Resolver despliegues simultáneos

Es posible iniciar una implementación antes de que se complete una implementación anterior de la misma aplicación. Por ejemplo, dos
colaboradores en una aplicación pueden enviar diferentes confirmaciones al heroku control remoto aproximadamente al mismo
tiempo.
Si esto ocurre, las diferentes versiones de su aplicación se implementarán en Heroku en el orden en que se completen sus
respectivas compilaciones. Tenga en cuenta que esto puede diferir del orden en que ocurrieron los empujes.

Por ejemplo, consideremos dos construcciones, A y B. Si Construir B empieza después de Build pero acabados antes de que, Heroku
se desplegarán Construir B primero . Luego, cuando la construcción A finalmente se complete, Heroku la implementará, reemplazando
la construcción B.

Autenticación HTTP Git

i Por defecto, Heroku usa HTTP como su transporte Git. La CLI de Heroku colocará automáticamente las credenciales en el
.netrc archivo heroku login . El cliente Git usa cURL cuando interactúa con controles remotos HTTP, y cURL usará las
credenciales del .netrc archivo. Consulte la sección Autenticación y el artículo de autenticación CLI
(https://devcenter.heroku.com/articles/authentication) para más detalles.

El punto final Heroku HTTP Git solo acepta autenticación básica HTTP (http://en.wikipedia.org/wiki/Basic_access_authentication)
basada en clave API . No se requiere un nombre de usuario y se ignora cualquier valor pasado para el nombre de usuario.

t No puede autenticarse con el punto final Heroku HTTP Git utilizando su nombre de usuario (correo electrónico) y contraseña de
Heroku. Use una clave API como se describe en esta sección

Si, por algún motivo, se autentica en el servicio Git con credenciales incorrectas, obtendrá este error:

remote: ! WARNING:
remote: ! Do not authenticate with username and password using git.
remote: ! Run `heroku login` to update your credentials, then retry the git command.
remote: ! See documentation for details: https://devcenter.heroku.com/articles/git#http-git-authentication

Cuando lo haga heroku login , la CLI escribirá una entrada git.heroku.com en su .netrc archivo (o su equivalente de Windows). Dado
que el cliente Git usa cURL cuando interactúa con los controles remotos HTTP Git, la autenticación correcta ahora se realizará de
forma transparente.

Si está utilizando otros clientes Git, como EGit o Tower, configúrelos para usar una cadena vacía para el nombre de usuario (o
cualquier cadena que desee, se ignora) y la clave API de su cuenta para la contraseña. La clave API está disponible en la CLI
(https://devcenter.heroku.com/articles/authentication#retrieving-the-api-token) y en el Panel
(https://dashboard.heroku.com/account) de control (https://dashboard.heroku.com/account) .

SSH Git transport

El transporte Git predeterminado configurado por la CLI de Heroku es HTTP, pero también se admite el transporte SSH. El transporte
SSH y HTTP puede ser usado indistintamente por el mismo usuario y por múltiples usuarios que colaboran en la misma aplicación.
Para que el transporte de configuración SSH Heroku CLI, se puede pasar una --ssh-git bandera para las heroku create , heroku
git:remote y los heroku git:clone comandos.

$ heroku create --ssh-git

Para utilizar el transporte SSH Git, debe registrar su clave SSH con Heroku. Consulte el artículo Gestión de claves SSH
(https://devcenter.heroku.com/articles/keys) para obtener más información.

Si desea usar siempre SSH Git con Heroku en una máquina en particular, puede agregar la siguiente configuración global:

$ git config --global url.ssh://git@heroku.com/.insteadOf https://git.heroku.com/

Las URL HTTP aún se escribirán en .git carpetas, pero Git reescribirá, sobre la marcha, todas las URL Herit HTTP Git para usar SSH.

Para eliminar esta configuración de reescritura, ejecute:

$ git config --global --remove-section url.ssh://git@heroku.com/

t El transporte SSH Git no es compatible con usuarios SSO; Los usuarios de SSO deben usar el transporte HTTP Git.

Múltiples controles remotos y entornos.

Las mismas técnicas que se usan para implementar en producción se pueden usar para implementar una rama de desarrollo de su
aplicación en una aplicación provisional en Heroku, como se describe en Administración de entornos múltiples para una aplicación
(https://devcenter.heroku.com/articles/multiple-environments) .

Construir caché
Los paquetes de compilación (https://devcenter.heroku.com/articles/buildpacks) pueden opcionalmente almacenar en caché el
contenido (como las dependencias de la aplicación) para acelerar en gran medida futuras compilaciones.

Si sospecha que un error en esta memoria caché está causando un problema de compilación, puede usar el heroku-repo
(https://github.com/heroku/heroku-repo)complemento para borrarlo.

Tamaño del repositorio

Aunque no hay un límite estricto en el tamaño de su repositorio, no se recomiendan repositorios muy grandes (más de 600 MB);
pueden causar tiempos de espera y empujes lentos en general. La ejecución heroku apps:info le mostrará el tamaño de su repositorio.
El caché de compilación de la aplicación se almacena dentro del repositorio de la aplicación, así que no se sorprenda si el repositorio es
más grande de forma remota que local.

Las causas comunes de los repositorios grandes son los archivos binarios registrados en el repositorio (Git es notoriamente malo en el
manejo de binarios) o los registros de desarrollo que cambian constantemente. La eliminación de archivos cometidos por accidente se
puede hacer con git filter-branch (http://git-scm.com/book/en/Git-Internals-Maintenance-and-Data-Recovery#_removing_objects) ,
aunque después de ejecutarlo tendrá que presionar con la --force opción, que es algo que requiere coordinación entre su equipo.

Otros limites
Para proteger el servicio Git, Heroku impone ciertos límites en el uso del repositorio Git y el tamaño del contenido.

Los usuarios están limitados a una ventana móvil de 75 solicitudes Git por hora, por usuario, por aplicación. Una vez que se alcanza
este límite, se rechazan las solicitudes de Git hasta que los niveles de solicitud caigan por debajo del límite durante unos minutos, con
el mensaje de error:

! Too many requests for this Git repo. Please try again later.

Si alcanza este límite, asegúrese de que no haya procesos automatizados o scripts que sondeen el repositorio de Git.

Además, el tamaño sin comprimir de un pago HEAD desde el repositorio, combinado con el tamaño de los submódulos restaurados, no
puede exceder 1 GB.

Usar subversión u otros sistemas de control de revisión

¿Qué sucede si ya está utilizando Subversion u otro sistema de control de revisiones para rastrear su código fuente? Aunque creemos
que Git es una de las mejores opciones disponibles para el control de revisión, no necesita dejar de usar su sistema de control de
revisión actual. Git puede ser puramente un mecanismo de implementación, existente al lado de su otra herramienta.

t Puedes aprender mucho más .gitignore en nuestro artículo sobre el tema (https://devcenter.heroku.com/articles/gitignore)
.

Por ejemplo, si está utilizando Subversion, inicialice su repositorio Git como se describe anteriormente. Luego, agregue un
.gitignore archivo para decirle a Git que ignore sus directorios de Subversion.

$ git init
$ echo .svn > .gitignore
$ git add .
$ git commit -m "using git for heroku deployment"

Ahora dile a Subversion que ignore a Git:

$ svn propset svn:ignore .git .

property 'svn:ignore' set on '.'
$ svn commit -m "ignoring git folder (git is used for heroku deployment)"

t Se -f recomienda el (indicador de fuerza) para evitar conflictos con los empujes de otros desarrolladores. Como no está utilizando
Git para su control de revisión, sino solo como transporte, usar la bandera de fuerza es una práctica razonable.

Cada vez que desee implementar en Heroku:

$ git add -A
$ git commit -m "commit for deploy to heroku"
...

$ git push -f heroku

Recursos adicionales
Git on Rails (http://railscasts.com/episodes/96) muestra convenciones comunes para usar Git para rastrear aplicaciones Rails.

Git Cheat Sheets para web (http://cheat.errtheblog.com/s/git) y consumo de impresión

(http://res.cloudinary.com/hy4kyit2a/image/upload/SF_git_cheatsheet.pdf) .

Git - Curso intensivo SVN (http://git.or.cz/course/svn.html)

El libro Pro Git (https://git-scm.com/book) es un gran recurso que cubre todo Git.