使用Git更新生产服务器

Question

我们的团队最近已经迁移到了Git。

我们有一个生产Web应用程序服务器，对代码进行了一些小的更改：

• 针对该安装的特定超级紧急修复
• 为那些无法在我们的测试环境中重现的错误添加一些调试语句

我认为，我们不能将这些提交到服务器存储库中。

以前，当我们使用svn update时，要么合并更改的文件，要么不合并。现在：

 git stash; git pull; git stash pop

这对我很有用

如何自动检测那些情况下 git stash pop 会导致冲突，从而使生产工作副本出现问题？

我想发送邮件手动解决这些情况

在它们发生之前，像请注意，拉取已取消（冲突）

- jonny

---

那些在生产服务器上的小更改能否在新分支中被跟踪？我对任何未存储在代码库中的重要代码持谨慎态度，而这种设置感觉很脆弱。 - sarnold

不，这些是“调试语句”，在这种情况下，我们需要安装另一个应用程序而不是分支。 - jonny

Answer 1

我不想承担在生产服务器上发生合并冲突的风险。这对我来说听起来很糟糕。

从你的帖子中，我可以推断出你在生产环境中遇到了无法在测试/预发布环境中重现的问题。为了帮助检测这些问题，你添加了额外的应用程序监控工具。虽然这是一个常见的方法，但你真的应该尝试在 Q&A 中重现故障（通常值得进行一次初始投入以获得长期效益）。

接下来，我会推断你正在直接操作生产服务器上的代码。你绝不能这样做。你已经在使用 git，它为你提供了很大的灵活性，可以管理事物，有比你的问题更聪明的解决方案。 以下是我建议的步骤：

1. 从服务器获取这些更改（创建补丁或其他方式）
2. 将这些更改放到本地分支中。
3. 每当你更改某些东西时，请在主分支 HEAD 的顶部重新调整本地分支。在本地解决冲突。
4. 由于你已经模拟了历史记录，所以需要强制将其推送到生产存储库中，请参阅 如何将修改后的提交推送到远程 Git 存储库？ 以获取详细信息。

同时也可以讨论是否需要将您添加的额外日志记录“产品化”，使其成为您的非功能性需求的一部分。

- Johannes Rudolph

---

在生产环境中保持干净的工作树是一个纪律问题，而我没有权力强制执行。 - jonny

"产品化"您添加的额外日志记录：非常好的观点。 - jonny

Answer 2

我宁愿：

• 在git仓库和网页文件之间保持清晰的分离：
• 不直接在工作树目录中工作（为了进行干净的拉取操作而存在的隐藏问题）

最好是推送到一个带有post-update钩子的裸仓库，并在一个单独的Git仓库中进行需要的拉取操作。

---

那么，我宁愿尝试在一个临时分支中解决任何冲突（来自 git stash man page）。

 git branch <branchname> [<stash>]

创建并检出一个新分支，命名为<branchname>，从创建<stash>的提交开始，将记录在<stash>中的更改应用于新的工作树和索引。如果成功，并且<stash>是形式为stash@{<revision>}的引用，则删除<stash>。如果没有给出<stash>，则应用最新的<stash>。
如果您运行git stash save的分支发生了足够的更改，导致git stash apply由于冲突而失败，则此操作非常有用。由于stash是应用于运行git stash时的提交的顶部，因此它可以恢复最初的存储状态而不会产生冲突。
一旦解决了冲突，就可以将该分支合并回主分支。

- VonC

---

我们在gitosis中有我们的中央仓库。我意识到，在生产环境中保持干净的工作树是纪律问题。 - jonny

@jonny：刚刚添加了一种可能的方法来处理分支中的stash pop步骤。 - VonC