Question

我们正在Rails中建立一个项目，事实是为此目的，我们有两个git repos，一个是bitbucket（我们一直在跟踪该项目），另一个是Heroku（生产）。我们必须将凭证文件上传到Heroku中，以便应用程序可以正常运行，但是我们不希望将该文件上传到Bitbucket上以解决安全问题，因此我们的问题是：我们可以在gitignore文件中设置某种选项来上传凭证吗？文件只是给Heroku而没有给bitbucket？预先感谢。

我们尝试通过transfer.sh和gpg上传文件，但我们不希望使用它，因为此文件在安全性方面非常微妙。由于Heroku会自动删除文件，因此无法使用heroku bash创建文件。

Answer 1

我们可以在gitignore文件中设置某种选项以将凭据文件仅上传到Heroku，将否上传到bitbucket吗？

不。尽管在任何情况下将凭据存储在存储库中通常都是错误的主意，但您仍有可以做的几件事。

Git与文件无关。 Git与 commits 有关。提交包含文件，因此通过获取和使用提交，您可以获取这些文件，但是Git的基本单位是提交。

与此同时，.gitignore 是关于文件的-具体来说，您的工作树中的文件不会在将来的提交中使用。人们遇到了一个绊脚石，因为您构建的 new 提交包含Git称为 index 的内容。但是，最后，如果忽略项有效，那是因为它可以防止文件进入 next 提交。 此处的机制（即.gitignore文件）完全无关。

如果您不让文件进入下一个提交，而最终提交到Bitbucket，那么，当相同提交也进入Heroku时，，该提交也将没有该文件。

同样，如果并且当您将文件放入最终进入Heroku系统的提交中时，那么，如果以及何时 same 提交也进入到Bitbucket，该提交将继续拥有该文件。

这使情况变得很清楚：如果提交中包含文件，则无论提交的人都有该文件。可以将提交到Heroku中，而从未发送到Bitbucket，但这是因为Git通常围绕一种哲学设计，它倾向于将每个提交给每个人，认真思考如何您打算确保安全数据永远不会泄漏，然后再尝试。

如果您仍然不愿意这样做，请注意.gitignore可能是错误的机制，有时可能会将文件放入特定的提交中，有时将文件拒之门外。（这是因为.gitignore条目仅在文件尚未在索引中时有效，并检查出具有文件的所有提交，文件添加到索引中，以便 next 提交也将具有该文件，而不管任何.gitignore条目如何。）

Answer 2

您可以使这种情况发生，但可能不完全符合您的描述。

当git推送（或拉取）时，它根据“引用”及其历史进行通信。引用的历史记录由提交组成。在这种情况下，提交是不可变的，可以认为是原子的-您要么发送提交，要么不发送。提交中包含目录和文件的结构（大致），这些目录和文件构成了项目内容的快照。

因此，为了在发送到heroku时包含文件，而在发送到bitbucket时不包含文件，则需要向每个存储库发送不同的提交。实际上，这意味着您应该发送不同的参考。很好-您可以将文件放在“生产分支”上，而不要放在任何其他分支上。您可以从推送到bitbucket的过程中省略生产分支，并将其包含在推送到heroku的推送中。

理论上就是这么简单。您开始一个没有敏感文件的仓库。您映射到遥控器-例如，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推送到bitbucket，但是您要做希望将其推送到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)

所以你再次按下heroku

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。如果您绝对需要支持此案，我可以添加一些想法，但最好的建议是使可发布的历史沿一个方向发展（这通常也是您的{{ 1}}分支总会为您服务）。

如果您完全按照我上面的描述进行操作，您会发现存在很大的人为错误余地。作为故障保护，您可能只想创建一个特殊的本地存储库即可在其中构建生产分支。（如果您的其他本地存储库中不包含master，则不能将production从它们中意外推送到bitbucket。）您可能还需要调整该特殊存储库的配置，因此默认情况下，推送会发送本地production到heroku production。（有关执行此操作的选项的更多信息，请参见git config文档。）

有什么方法可以将gitignore忽略的文件仅上传到特定的仓库吗？

2 个答案: