0

背景资料

我们正在努力从使用 SVN 转向 GIT，我们主要在 magento 商店上工作，并为每个项目配备一个登台服务器和生产服务器。

简单来说这个过程：代码首先在本地机器上开发，在每台开发机器上设置项目，然后将其提交到暂存仓库并由客户和 QA 测试，然后掌握它进入生产和最终测试的位置质量保证。

我们使用 codebase/github 存储库，部署到登台是使用 deployhq 自动进行的，从 master 到生产的部署是由系统管理员使用 deployhq 完成的。

GIT 工作流程是在受到 Internet 上建议的不同工作流程的影响后派生的，并使用了http://nvie.com/posts/a-successful-git-branching-model/和正确使用 Git/GitHub 的方法 - PHP具有开发/测试/生产服务器以及其他服务器的系统，但还包括我认为与此模型一致的命令。

GIT 工作流程

0]在本地建立新的GIT项目

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

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

  • git 远程设置 URL 来源 [path_to_repo]
  • path_to_repo 是远程存储库

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

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

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

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

4]一旦远程/本地分支中的更改生效并需要在暂存服务器上进行审查，本地分支将被合并到远程暂存分支中。

  • git checkout staging // 如果已经存在切换到它
  • git 合并 [remote_branch_to_merge_to_master]
  • git 推送

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

  • 合并到主
  • git checkout [master_branch_name] // 切换到 master
  • git pull 原点/主
  • git merge [remote_branch_name_to_merge_to_master] // 合并到 master
  • git 推送

Master to Production 由系统管理员通过 deployhq 手动完成。

Q] 是否应该有另一个基于 master 的分支生产，并且只从 master 获取立即生效的更改，即始终是最稳定的代码，或者这是多余的。

我们正在寻找有关减少步骤数量的建议，以及工作流程是否与 GIT 中的最佳实践（包括其中提到的命令）一致。

4

1 回答 1

1

一种方法：

主要有三个分支：master（开发）、staging 和 production。Staging 和 dev 通过 git post-receive hook 和一些 bash 脚本自动部署，生产由技术主管手动运行部署脚本部署。

工作是在 master 上完成的，直到功能完成才推送（除非功能非常复杂并且会彻底改变很多东西）。开发人员在开发站点上测试功能（每次推送后都会启动构建脚本），将功能发送给 QA 部门（如果有的话），在 QA 人员完成后，编码人员将工作发送给技术主管的代码审查，客户批准开发工作.

在 x 天内将 master 合并到 staging 中，QA 通过 staging 运行，客户端第二次确认功能。

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

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

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

PPPS：使用 pull --rebase 而不是 pull 可以让 git 历史更清晰，更易于阅读。

于 2013-05-13T19:15:07.087 回答