Domanda

Sto cercando di creare un ramo messa in scena su Heroku, ma c'è qualcosa che non riesce quasi mai.

Supponendo che ho già creato un app Heroku e la configurazione del telecomando per puntare a messa in scena-a distanza, se faccio:

git checkout -b staging staging-remote/master

ho un ramo locale chiamato 'messa in scena', che tiene traccia di sosta-remote / padrone - o questo è quello che ho pensato ....

Ma:

git remote show staging-remote

mi dà questo:

remote staging
  Fetch URL: git@heroku.com:myappname.git
  Push  URL: git@heroku.com:myappname.git
  HEAD branch: master
  Remote branch:
    master tracked
  Local branch configured for 'git pull':
    staging-remote merges with remote master
  Local ref configured for 'git push':
    master pushes to master (up to date)

Come si può vedere, il tiro sembra ragionevole, ma la spinta di default non lo fa. Ciò implica che se faccio:

git push-staging remoto

ho intenzione di spingere il mio ramo principale locale fino al ramo messa in scena. Ma non è quello che voglio .... Fondamentalmente, io voglio unire gli aggiornamenti nel mio ramo messa in scena, quindi facilmente spingerlo a Heroku senza dover specificare il ramo in questo modo:

git push staging-remote mybranch:master

È possibile che questo non è difficile da fare, ma voglio evitare accidentalmente fare la spinta precedente e spingendo il ramo sbagliato ... Questo è doppiamente importante per la filiale di produzione mi piacerebbe creare!

Ho provato scherzi con git config, ma non ho capito come ottenere questo diritto ancora ...

È stato utile?

Soluzione

Ho testato e @juba e @ versioni di MatthewFord funzionano perfettamente!

git config remote.staging.push staging:master

Questo spinge il mio ramo argomento locale denominato messa in scena nel ramo remoto Master sul repository remoto denominato messa in scena .

@nickgrim metterlo nella forma generale in questo modo:

git config remote.[remoteRepositoryName].push [localBranchName]:[remoteBranchName]

Aggiornamento:

Inoltre, git moderna vi porta comodamente eseguire il comando di configurazione di cui sopra per voi quando si git push con l'opzione -u:

git push -u staging staging:master

Altri suggerimenti

Ho un ramo chiamato Heroku, e questo ha funzionato per me:

git config remote.heroku.push heroku:master

il problema si sta affrontando è Heroku ignora tutti i rami diversi da padrone.

Dal libro "O'Reilly - Controllo di Versione con Git" Pagina 184 | Capitolo 11: Archivi remoti

  

Durante un'operazione git push, in genere si desidera fornire e pubblicare le modifiche   che hai fatto sul tuo argomento filiali locali. Per consentire ad altri per trovare le modifiche nel   repository remoto dopo averli caricati, le modifiche deve apparire in quel repository come argomento rami. Così, durante un tipico comando git push, i rami di origine dal   il repository vengono inviati al repository remoto utilizzando un refspec come ad esempio:

+refs/heads/*:refs/heads/*
     

Questa refspec può essere parafrasato come:   Dal repository locale, prendere ogni nome del ramo che si trova sotto lo spazio dei nomi fonte   refs/heads/ e metterlo in un ramo corrispondenza nome simile sotto la destinazione   namespace refs/heads/ nel repository remoto.   Il primo si riferisce alla refs/heads/ repository locale (perché si sta eseguendo una spinta),   e la seconda si riferisce al repository remoto. Gli asterischi garantire che tutti i rami   vengono replicati.   ...


Ecco perché l'esempio da Juba dovesse fallire. il refspec corretto dovrebbe essere:

git config remote.staging-remote.push +refs/heads/local_branch_name:refs/heads/master

Dalla pagina sua quotidiana Git con 20 comandi o giù di lì :

http://www.kernel.org/pub /software/scm/git/docs/everyday.html

Sembra che si può ottenere ciò che si vuole fare con l'aggiunta di una direttiva di configurazione al repository git locale, qualcosa di simile:

git config remote.staging-remote.push mybranch:refs/remotes/staging-remote/master

Quindi, se si fa un git push dal mybranch filiale locale, dovrebbe essere spinta al Master ramo del messa in scena-remoto remote.

Tuttavia, si prega di verificare con git remote show staging-remote e con attenzione testarlo prima di utilizzarlo, come io sono lontano da un esperto di git ...

Non ho potuto trovare un modo per fare questo, ma alla fine ho trovato un compito rastrello a portata di mano per rendere più facile: http://www.jbarnette.com/2009/11/ 10 / Distribuzione-to-heroku.html

Sto avendo lo stesso problema cercando di capire come trattare con la politica di Heroku di ignorare tutti i rami, ma 'master'. Sconfigge po 'il punto centrale di mantenere rami separati se si può sempre e solo testare il ramo master sul Heroku.

La conseguenza di questa limitazione è che qualunque argomento filiale locale mi sia lavorando, mi piacerebbe un modo semplice per cambiare padrone di Heroku a quel ramo argomento locale e fare un "git push -f" da padroneggiare over-write su Heroku. Inutile dire che sarebbe una buona idea avere un repository remoto separato (come Github), per eseguire il tutto senza questa restrizione. Io chiamerei quella "origine" e usare "Heroku" per Heroku in modo che "git push" si capiscono sempre tutto.

Quello che ho ottenuto dalla lettura della sezione "Pushing Refspecs" di http://progit.org /book/ch9-5.html è

git push Heroku locale-topic-branch: refs / teste / master

Quello che mi piacerebbe davvero è un modo per impostare questa funzione nel file di configurazione in modo che "Heroku git push" fa sempre quanto sopra, sostituendo "locale-argomento-ramo" con il nome di qualsiasi mio ramo corrente succede essere.

posso chiedere questo come una nuova domanda, per vedere se qualcun altro ha capito come fare questo.

Questo funziona. L'ho usato più di un paio di volte per la creazione di client con git-flow, Heroku, e un servizio di backup git.

.git / config per il pronti contro termine:

[core]
  repositoryformatversion = 0
  filemode = true
  bare = false
  logallrefupdates = true
  ignorecase = true
[heroku]
  account = youraccount
[remote "origin"]
  url = git@bitbucket.org:youruser/yoursite.heroku.com.git # or github, etc.
  fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
  remote = origin
  merge = refs/heads/master
[branch "staging"]
  remote = origin
  merge = refs/heads/staging
[branch "develop"]
  remote = origin
  merge = refs/heads/develop
[remote "production"]
  pushurl = git@heroku.com:your-prod-app.git
  push = master:master
[remote "staging"]
  pushurl = git@heroku.com:your-staging-app.git
  push = staging:master

Tutto funziona correttamente:

git push origin

git pull origin

git push staging

git push production

Pensate a recuperare e spingere come come stdout e stdin, dove entrambi possono essere reindirizzato o chiusa per essere un modo. Anche se qualcuno sa come ottenere queste impostazioni senza l'hacking .git / config, non esitate a modificare con una modifica, punti karma sono sicuri di seguire.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top