Вы можете сделать это, но, может быть, не совсем так, как вы описали.
Когда git толкает (или тянет), он общается в терминах "ссылок" и их истории.История ссылки состоит из коммитов.В этом контексте коммит является неизменным и может рассматриваться как атомарный - вы либо отправляете коммит, либо нет.В коммите есть структура каталогов и файлов (примерно), которые составляют снимок содержимого проекта.
Таким образом, чтобы включить файл при отправке в heroku, но не при отправке в bitbucket,Вам необходимо отправить различных коммитов каждому репо.Что на практике означает, что вы должны отправлять разные ссылки.И это нормально - вы можете иметь файл в «производственной ветке», а не в других ветках.Вы можете опустить производственную ветку от ваших пушей до битбакета и включить ее в свои пушы к героку.
Теоретически это так просто.Вы запускаете репо без конфиденциального файла.Вы наносите на карту пульты - скажем, origin сопоставляет с bitbucket, а heroku сопоставляет с вашим репозиторием prod heroku.
Вы позволяете программному обеспечению расти, и в итоге у вас есть версия, которую вы хотите опубликовать в рабочей среде.
O -- ... -- A <--(master)(origin/master)
(Здесь O - это ваш начальный коммит; ... представляет любой вид истории вообще - возможно, с ветвлениями и слияниями и т. Д .; и A - это коммит, который вы хотите опубликоватьЯ показал, что он находится на ветке master, что согласуется с такими моделями, как GitFlow, но в этом нет особой необходимости.)
Итак, вы проверяете эту версию, а затем
git checkout -b production
# create/copy the sensitive file into your work tree
git add path/to/sensitive file
git commit -m "production release 1"
Теперь у вас есть
O -- ... -- A <--(master)(origin/master)
\
P1 <--(production)
Вы не хотите помещать production в битбакет, но вы do хотите отправить его в Heroku.Обратите внимание, что ваша производственная ветка в репозитории heroku должна называться master, поэтому вы можете сказать что-то вроде
git push heroku production:master
и у вас будет
O -- ... -- A <--(master)(origin/master)
\
P1 <--(production)(heroku/master)
Затем в ваши местные филиалы приходит больше коммитов, и в конце концов вы хотите опубликовать снова.
O -- ... -- A -- ... -- B <--(master)(origin/master)
\
P1 <--(production)(heroku/master)
В этом сценарии вы можете просто
git checkout production
git merge master
База слияния будет A.Единственное изменение с A на production - добавление конфиденциального файла, а master не имеет конфиденциального файла (поэтому не может быть внесен в него конфликтующие изменения);поэтому слияние должно пройти гладко, и вы получите
O -- ... -- A -- ... -- B <--(master)(origin/master)
\ \
P1 --------- P2 <--(production)
^(heroku/master)
Итак, вы снова толкаете к героку
git push heroku production:master
, заканчивающемуся на
O -- ... -- A -- ... -- B <--(master)(origin/master)
\ \
P1 --------- P2 <--(production)(heroku/master)
Чтобы сохранить слияния вproduction ветвь простая, каждый раз, когда вы выпускаете новую версию (например, B), вы хотите, чтобы предыдущая версия (например, A) была "достижимой" с B.Большинство моделей ветвления даст вам это.Но по какой-то причине вы могли бы сделать что-то вроде
x -- x -- C <--(special-release)
/
O -- ... -- A -- ... -- B <--(master)(origin/master)
\ \
P1 --------- P2 <--(production)(heroku/master)
В этом случае простое слияние не сработало бы для обновления production, так что оно "выглядит" C.Если вы чувствуете, что вам абсолютно необходимо поддержать это дело, я могу добавить некоторые соображения о том, как это сделать, но лучший совет - это продолжать выпускать историю, движущуюся в одном направлении (что, опять же, часто является тем, что ваша * 1068В любом случае * ветка будет делать для вас).
Вы можете видеть, что есть много места для человеческой ошибки, если вы просто сделаете именно то, что я описал выше.В качестве отказоустойчивого устройства вы можете создать только один специальный локальный репозиторий, в котором вы создаете производственную ветку.(Если ваши другие локальные репозитории не содержат production, вы не можете случайно отправить production из них в bitbucket.) Вы также можете изменить конфигурацию этого специального репо, чтобы при отправке по умолчанию локальный * 1073 отправлялся* Герою master.(См. Документацию по git config для получения дополнительной информации об опциях для этого.)