使用Git更新生产服务器

我们的团队最近迁移到git

我们有生产web应用服务器，对代码做了一些小的更改

• 特定于此安装的超级热修复程序
• 针对那些无法在我们的测试环境中重现的bug，给出了一些调试语句

我认为，我们不能在服务器repo中提交这些

当我们有

svn update

时，要么合并了已更改的文件，要么没有合并。现在

 git stash; git pull; git stash pop

这把戏对我有用吗

当

git stash pop

将导致冲突时，如何自动检测这些情况

使生产工作副本损坏

我想通过发送邮件手动解决这些问题

在发生之前，它们像

被建议、取消拉拽（冲突）

我宁愿：

• 在git存储库和web文件之间保持清晰的分隔：
• 不直接在工作树目录中工作（存在隐藏问题，以便有一个干净的工作树用于拉操作）

最好推到一个单独的Git回购协议，在那里你可以做你需要的事情

---

话虽如此，我宁愿尝试在一个临时分支中解决任何冲突（从）

git分支[]

创建并签出名为

的新分支，从最初创建

的提交开始，将

中记录的更改应用于新的工作树和索引。
如果该操作成功，并且

是

stash@{}

形式的引用，则它会删除

。如果未给出

，则应用最新的

如果运行git stash save的分支发生了足够多的更改，以至于git stash apply由于冲突而失败，那么这将非常有用。由于在git stash运行时，stash应用于提交头上，因此它恢复了最初的隐藏状态，没有冲突

---

冲突解决后，该分支可以合并回主分支。

我不想承担在生产服务器上发生合并冲突的风险。我听上去完全错了

从您的帖子中，我可以推断出您在生产中存在无法在测试/登台中重现的问题。为了帮助检测这些问题，您在应用程序中添加了额外的检测工具。这是一种常见的方法，尽管你真的应该尝试在问答中再现失败（通常从长期利益的角度来看，这是值得的）

接下来我会推断，您直接在生产服务器上操作代码。你永远不应该这样做。您已经在使用git了，git为您提供了管理事物的极大灵活性，有更智能的解决方案可以解决您的问题。 以下是我想说的：

从服务器获取这些更改（创建补丁或其他内容）

将这些更改放到dev repo中的本地分支上

无论何时，只要你改变了某些东西，就在你的主脑上重新设置本地分支的基础。在当地解决冲突

由于您已经对历史进行了模拟，因此需要强制推进到生产存储库中，有关详细信息，请参阅

---

您是否不想将添加的附加日志“产品化”，使其成为非功能性需求的一部分，这也可能引起争议。

是否可以在新的分支中跟踪生产服务器上的这些小更改？我对没有存储在存储库中的任何重要代码都很谨慎，而且这种设置感觉很脆弱。不，这些是调试语句，在这种情况下，我们需要另一个应用程序安装，而不是Branch。我们在gitosis中有我们的中心repo。我意识到清洁生产的工作树是一个问题discipline@jonny：刚刚添加了一种可能的方法来处理分支中的隐藏弹出步骤。清理生产上的工作树是一个纪律性问题，我没有任何权力强制执行您添加的附加日志

 git branch <branchname> [<stash>]