改进PHP的Git工作流程和优化[magento]

Question

背景资料

我们正在努力从使用SVN转移到GIT，我们主要在magento商店工作，并为每个项目都有一个临时服务器和生产服务器。

这个过程用简单的术语来说：代码首先在本地机器上开发，每个开发机器上都有项目设置，然后提交到staging repo并由客户端和QA进行测试，然后掌握它进入生产的位置。质量保证的最终测试。

我们使用codebase / github存储库，并且使用deployhq自动部署到分段，并且使用deployhq由sys管理员从master到production进行部署。

GIT工作流程是在受到互联网上建议的不同工作流程影响后得出的，并且使用了http://nvie.com/posts/a-successful-git-branching-model/和Proper Way To Use Git/GitHub - PHP System with Dev/Testing/Production servers的块以及其他块，但也包括我认为与此模型一致的命令

GIT工作流程

0]在本地设置新的GIT项目

• git clone [path_to_repo] -b [branch_name] [local_dir]
• path_to_repo可以是远程存储库或分支包（repo.bundle）

1]在捆绑导入的情况下设置远程路径

• git remote set-url origin [path_to_repo]
• path_to_repo是远程存储库

2]根据分配的任务创建新的功能分支。

• git checkout -b [branch_name] //创建新分支并切换到它
• git push origin [branch_name]

3]所有更改都在本地分支中本地完成并定期推送到远程分支（批量处理，而不是单个更改！） 如果有人想在同一个分支上工作，他需要从同一个远程分支中提取数据，而不是从master。

• 日常生活
• git checkout [branch_name] //切换到分支
• git pull //从远程拉出最新的更改（例如在我们开始工作之前的早晨）
• 在文件中进行更改
• git add。或git add [folder] //准备要提交的文件列表或文件/文件夹
• git commit //提交对本地分支的更改
• git pull //在一天结束时推前同步以了解任何冲突
• git push //在一天结束时将更改推送到远程分支

4]一旦远程/本地分支中的更改正常并且需要在登台服务器上进行审核，本地分支将合并到远程登台分支中。

• git checkout staging //如果已经存在切换到它
• git merge [remote_branch_to_merge_to_master]
• git push

5]如果客户确认远程分支正常工作并准备部署到实时服务器，则合并到主服务器

• 合并为主人
• git checkout [master_branch_name] //切换到主
• git pull origin / master
• git merge [remote_branch_name_to_merge_to_master] //合并为主
• git push

Master to Production由Sys Admins手动完成deployhq。

问：是否应该有另一个分支机构，它将基于主机，只能从主机上获得正在上线的更改，即始终是最稳定的代码，或者这是多余的。

我们正在寻找有关减少步骤数量的建议，以及工作流程是否符合GIT中的最佳实践，包括随附的命令。

Answer 1

其中一种方法：

主要有三个分支：主要（开发），分期和生产。 staging和dev通过git post-receive hook和一些bash脚本自动部署，生产由tech lead手动运行部署脚本部署。

在master上完成工作，直到功能完成为止（除非功能非常复杂，并且大幅改变很多事情）。开发人员测试功能在开发站点上（构建脚本在每次推送后启动），向QA部门发送功能（如果有的话），在QA人员完成后编码器将工作发送给技术负责人的代码审查，客户批准开发工作

在x天内，master在合并阶段合并，QA通过分段运行，客户端第二次确认功能。

在分段中确认所有问题后，将在生产和生产分支中合并分段，并实时部署。

PS：所有三种环境都托管在不同的机器上，分段和生产具有完全相同的配置，开发人员不必严格遵循每个实时服务器配置调整 - 因此您可以为所有开发站点安装一台机器。

重要的P.P.S：为了让所有工作都在一个分支中，您需要使用一些问题跟踪系统并在每个相关提交中指定一个问题编号。

P.P.P.S：使用pull --rebase而不是pull来保持git历史更清晰，更容易阅读。