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
master
local a la ramamaster
remota - Empuje la rama
master
local 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