题
我在某处读过*这样的设置会很好:
两个主要分支,每个服务器一个。
推送到 master 会将更改发送到现场;
推送到 dev/stage(或者无论你怎么称呼它)会将更改发送到 staging;
工作流程:
从 dev 创建分支;
在本地工作,直到您准备好进行测试;
合并回开发;
推送到集线器,集线器将更改发送到开发/登台服务器。
一旦您准备好上线:
从 dev 合并到 master,
然后将主服务器推送到集线器,集线器将这些更改发送到实时服务器。
两个主要分支,每个服务器一个。
因此,我在“ Webroot/myliveapp/”上有一个分支“生产”,以及“ WebRoot/devapp/”上的另一个分支“开发”。
存储库应该在哪里?
更新:
我是说:
根据这个流程,我们将得到:
Prime 回购协议;
裸仓库中心;
克隆;
开发和生产分支应该属于一个存储库,对吗?
如果这是正确的,那么我们应该发出第一个 git init 命令吗?在我们的 Prime 仓库上?
所以我们将有:
“webroot/myliveapp/” - 生产分支;
“webroot/devapp/”-开发分支;
“webroot/.git”-Prime 存储库;
这有道理吗?
或者 Prime 存储库应该与我们的生产分支位置相对应吗?
*笔记:如果您需要了解我正在尝试实施的工作流程,是这样的:http://joemaller.com/990/a-web-focused-git-workflow/
解决方案
感谢您对问题的更新,现在更加清楚了。
我相信您遇到的问题是基于对 Git 工作流程的误解;Git 不等同于 目录 对于分支,它相当于 查看你的文件系统 到分支机构。这很强大——但很容易搬起石头砸自己的脚。让我解释。
Git 本身更像是一个数据库支持、差异版本、历史跟踪的文件系统。它位于文件系统的“之上”,而不是文件系统的“一部分”。它不使用您的文件系统来表示分支,相反,当您签出不同的分支时, 文件系统中的所有文件都将更改为该分支中的文件. 。您要求 Git 让您的文件系统代表该分支的替代现实。
如果您在分行 master
, ,它有一个文件 root/foo.txt
已提交,然后您查看分支 experiment
, ,这确实 不是 有 root/foo.txt
提交后,你会发现该文件 消失了 当你寻找它时。它是一部分 master
, , 不是 experiment
, ,因此它不存在于您的文件系统中。这就是为什么 Git 在允许你切换分支之前对你当前提交的分支非常挑剔 - 如果你的文件系统上有 Git 不知道的未暂存的更改,它会拒绝通过用不同的现实覆盖它们来将它们吹走。你必须先进行干预,让事情恢复正常。
因此,要回答这个问题,不要为“myliveapp”和“devapp”创建子目录 - 创建不同的 分支机构. 。只需将您的一个代码库放在“webroot”下即可。然后,砍掉“不稳定”分支,像往常一样提交更改。然后,您可以通过切换到“devapp”分支,将存储库中的所有文件切换为开发服务器文件的版本,并且您可以类似地随时切换回“不稳定”。
当你想更新一个分支时,例如更新你的开发服务器,你可以 merge
“不稳定”变成“devapp”。这将使“devapp”的所有文件看起来像“不稳定”的文件,使其保持最新状态。
还有一件事需要注意:主要仓库、裸仓库和克隆仓库之间的差异几乎为零。软件上几乎没有区别;相反,“Linus 内核是规范的 Linux 内核”是人类的惯例。有了这样的理解:
- 主要存储库只是每个人都同意保存该软件的“规范”版本的一个存储库。也就是说,每当开发人员做出更改时,他们希望每个人都看到,而不是说“拉我的Devapp版本”,他们可以说,“我已经发布了对我们的主要仓库的更改。”对于人们来说,这只是一个简单的惯例。
- 克隆是其他存储库的副本。我可以克隆主要存储库,进行更改,然后您可以克隆我的存储库。如果您进行更改,只要合并有效并且您拥有计算机的权限,您就可以将它们推送到主要存储库或我的存储库上。
- 裸存储库根本没有“工作副本” - 该计算机上没有“webroot”目录。它是空的 仅有的 这
.git
目录 - 这对于没有人需要更改文件的服务器来说很好。
最后, .git
dir 不保存存储库的文件,它保存 git 配置和数据库。这是数据库形式的整个存储库历史记录,用于使用特定版本的软件填充存储库的其余部分。这就是为什么我发表评论:你可以 本地 查看 任何替代现实的任何版本 存储库的内容,无需网络通信,随时 - 因为它都在 .git 目录中。唯一需要的网络通信是当您想要 同步 您的本地存储库到其他存储库,使用 push
或者 pull
.