5

我有很多虚拟主机网站，目前正在通过 chrooted SFTP 进行更新。更新由客户（通常使用 Dreamweaver 和 CuteFTP/Filezilla）和我公司的员工（通常使用 Eclipse Team Syncronisation 和 JCraft SFTP）完成。除非客户与我们同时编辑他们的网站，否则此设置可以正常工作。在这种情况下，我们必须不断同步以检查既慢又不可靠的变化。考虑到每个站点中的大量文件、缓慢的目录遍历和缺乏增量压缩，SFTP 传输也很慢。

我想转向（部分）Git 工作流程，主要是为了从增量压缩中受益，同时也引入一些基本的修订控制。我说“初级”是因为在将更改捆绑到 git 提交之前在本地开发和测试的典型 git 工作流程不适合我们的需求，因为：

  • 为了方便或兼容，我们的一些客户需要使用 SFTP，而不是 Git
  • 我不想强制使用特定的 SFTP 客户端（如 git-ftp）。我们的客户对自己的选择感到满意（例如 Dreamweaver 或 CuteFTP）。它们可能在任何操作系统上，并且不使用 shell。
  • 我们的客户都不能在本地进行测试，每个小的更改都必须上传到网络服务器并立即“上线”（我们有测试站点，所以在这种情况下“上线”不一定意味着“生产”或“公开”）
  • 大约 90% 的更改将是小的 1 行 CSS/HTML 更改，这使得提交消息非常耗时。
  • 一些更改是通过 shell 或脚本直接在服务器 webroot 上完成的。

我想我想要的是远程 git repo 使用 webroot 作为工作目录，并自动提交在那里更改的任何文件，并带有一条通用消息，指示哪些文件已更改。但是，我一直在阅读，项目的主仓库不应该有工作目录（git init --bare），即使有，通常也不会提交在那里所做的更改。我不在乎此设置是否会丢失提交的所有权详细信息（因为它不知道谁更改了文件，我通常不在乎）。

失败了，我基本上想使用 Git 作为 Rsync-over-SSH 的替代品（Eclipse Team Sync 似乎不支持它）。任何暗示另一种技术的答案都需要支持 Eclipse（我选择的工具）和 Dreamweaver（我的客户选择的主要工具）。我意识到这并不理想，但没有商量余地。如果我可以强制使用 Git，我会的，这个问题将无关紧要。我必须与数百个客户打交道，主要是 Mac 上的图形设计师。

PS。我意识到当客户端没有足够定期地重新同步他们的本地文件时会出现问题。任何有关处理的建议将不胜感激。

任何人都可以提供有关此设置的指导（Centos 6.4 linux）。

4

4 回答 4

3

对于直接在服务器上（或通过 SFTP）进行的更改：

看看Gitwatch，它是“用于监视文件或文件夹并将更改提交到 git 存储库的 bash 脚本”。它似乎正是您正在寻找的东西。

您可能希望您的 webroot 不是作为主要存储库，而是作为远程克隆存储库。在其他地方（如 github 或 bitbucket）设置您的主节点，将其克隆到网络服务器上。用于gitwatch监控更改、自动提交和推送到您的主/github 存储库。

使用 github/bitbucket 等单独的主存储库的一大好处是，您可以轻松查看/查看正在进行的更改，并根据需要自行在本地将其拉下，而无需直接访问网络服务器上的 git 存储库。

对于通过 git 进行的更改：

您是否还希望通过 git 进行更改并将它们自动拉到网络服务器上？从理论上讲，您可以在 git 中连接一个接收后挂钩来为您执行此操作。但是，如果同时直接在服务器上进行更改，则很容易发生合并冲突。

再三考虑，避免这种情况。坚持使用单向网络服务器 -> 本地提交 -> 推送到主 git 存储库。

在此处插入免责声明，说明这不是 git 的正确用户、违反各种规则并违反最佳实践。您似乎已经很清楚这一点，所以我将跳过它。=)

于 2013-04-06T19:43:58.320 回答
3

对我来说，您应该设置一个持续集成工具，例如Jenkins、CruiseControl或许多其他替代方案之一，配置为部署在 Web 服务器上。

你需要：

  1. 每个网站的存储库，可通过 sftp 访问并观看gitwatch以提交更改（如jszobody建议的那样）和一个用于拉/推/ask_for_help_via_email_to_a_developer_if_merge_fails的gitook
  2. 一个“中央”存储库，开发人员和钩子将推送每个提交。
  3. 您选择的 CI 工具，在中央存储库收到的每次推送时，都会唤醒并将更新的内容发送到网络服务器（sftp、直接 fs 访问……什么对您更好）。
  4. 一个 Web 服务器，现在不需要通过 git 或通过 sftp 提供公共访问。

优点：

  • 涵盖您的所有要求
  • 不需要中央存储库中的工作目录
  • 无需在网络服务器上打开更多端口（显然，http/https 除外）
  • 无需在 Web 服务器上安装 git
  • 无需使用存储库历史（包含在.git/文件夹中）重载 Web 服务器的文件系统
  • 相当灵活
  • 易于演变为功能齐全的 CI 解决方案（自动化测试、代码指标等）
  • 处理不同步的客户端，因为钩子将无法合并，并且会警告开发人员

缺点：

  • 复杂，因此设置成本高
  • 您必须告知您的客户要使用的新 sftp 地址（除非您明智地使用了不同的子域并且您可以等待DNS 更新）。
于 2013-04-11T21:25:23.923 回答
1

我没有看到让一百个开发人员部署到单个 Web 服务器并尝试在那里跟踪他们的更改的意义，但是快速而肮脏的方法是使用 cron 作业git add .并将git push --force服务器克隆到其他地方的适当镜像您可以更好地管理合并并推回服务器克隆（应该在不同的分支上）。服务器克隆（对于那些不可见 git 的设计人员）从外观上看几乎总是很脏，因此您可能希望放宽 cron 间隔。

于 2013-04-06T20:15:23.740 回答
0

也许在 dulwich 之上定制的东西会满足你的需要，某种基于 python 的网络服务器来管理 repos。https://github.com/jelmer/dulwich

于 2015-11-12T13:15:09.963 回答