Git протолкнуть текущую ветку на пульт с Heroku

Question

Я пытаюсь создать промежуточную ветку на Heroku, но есть кое-что, чего я не совсем понимаю.

Предполагая, что я уже создал приложение heroku и настроил пульт, чтобы он указывал на staging-remote, если я это сделаю:

git checkout -b staging staging-remote/master

Я получаю локальную ветвь, называемую «staging», которая отслеживает staging-remote / master - или я так думал ....

Но:

git remote show staging-remote

Дает мне это:

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)

Как видите, вытягивание выглядит разумным, но по умолчанию - нет. Это означает, что если я сделаю:

git push staging-remote

Я собираюсь подтолкнуть мою локальную главную ветвь к промежуточной. Но это не то, что я хочу .... По сути, я хочу объединить обновления в мою промежуточную ветку, а затем легко перенести ее в heroku без необходимости указывать ветку следующим образом:

git push staging-remote mybranch:master

Вышесказанное не сложно сделать, но я хочу избежать случайного выполнения предыдущего нажатия и нажатия неверной ветви ... Это вдвойне важно для производственной ветви, которую я хотел бы создать!

Я пробовал возиться с git config, но пока не понял, как это сделать ...

Answer 1

Я проверил это, и версии @juba и @ MatthewFord работают отлично!

git config remote.staging.push staging:master

Это выдвигает мою локальную ветку темы с именем staging в удаленную ветку master в удаленном хранилище с именем staging .

@ nickgrim выразился в общем виде примерно так:

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

Обновление:

Кроме того, современный git будет удобно запускать указанную выше команду конфигурации для вас, когда вы git push с опцией -u:

git push -u staging staging:master

Answer 2

У меня есть ветка под названием heroku, и у меня это сработало:

git config remote.heroku.push heroku:master

проблема, с которой вы сталкиваетесь, заключается в том, что герою игнорирует все ветви, кроме мастера.

Answer 3

Из книги «O’Reilly - Контроль версий с помощью Git» стр. 184 | Глава 11: Удаленные репозитории

Во время операции git push вы обычно хотите предоставить и опубликовать изменения ты сделал на твоей локальной теме ветки. Чтобы другие могли найти ваши изменения в Удаленный репозиторий после их загрузки ваши изменения должны появиться в этом репозитории как ветки тем. Таким образом, во время типичной команды git push, источник ответвляется от ваш репозиторий отправляется в удаленный репозиторий с использованием refspec, например:

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

Этот refspec можно перефразировать как: Из локального репозитория возьмите каждое имя ветви, найденное в пространстве имен источника refs/heads/ и поместите его в совпадающую ветвь с тем же именем под местом назначения Пространство имен refs/heads/ в удаленном хранилище. Первый refs/heads/ относится к вашему локальному репозиторию (потому что вы выполняете push), а второй относится к удаленному хранилищу. Звездочки гарантируют, что все ветви тиражируются. ...

---

Вот почему пример с Джубы должен провалиться. исправленный refspec должен быть:

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

Answer 4

Со страницы Everiday Git с 20 командами или около того :

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

Кажется, что вы можете достичь того, что вы хотите сделать, добавив конфигурациюдиректива к вашему локальному репозиторию git, что-то вроде:

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

Затем, если вы делаете git push из вашей локальной ветки mybranch , она должна быть передана мастеру ветка вашего staging-remote remote.

Тем не менее, пожалуйста, проверьте с помощью git remote show staging-remote и тщательно протестируйте его перед использованием, так как я далеко не эксперт по git ...

Answer 5

Это работает. Я использовал его несколько раз для настройки клиентов с помощью git-flow, heroku и службы резервного копирования git.

.git / config для репозитория:

[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

Все работает правильно:

git push origin

git pull origin

git push staging

git push production

Думайте о извлечении и отправке как о stdout и stdin, где оба могут быть перенаправлены или закрыты, чтобы быть одним из способов. Кроме того, если кто-то знает, как получить эти настройки без взлома .git / config, пожалуйста, не стесняйтесь вносить изменения с помощью редактирования, обязательно следуйте пунктам кармы.

Answer 6

У меня та же проблема, когда я пытаюсь понять, как справиться с политикой Heroku игнорировать все ветви, кроме «master». Это своего рода побеждает весь смысл сохранения отдельных веток, если вы можете только когда-либо тестировать основную ветку на Heroku.

Следствием этого ограничения является то, что независимо от локальной ветки темы, над которой я могу работать, я бы хотел простой способ переключить мастер Heroku на эту локальную ветку темы и выполнить "git push -f", чтобы перезаписать мастер на Heroku. Само собой разумеется, было бы очень хорошей идеей иметь отдельный удаленный репозиторий (например, Github), чтобы выполнять резервное копирование всего без этого ограничения. Я бы назвал это «происхождение» и использовал бы «heroku» для Heroku, чтобы «git push» всегда делал резервные копии всего.

То, что я получил от прочтения раздела "Pushing Refspecs" http://progit.org/book/ch9-5.html, равно

git push heroku local-topic-branch: refs /heads / master

Что мне действительно нравится, так это способ установить это в конфигурационном файле так, чтобы «git push heroku» всегда делал вышеуказанное, заменяя «local-topic-branch» именем того, что происходит с моей текущей веткой. будет.

Я могу задать этот вопрос как новый вопрос, чтобы выяснить, понял ли кто-нибудь еще, как это сделать.

Answer 7

Я не мог придумать, как это сделать, но в конце концов я нашел удобное задание по рейку, чтобы упростить его: http://www.jbarnette.com/2009/11/10/deploying-to-heroku.html