Нажатие мерзавца текущее ответвление к удаленному с Heroku
Я пытаюсь создать ответвление подготовки по Heroku, но существует что-то, что я не вполне получаю.
Принятие я уже создал heroku приложение и устанавливаю удаленное для указания на удаленный от подготовки, Если я делаю:
git checkout -b staging staging-remote/master
Я добираюсь, локальное ответвление назвало 'подготовку', которая отслеживает 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)
Как Вы видите, получение по запросу выглядит разумным, но нажатие по умолчанию не делает. Это подразумевает это, если я делаю:
удаленное от подготовки нажатие мерзавца
Я собираюсь продвинуть свое локальное основное ответвление до ответвления подготовки. Но это не то, что я хочу.... В основном я хочу объединить обновления в свое ответвление подготовки, тогда легко продвинуть его к heroku, не имея необходимость определять ответвление как так:
git push staging-remote mybranch:master
Вышеупомянутое не трудно сделать, но я не хочу случайно делать предыдущее нажатие и продвигать неправильное ответвление... Это вдвойне важно для производственного ответвления, которое я хотел бы создать!
Я попытался смешать с конфигурацией мерзавца, но не выяснил, как разобраться в этом все же...
5 ответов
Я не мог найти способ сделать это, но в конце концов я нашел удобную задачу rake, чтобы сделать это проще: http://www.jbarnette.com/2009/11/10/deploying-to-heroku.html
Со страницы Everiday Git с 20 командами или около того :
http://www.kernel.org/pub/ программное обеспечение / scm / git / docs / каждый день.html
Кажется, что вы можете добиться того, чего хотите, добавив директиву config в локальный репозиторий git, например:
git config remote.staging-remote.push mybranch:refs/remotes/staging-remote/master
Затем, если вы выполните git push из своего ] mybranch локальную ветвь, она должна быть отправлена в ветвь master вашего staging-remote удаленного.
Тем не менее, проверьте с помощью git remote show staging-remote и внимательно проверьте его перед использованием, так как я далек от эксперта по git ...
У меня есть ветка heroku, и это сработало для меня:
git config remote.heroku.push heroku:master
проблема, с которой вы столкнулись, заключается в том, что heroku игнорирует все ветки, кроме master.
У меня та же проблема, пытаюсь понять, как справиться с политикой Heroku по игнорированию всех веток, кроме "master". Это как бы сводит на нет весь смысл поддержания отдельных веток, если на Heroku можно тестировать только главную ветку.
Следствием этого ограничения является то, что над какой бы локальной тематической веткой я ни работал, мне бы хотелось иметь простой способ переключить мастер Heroku на эту локальную тематическую ветку и сделать "git push -f", чтобы перезаписать мастер на Heroku. Излишне говорить, что было бы очень хорошей идеей иметь отдельный удаленный репозиторий (например, Github), чтобы делать резервные копии без этого ограничения. Я бы назвал его "origin" и использовал "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" на имя любой моей текущей ветки.
Я могу задать это как новый вопрос, чтобы узнать, не придумал ли кто-нибудь еще, как это сделать.
Из книги "O'Reilly - Version Control with Git" page 184 | Chapter 11: Remote Repositories
Во время операции git push вы обычно хотите предоставить и опубликовать изменения, которые вы сделали в локальных ветках темы. сделанные вами в локальной ветке темы. Чтобы другие могли найти ваши изменения в удаленном репозитории после загрузки, ваши изменения должны появиться в этом репозитории в виде тематических веток. Таким образом, во время типичной команды git push исходные ветви из вашего репозитория отправляются в удаленный репозиторий с помощью refspec, например:
+refs/heads/*:refs/heads/*Этот refspec можно перефразировать следующим образом: Из локального хранилища взять каждое имя ветви, найденное в пространстве имен источника
refs/heads/и поместите его в аналогично названную, соответствующую ветвь в пространстве имен назначения пространства именrefs/heads/в удаленном хранилище. Первыйrefs/heads/относится к вашему локальному репозиторию (поскольку вы выполняете push), а второй относится к удаленному хранилищу. Звездочки гарантируют, что все ветви реплицируются. ...
Вот почему пример из juba должен потерпеть неудачу. исправленный refspec должен быть:
git config remote.staging-remote.push +refs/heads/local_branch_name:refs/heads/master