remove - Github: Reflejando gh-páginas para dominar
git tag release github (8)
Estoy desarrollando un plugin jQuery que hospeda en GitHub. Tiene una demostración incluida de la cual estoy copiando manualmente y presionando a la rama gh-pages , lo que me gustaría hacer es tenerlo así que cuando presiono un cambio para master , automáticamente se pasa a gh-pages , o a al menos una configuración donde están duplicados.
Ya he visto esta question pero no estoy seguro de si realmente responde mi pregunta con respecto a estos requisitos:
- Yo uso Tower , no me importa usar la terminal (Mac) para hacer cambios en la configuración, siempre y cuando la solución funcione con esta GUI.
- Solo quiero este ''reflejo'' en ciertos repositorios, no en todos ellos en mi máquina.
Aclamaciones
Agregue las siguientes 2 líneas a la sección [remote "origin"] de .git/config :
push = +refs/heads/master:refs/heads/gh-pages
push = +refs/heads/master:refs/heads/master
Cada vez que lo push , automáticamente enviará maestro a gh-páginas también. Estoy usando esto para el proyecto jQuery Lifestream .
Estoy agregando más explicaciones a las @denbuzze de @denbuzze y @MCSDWVL .
Si desea presionar ambos para master y gh-pages automáticamente cada vez que ejecuta git push origin , probablemente quiera agregar un Refspec a la configuración de git de su repositorio.
Entonces, de acuerdo con el libro de git-scm , puede agregar dos RefSpecs , agregando dos valores de push al archivo de configuración de repos .git/config :
[remote "origin"]
url = https://github.com/<github_user>/<repo_name>
fetch = +refs/heads/*:refs/remotes/origin/*
push = refs/heads/master:refs/heads/master
push = refs/heads/master:refs/heads/gh-pages
Eso causará un git push origin a:
- Empuje la rama
masterlocal a la ramamasterremota - Empuje la rama
masterlocal a la rama remotagh-pages
por defecto.
Nota : el uso de un + antes de la especificación causa forzar el empuje hacia el repositorio. Úselo con precaución:
El formato del refspec es un
+opcional, seguido de<src>:<dst>, donde<src>es el patrón para las referencias en el lado remoto y<dst>es donde esas referencias se escribirán localmente. El+le dice a Git que actualice la referencia, incluso si no es un avance rápido.
O simplemente puede usar el cmd a continuación, esto impulsará su rama principal local a la rama maestra gh-pages. git push -f origin master:gh-pages
Personalmente me gusta envolver esto en un alias:
alias gpogh="git checkout gh-pages && git merge master && git push origin gh-pages && git checkout -"
Esto refleja su maestro a gh-pages , empuja a github, luego vuelve a cambiar la rama anterior en la que estaba trabajando.
¡No hagas lo que denbuzze sugiere arriba ! El + (signo más) en la inserción hace que acepte silenciosamente actualizaciones que no son rápidas. Descubrí por las malas que esto puede causar irrevocablemente que se pierda trabajo al llevar a compromisos pendientes. Simplemente eliminar los signos más hace que este sea un enfoque más seguro.
push = refs/heads/master:refs/heads/gh-pages
push = refs/heads/master:refs/heads/master
ahora, en lugar de provocar una actualización de fuerza, esto provocará una sugerencia de advertencia y extracción
To https://github.com/someuser/repo.git
! [rejected] master -> gh-pages (fetch first)
! [rejected] master -> master (fetch first)
error: failed to push some refs to ''https://github.com/someuser/repo.git''
hint: Updates were rejected because the remote contains work that you do
hint: not have locally. This is usually caused by another repository pushing
hint: to the same ref. You may want to first integrate the remote changes
hint: (e.g., ''git pull ...'') before pushing again.
hint: See the ''Note about fast-forwards'' in ''git push --help'' for details.
ACTUALIZACIÓN : github.com/blog/2228-simpler-github-pages-publishing
Para mí fue mucho más fácil usar la rama gh-pages como maestro. No hay nada mágico sobre "maestro"; es solo otro nombre de sucursal. Hay algo mágico sobre gh-pages, porque ahí es donde GitHub está buscando index.html para publicar su página.
Lea más en mi otra respuesta sobre este tema .
Usar gh-pages como maestro también es más fácil que los subárboles, que son más fáciles que duplicar. Puede usar el git subtree como se describe here o here : si tiene un directorio que contiene su demostración, puede empujar ese directorio a la gh-branch con un comando. Digamos que nombra el directorio gh-pages para aclarar las cosas. Luego, una vez que haya confirmado sus cambios y los haya pasado a los master , ejecute esto para actualizar gh-pages:
git subtree push --prefix gh-pages origin gh-pages
El problema es si sus archivos en gh-pages refieren a archivos en otros directorios fuera de él. Los enlaces simbólicos no funcionan, por lo que tendrá que copiar los archivos en el directorio que sirve como gh-páginas.
Si usa gh-pages como maestro , este problema no ocurrirá.
cometer y empujar a dominar ...
entonces :
git checkout gh-pages // -> go to gh-pages branch
git rebase master // bring gh-pages up to date with master
git push origin gh-pages // commit the changes
git checkout master // return to the master branch
git checkout gh-pages
git merge master
git push origin gh-pages