我在某个地方读过*这样的设置会很好:
两个主要分支,每个服务器一个.
推送到主人发送更改为live;
推送到dev/stage(或者你称之为的任何东西)会发送更改到staging;
工作流程:
从dev创建分支;
在你准备测试之前在当地工作;
合并回dev;
推送到Hub,它将更改发送到dev/staging服务器.
一旦你准备好上线了:
从dev到master合并,
然后将master推送到Hub,Hub将这些更改发送到实时服务器.
两个主要分支,每个服务器一个.
所以我在"webroot/myliveapp /"上有一个分支"production",在"webroot/devapp /"上有另一个分支"development"
存储库应该在哪里?
更新:
我的意思是:
根据这个流程,我们将有:
主要回购;
裸露的回购中心;
克隆;
开发和生产分支应该属于一个存储库,对吧?
如果这是正确的,那么我们应该发出FIRST git init命令吗?在我们的Prime回购?
所以我们将:
"webroot/myliveapp /" - 生产部门;
"webroot/devapp /" - 开发部门;
"webroot/.git" - Prime存储库;
这有意义吗?
或者Prime库是否应该与我们的生产分支机构位置相对应?
*注意:如果您需要有关我正在尝试实施的工作流程的上下文,请参阅:http: //joemaller.com/990/a-web-focused-git-workflow/
Mat*_*att 11
感谢您对问题的更新,现在更清楚了.
我相信你遇到的问题是基于对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内核"是一种人类惯例.有了这样的理解:
.git目录它是空的- 这对于没有人需要改变文件的服务器来说很好.最后,.gitdir不包含你的repo文件,它包含git配置和数据库.它是数据库形式的整个存储库历史记录,用于使用特定版本的软件填充其余的存储库.这就是我发表评论的原因:你可以在本地检查任何存储库的任何版本,没有任何网络通信,因为它在.git目录中都存在.唯一需要的网络通信是当您想要将本地存储库同步到其他存储库时,使用push或pull.
| 归档时间: |
|
| 查看次数: |
2275 次 |
| 最近记录: |